Abtrünnig
Neuling
- Mitglied seit
- 15.01.2024
- Beiträge
- 15
Thank you for your time
Sorry I did just a small typo - LLC3 while SVID Trained set auto values to AC 0.54, DC 1.1
Here is my V/F:
[Sammelthread] Intel DDR5 RAM OC Thread
- Ersteller even.de
- Erstellt am
Sorry I did just a small typo - LLC3 while SVID Trained set auto values to AC 0.54, DC 1.1
Here is my V/F:
PSU aus = cold boot.
Stromzufuhr zu dem Board wegschneiden.
Da Training Optionen besonders solche wie VDDQ Training, welche als Foundation für 10+ Spannungen und Slopes verwendet werden (% factor of VDDQ)
Und somit es große Änderungen für die CPU selber sind.
Würde ich ein frischen Boot cycle erzwingen, damit auch jeder Wert schön und korrekkt mit dem neuen VDDQ antrainiert wird.
Ansonsten wäre es der Nutzer Wert + das antrainierte Offset ~ welches für die versteckten Werte benützt wird.
Das antrainierte Offset variiert natürlich, und wenn Slopes bzw Vout/Groups/RTT natürlich eine Lookuptable haben damit das Board schneller startet;
Kann es sehr schnell mal vorkommen, dass manche Slopes nicht genau antrainiert werden = Reboot Inconsistency.
Lookup Table =
Vorkonfigurierte Presets welche durch Bruteforce durchgegangen werden (trainiert)
Sollten alle Fehlschlagen failt der Boot, außer das Training ist absichtlich auf "slow" gesetzt.
Ein Beispiel für ein komplettes Trainiert sieht man bei AM5 Mainboards mit 90-180sec Training Zeit.
Eine "Große VDDQ Änderung"
Abseits dem ersten mal wo man VDDQ Training komplett ausschaltet ~ wäre zb über +/- 15mV.
30mV sind schon eine große Änderung, da Stabilität ohne Training innerhalb 5-15mV "brechen?" ... ruiniert werden kann, verloren geht.
ASUS bios'e sind nicht dumm. Überhaupt nicht.
Nur muss man als OCer sich im klaren sein, dass man verschiedene Foundations baut.
Man sollte die maximale stabile VDDQ zu VDDQ delta kennen (clock irrelevant)
Und darauf dann schauen wie weit man ohne niedrigeren Wert kommt. Ohne eine Erhöhung beider VDDQs.
// VDD2_CPU & VDD_MEM können seperat skaliert werden. Nur SA hat Einfluss auf alle Werte, da es die Vodt ändert.
Erst später kann man diese VDDQ ↮ VDDQ Delta verkleinern, wenn man Stabilität bzw SNR (noise) Probleme hat
IVR, VID ~ sind Load dynamic Spannungswerte.
Das umfasst (CoreVID, UncoreVID, E-cores & Cache VID, SA VID)
sowie (IVR VDDQ_CPU, IVR VDD2_MEM)
Wenn die CPU es nicht schafft durch das Powersupply Limit (PT1/2 ~ TDP/PPT) stabil zu throtteln
Sowie es nicht schafft auf 95-105° Thermisch mit einem (A) limiter zu throtteln. // Package Throttle @ same frequency-strap.
Dann ist eine der Spannungen zu tief.
// wenn sie es nicht schafft durch Clock Straps sich zu throttlen müssen auch andere Spannungen darunter leiden.
Den der Effekt wie stark es throtteln wird, wird stärker je tiefer das Powerlimit gesetzt ist.
Jedoch ebenso die Chance höher dass man das System nicht in seiner kompletten Auslastung testet ~ weswegen die Spannungen niedriger als eigentlich erlaubt, gehen.
Thermisch gesehen, benehmen sich die CPUs sehr ähnlich bis Subzero.
Die Kerne skalieren minimal bis 0°C
Allerdings sind IVR Spannungen nicht "in der CPU". Nun, sie umfassen nicht die Kern/Ring Stabilität.
Ein kleiner Einfluss hätten eher die Mainboard Thermals für die IVR Spannugen ~ jedoch ist das Kupfer/Glasfaser Gemisch recht stabil bis -50°c bzw tiefer.
Erst sobald es ~(-.200°C) erreicht, erst dann ändern sich die Material-Eigenschaften und bei ungefähr -270° wird es zu einem Superconductor.
Beitrag automatisch zusammengeführt:
Thank you
Soo its rather the lower range that causes scoreloss.
Peaks are about there where they should be.
Increase minimums and maybe AC_LL goes lower
Zuletzt bearbeitet:
tibcsi0407
Semiprofi
@Veii
Good Morning.
I thought maybe I can make an experiment with a 8533C36 profile and the RON's on 48/48-48/48 what I used for 8600 profile.
Decided to let the water heat up.
Look at the bitrates how they are raised by the time. It errored at 19th iteration but it's still very interesting, as it becomes warmer and warmer the bitrates were growing.
Is the RON's heat based too?
Good Morning.
I thought maybe I can make an experiment with a 8533C36 profile and the RON's on 48/48-48/48 what I used for 8600 profile.
Decided to let the water heat up.
Look at the bitrates how they are raised by the time. It errored at 19th iteration but it's still very interesting, as it becomes warmer and warmer the bitrates were growing.
Is the RON's heat based too?
Zuletzt bearbeitet:
Good timezone@Veii
Good Morning.
I thought maybe I can make an experiment with a 8533C36 profile and the RON's on 48/48-48/48 what I used for 8600 profile.
Decided to let the water heat up.
Look at the bitrates how they are raised by the time. It errored at 19th iteration but it's still very interesting, as it becomes warmer and warmer the bitrates were growing.
Is the RON's heat based too?
Anhang anzeigen 969193
I think that's pure coincidence and maybe two factors
~ cores V/F was too droopy, higher heat == lower TVB caused better stability
~ VDDQ was a bit too high by 5mV, and bit of heat messed with it. Soo it got more stable
Guardbands ~ thermal or voltage focused do not improve by thermals
To my eyes this looks like there is still room left to improve on bandwidth and it just happened to get better when losses increased.
You do have quite some throttle on IVR & SA-VID.
Its odd.
Ring hits max voltage, but without biosmod you can not do much.
I still have not gotten an "ok" to share it.
RONs just are wrong by the looks of it
Neither VDDQ nor RONs change by clock.
tibcsi0407
Semiprofi
That's why I thought to try a profile with lower mem speed. To find how it works on this particular config.
So RON and VDDQ's could be constant through all speeds.
I believe my best VDDQ pair is 1.32-1.35V for CPU and 1.47V for RAM. This gave me always the most stable result on each frequency. (On 8400C38 1.435V is enough)
I think I need to revise the voltage set for different RON's.
I don't know how can it be stable with that crazy setting.
But it's not reboot stable.
Now running 48/48-40-40 as you suggested before.
How the CPU_VDDQ should move if I change the RON? Lower resistance need more Voltage on TX side?
Beitrag automatisch zusammengeführt:
TVB doesn't kick in in Y when I have the water above 23C.
Beitrag automatisch zusammengeführt:
What can I do whit this one?
Beitrag automatisch zusammengeführt:
Yep, I can give 5mV offset to cache SVID and it can hold even 50X under Y, but I am not sure it's stable enough, so better to keep it like this.
Zuletzt bearbeitet:
Raw delta is what matters.
Training off has playroom of 15mV max. Mostly can fail by 5mV missmatch if you run it at the edge.
CPU Side:
RON = X * VDDQ
DQ_VFREF = X% * VDDQ
CA/CS_VREF = X% * VDDQ
CTL0 DQ VREF = (distance & height) Position of Pull_UP & Pull_Down ~ on build DQ_VREF
CTL0 Rodt?Vodt Vref = Sample Leakage, SA factor, PLL factor ~ build Vref , i think! based on sample resistance.
Mem side:
RTTs for DQ & DQS
Groups for same DQ (CK, CA, CS)
Any case, this stays valid
I would not recommend to start with defined RON, because Board (FW engineer) has to know the correct ones.
It is ok to sample them on already set VDDQ foundation, because of how important VDDQ itself is for everything.
But i would not go this way around. Especially without access to MR10-MR12. The field where VREF is created.
In order to mess with this part, you need to understand all other fields.
I don't recommend, but this sounds selfish.
I recommend trusting the board more now
And trusting your delta more too.
If Board or CPU has one weaker channel (common) its ok to tune
But this is a much later step.
Use a weaker RON for stronger MC channel.
Use a stronger RON for weaker MC channel.
If you remember which of both subchannels on 2nd channel failed. Give it a stronger signal
Pull Up is targeting "common signal", signal foundation.
If signal was too weak for mc channel, either Pull-Down needs to be stronger, or pull Up needs to be weaker (one of both)
This is interesting but for another day.
Likely correct is 48-40 && 34-40 or 40-34.
I remember this worked for Z690 Boards and white apex ~ but they had weak Channel A
Rest was MC (CPU) focused.
Result to show MC to MC communication was a coincidence. Its been verified with 6 hour runs.
I expect Encore to run 48ohm , because PCB is good. Its not similar to both APEX's.
But it has weaker 2nd Channel (funnily) - many encore by the looks.
Encore also seems to fail on fully automatic mode, but scales good on tuned manual mode.
If user maximizes and targets correct VDDQ then board begins to work. Unfortunately its not how it comes on stock.
Idk RONs for it. No way around testing hours on hours without messing with your found VDDQ.
One should not touch them, unless its MC-Link issue and not whole channel issue.
Beitrag automatisch zusammengeführt:
@tibcsi0407 opposite testing
Figure out absolute max delta (not PPT or Thermal limited)
Lower clock and higher clock
User higher clock to figure out one and only RON preset
Later once one and only RON preset is correct, downclock and finetune VDDQ again a bit and SA a bit
Then you can go back to scaling up and things should work. Last variable then is Groups and RTTs per channel.
Don't adapt VDDQ to RON, without knowing which RON is fully fine. And if two values work, then increase clock till one value only is correct.
// see proof-of-concept post #13.256. There is no need to scale VDDQ with clock
We can see that RON is fully not fine on 8533 example. Its not VDDQ that needs to change, but RON that needs to change.
Later later you can play with margins of 5mV (out of 15mV) to see which VDDQ really is perfect and only then find good RTTs to allow more margins
Reverse is asking for problems due to confusion.
VDDQ has to be perfect for the rest to work well. Everything builds on it.
Only later later you can target to slim delta. When signal is too noisy on high clock.
But not with soo many things on Auto.
Zuletzt bearbeitet:
tibcsi0407
Semiprofi
Thank you! This is so good write up, it's bookmarked.😊Raw delta is what matters.
Training off has playroom of 15mV max. Mostly can fail by 5mV missmatch if you run it at the edge.
CPU Side:
RON = X * VDDQ
DQ_VFREF = X% * VDDQ
CA/CS_VREF = X% * VDDQ
CTL0 DQ VREF = (distance & height) Position of Pull_UP & Pull_Down ~ on build DQ_VREF
CTL0 Rodt?Vodt Vref = Sample Leakage, SA factor, PLL factor ~ build Vref , i think! based on sample resistance.
Mem side:
RTTs for DQ & DQS
Groups for same DQ (CK, CA, CS)
Any case, this stays valid
Anhang anzeigen 969199
I would not recommend to start with defined RON, because Board (FW engineer) has to know the correct ones.
It is ok to sample them on already set VDDQ foundation, because of how important VDDQ itself is for everything.
But i would not go this way around. Especially without access to MR10-MR12. The field where VREF is created.
Anhang anzeigen 969204
In order to mess with this part, you need to understand all other fields.
I don't recommend, but this sounds selfish.
I recommend trusting the board more now
And trusting your delta more too.
If Board or CPU has one weaker channel (common) its ok to tune
But this is a much later step.
Anhang anzeigen 969206
Use a weaker RON for stronger MC channel.
Use a stronger RON for weaker MC channel.
If you remember which of both subchannels on 2nd channel failed. Give it a stronger signal
Pull Up is targeting "common signal", signal foundation.
If signal was too weak for mc channel, either Pull-Down needs to be stronger, or pull Up needs to be weaker (one of both)
Anhang anzeigen 969209
This is interesting but for another day.
Likely correct is 48-40 && 34-40 or 40-34.
Anhang anzeigen 969212
I remember this worked for Z690 Boards and white apex ~ but they had weak Channel A
Rest was MC (CPU) focused.
Result to show MC to MC communication was a coincidence. Its been verified with 6 hour runs.
I expect Encore to run 48ohm , because PCB is good. Its not similar to both APEX's.
But it has weaker 2nd Channel (funnily) - many encore by the looks.
Encore also seems to fail on fully automatic mode, but scales good on tuned manual mode.
If user maximizes and targets correct VDDQ then board begins to work. Unfortunately its not how it comes on stock.
Idk RONs for it. No way around testing hours on hours without messing with your found VDDQ.
One should not touch them, unless its MC-Link issue and not whole channel issue.
Beitrag automatisch zusammengeführt:
@tibcsi0407 opposite testing
Figure out absolute max delta (not PPT or Thermal limited)
Lower clock and higher clock
User higher clock to figure out one and only RON preset
Later once one and only RON preset is correct, downclock and finetune VDDQ again a bit and SA a bit
Then you can go back to scaling up and things should work. Last variable then is Groups and RTTs per channel.
Don't adapt VDDQ to RON, without knowing which RON is fully fine. And if two values work, then increase clock till one value only is correct.
// see proof-of-concept post #13.256. There is no need to scale VDDQ with clock
We can see that RON is fully not fine on 8533 example. Its not VDDQ that needs to change, but RON that needs to change.
Later later you can play with margins of 5mV (out of 15mV) to see which VDDQ really is perfect and only then find good RTTs to allow more margins
Reverse is asking for problems due to confusion.
VDDQ has to be perfect for the rest to work well. Everything builds on it.
Only later later you can target to slim delta. When signal is too noisy on high clock.
But not with soo many things on Auto.
Now running on 48-40 / 34-40, seems promising.
I will post the results. Wanna run a TM5 too because I got freeze again at 47. Minutes.
WIP: (bitrates are high and constant)
For bonus I tightened the primaries a little and upped VDD_MEM. Will see if it is okay.
Too short for RON testing.
Way too short
120-180min++, and even then its too short.
tibcsi0407
Semiprofi
I know, just wanted to pretest before TM5. Started the 90 min test too, hope it will pass.
Then it would be 120 min total. (If pass)
Update.
Second test died in 40 minutes.
I have no idea where to go further.
@Veii
Bitrates didn't even drop, not sure if it's the RON, or something else.
Could be the VDDQ too.
What do you think?
SA: 1.23V
VDD2: 1.518V
VDD_MEM: 1.62V
VDDQ_MEM: 1.47V
VDDQ_CPU: 1.35V
Maybe I should change the VDDQ_CPU before touching the RON's again.
VDD2 is also a black horse for me.
Zuletzt bearbeitet:
Global lasse ich auf AUTO, da das in bestimmten Situationen zu freezes geführt hat. Ich setze das negative OffSet in den Per P Core und per E Core Einstellungen, da kann ich auch etwas mehr negatives OffSet auf den E Cores fahren, muss man testen wie viel da jeweils geht. Die oberen VID-Punkte ziehe ich dann über die VID table wieder etws hoch. Ganz am Anfang zu Alder Lake Zeiten hab ich die P Cores direkt per negativem OffSet in der V/F curve in der Spannung reduziert, aber das funktionierte ab einer bestimmten BIOS-Version nicht mehr.
tibcsi0407
Semiprofi
Das Spielen mit VF-Punkten funktioniert wieder. Es ist besser anpassbar
We do likely again too many things at once
It is likely the fault of strange slopes on strange multiplier strap.
Two options
You auto RON & RON Training.
And get 150mV delta stable, +/- 5-10mV.
You drop to 8400. Force CTL0 which is based on VDDQ
Let it train
Psu off, then instead 1.33 VDDQ_CPU
You change to 1.32 VDDQ_CPU.
Get that 2-3 hour stable and only then change RON
Psu off again, discharge board, psu on, and 2-3 hours repeat.
If fail the usual, no change on RON
Isolate which channel till error, isolate which subchannel
On those, psu off.
We want full non persistent training
Beitrag automatisch zusammengeführt:
@X909
Ein IA offset, ist ein input/VRM supply offset.
Das ist schlecht, den die Kurve korrigiert sich und möchte X, jedoch gibst du ihr X-100mV.
Die CPU fragt dann konstant nach mehr und mehr da du ihr zu wenig gibst
Mit IA_AC_LL, erkennt sie wenigstens, dass ihre Requests niedriger sind als sie sein sollten und durch ein Exploit am Spannungscontroller (in der CPU) geht dies durch.
Die fused curve der CPU geht damit linear nach unten.
Die margins zwischen den VID-Requests werden zwar nicht verbessert, jedoch gehen wenigstens die Requests als ganzes Linear hinunter.
Wenn du von der VRM Seite das limitierst was sie bekommen soll, bettelst du nach Problemen.
Den die IA Spannung wird durch die gesammten VID Requests schon zu:
(Ring + QCLK (IMC) = DevClk) , VID-SA, VID IMC, VID VDD2 MC-LINK, SVID Cores & (E-Cores+Cache)
verteilt.
Es sind alles LDO's.
Ein cut in IA supply bzw ein Telemetry faking ist generell sehr suboptinal.
Ein offset am VRM , wäre somit sehr unüberlegt.
Ich hoffe man versteht.
Zuletzt bearbeitet:
tibcsi0407
Semiprofi
What if I force the 8600 CTL0 on this one?
This profile is badass. Very fast, much faster than a 8600C38. Maybe I could even tighten the tRFC a little.
Or maybe I can try the 8600 with these Voltages and timings. Huge in mem delta, I like it. 😊
"What if i do something stupid"
"Will i expect something functional"
I mean~~
Why do you ask
Zuletzt bearbeitet:
tibcsi0407
Semiprofi
We can call it research. 🤪
@X909
Ein IA offset, ist ein input/VRM supply offset.
Das ist schlecht, den die Kurve korrigiert sich und möchte X, jedoch gibst du ihr X-100mV.
Die CPU fragt dann konstant nach mehr und mehr da du ihr zu wenig gibst
Mit IA_AC_LL, erkennt sie wenigstens, dass ihre Requests niedriger sind als sie sein sollten und durch ein Exploit am Spannungscontroller (in der CPU) geht dies durch.
Die fused curve der CPU geht damit linear nach unten.
Die margins zwischen den VID-Requests werden zwar nicht verbessert, jedoch gehen wenigstens die Requests als ganzes Linear hinunter.
Wenn du von der VRM Seite das limitierst was sie bekommen soll, bettelst du nach Problemen.
Den die IA Spannung wird durch die gesammten VID Requests schon zu:
(Ring + QCLK (IMC) = DevClk) , VID-SA, VID IMC, VID VDD2 MC-LINK, SVID Cores & (E-Cores+Cache)
verteilt.
Es sind alles LDO's.
Ein cut in IA supply bzw ein Telemetry faking ist generell sehr suboptinal.
Ein offset am VRM , wäre somit sehr unüberlegt.
Ich hoffe man versteht.
Es ist halt die beste Art die Spannung auch in Teillast zu reduzieren. Drehe ich die AC_LL runter hab ich irrsinnig hohe Voltage in Teillast / beim Gaming.
Ich drehe nicht am VRM-Output, sondern direkt in der VF curve. Wirkt das nicht auf die requests der CPU bevor die ganze Regelung über Last, Temperatur, Loadline etc... zum Tragen kommt?
VIelen Dank für die ausführliche Antwort und Info. Jetzt nochmals, das sich es verstehe.PSU aus = cold boot.
Stromzufuhr zu dem Board wegschneiden.
Da Training Optionen besonders solche wie VDDQ Training, welche als Foundation für 10+ Spannungen und Slopes verwendet werden (% factor of VDDQ)
Und somit es große Änderungen für die CPU selber sind.
Würde ich ein frischen Boot cycle erzwingen, damit auch jeder Wert schön und korrekkt mit dem neuen VDDQ antrainiert wird.
Ansonsten wäre es der Nutzer Wert + das antrainierte Offset ~ welches für die versteckten Werte benützt wird.
Das antrainierte Offset variiert natürlich, und wenn Slopes bzw Vout/Groups/RTT natürlich eine Lookuptable haben damit das Board schneller startet;
Kann es sehr schnell mal vorkommen, dass manche Slopes nicht genau antrainiert werden = Reboot Inconsistency.
Lookup Table =
Vorkonfigurierte Presets welche durch Bruteforce durchgegangen werden (trainiert)
Sollten alle Fehlschlagen failt der Boot, außer das Training ist absichtlich auf "slow" gesetzt.
Ein Beispiel für ein komplettes Trainiert sieht man bei AM5 Mainboards mit 90-180sec Training Zeit.
Eine "Große VDDQ Änderung"
Abseits dem ersten mal wo man VDDQ Training komplett ausschaltet ~ wäre zb über +/- 15mV.
30mV sind schon eine große Änderung, da Stabilität ohne Training innerhalb 5-15mV "brechen?" ... ruiniert werden kann, verloren geht.
ASUS bios'e sind nicht dumm. Überhaupt nicht.
Nur muss man als OCer sich im klaren sein, dass man verschiedene Foundations baut.
Man sollte die maximale stabile VDDQ zu VDDQ delta kennen (clock irrelevant)
Und darauf dann schauen wie weit man ohne niedrigeren Wert kommt. Ohne eine Erhöhung beider VDDQs.
// VDD2_CPU & VDD_MEM können seperat skaliert werden. Nur SA hat Einfluss auf alle Werte, da es die Vodt ändert.
Erst später kann man diese VDDQ ↮ VDDQ Delta verkleinern, wenn man Stabilität bzw SNR (noise) Probleme hat
IVR, VID ~ sind Load dynamic Spannungswerte.
Das umfasst (CoreVID, UncoreVID, E-cores & Cache VID, SA VID)
sowie (IVR VDDQ_CPU, IVR VDD2_MEM)
Wenn die CPU es nicht schafft durch das Powersupply Limit (PT1/2 ~ TDP/PPT) stabil zu throtteln
Sowie es nicht schafft auf 95-105° Thermisch mit einem (A) limiter zu throtteln. // Package Throttle @ same frequency-strap.
Dann ist eine der Spannungen zu tief.
// wenn sie es nicht schafft durch Clock Straps sich zu throttlen müssen auch andere Spannungen darunter leiden.
Den der Effekt wie stark es throtteln wird, wird stärker je tiefer das Powerlimit gesetzt ist.
Jedoch ebenso die Chance höher dass man das System nicht in seiner kompletten Auslastung testet ~ weswegen die Spannungen niedriger als eigentlich erlaubt, gehen.
Thermisch gesehen, benehmen sich die CPUs sehr ähnlich bis Subzero.
Die Kerne skalieren minimal bis 0°C
Allerdings sind IVR Spannungen nicht "in der CPU". Nun, sie umfassen nicht die Kern/Ring Stabilität.
Ein kleiner Einfluss hätten eher die Mainboard Thermals für die IVR Spannugen ~ jedoch ist das Kupfer/Glasfaser Gemisch recht stabil bis -50°c bzw tiefer.
Erst sobald es ~(-.200°C) erreicht, erst dann ändern sich die Material-Eigenschaften und bei ungefähr -270° wird es zu einem Superconductor.
Beitrag automatisch zusammengeführt:
sry. 
Was soll ich nun einstellen oder versuchen?Wie oben beschrieben und in meinem Screen die Spannungen zu sehen.Würde einfach gerne die 8400 c36 stabil hinbekommen. Weiss nun nicht an welcher Schraube ich drehen soll. Deine Anpassungen an den WTRL/S und RRD habe ich gemacht. CPU ist alles auf Auto. SA auf 1.2. Bei 1.25 schmiert er ab, Freeze. VDD auf 1.54, IVR auf 1.38.
Felix the Cat
Der mit SeLecT tanzt
Mindfactory hat gerade diverse Kits von Patriot im Mindstar Angebot, z.B. 48GB 8000er und 32GB 8000er. Vllt für dein ein oder anderen interessant.
Selbstständig arbeiten und weiter testen.Jetzt nochmals, das sich es verstehe.
"Einfach die 8400 stabil bekommen" ~ haha
Ich denke auch dass du es schaffen kannst.
Aber mit spoonfeeding wird das nichts.
Sobald ich sehe dass du weiterhin rumtestest und selber forscht wie hoffentlich beigebracht
Helfe ich gerne weiter~
EDIT:
Ohne weiteres testen hilfst du zb auch nicht mir.
Moin
Dann den SA zwischen 1.18-1.22.
VDD2_CPU zwischen 1.38-1.46 für 8400MT/s.
VDD_MEM ist irrelevant bloß gleich oder höher VDD2.
VDD2_CPU darf nicht über VDD_MEM sein. VDDQ_CPU darf nicht unter VDDCR_SA sein.
An VDDQ zu VDDQ musst du leider wohl arbeiten.
Womöglich auf niedrigeren clock, bis man die max-delta von seinem eigenen Board und der CPU kennt. (nur ICCMAX limitiert)
Erst später kann man sich darauf fokussieren ob diese Delta kleiner sein muss, und schritt für schritt Probleme beseitigt.
Für manche sind 8200 einfach, für manche sind 8600 einfach.
Margins~
Um die Arbeit drum herum kommt man nicht
Über Remote auszuhelfen wenn du nicht selbstständig weitertestest ~ möchte ich ebenfalls nicht.
Ich werde weder dafür bezahlt, noch kann ich glücklich sein dass du etwas lernst & somit selbstständig arbeitest + dann für andere welche Hilfe brauchen da bist.
Da beides Fehlt, verschwende ich quasy meine Zeit.
Bitte arbeite selbstständig weiter und ich beobachte gerne deine weiteren Reports.
Beitrag automatisch zusammengeführt:
Du änderst nicht die VID durch supply offsets.
Es bleibt die selbe VID +/- supply X offset.
Viele VIDs werden zusammengefasst und verteilt.
Mit einem globalen offset, änderst du den Supply aber niemals das eigentliche Problem weswegen hohe Spannungen verwendet werden.
Nun,
weswegen margins für andere Teile der CPU kleiner werden ~ wie zb den Ring oder QCLK (mem).
Bei telemetry faking IA_AC_LL geschieht das selbe.
Du änderst nicht was eigentlich geändert werden sollte. Die supply margins.
CPUs mit besseren Kernen haben logischerweise (oft) bessere Margins für den IMC
CPUs mit besseren Kernen und schlechtem IMC, haben bessere margins für den RingClk
CPUs mit besseren E-Cores können eventuell bessere IMC margins haben da Cache mehr Spielraum für die Spannungen hat (more margins).
Telemetry Faking gehe nur durch
Da die CPU input und output beobachtet.
Sowie weil SVID antrainiert wird, und somit die CPU sich dem Board (loss) adaptiert.
Mehr macht man auch nicht mit den AC/DC_LL Änderungen.
Man erzwingt die CPU zu denken, dass man ein schlechtes leaky Mainboard hat, welches nicht die Spannung "deliver / liefern" kann, welche die CPU nun mal möchte.
Ein Exploit, wie gesagt
Beitrag automatisch zusammengeführt:
Für das Korrekte Undervolten, muss du die VID abändern.
Nicht den supply anpassen.
Außerdem stört hohe VID als solches nicht
Sie ist nicht für die Hitze verantwortlich und ebenso nicht degrading
VRMax auf den Boards liegt bei ~1.7v an. Bis 1.55 VID hat man wenig Probleme, außer dass die CPU Package Throttle'n kann.
// da die Requests in der V/F zu hoch sind.
Clock strap somit auch irrelevant.
Weder die Spannung als solches noch die CoreCLK Ziffer als solches, haben eine Bedeutung.
CPUs nach 2018-19 sind alle Load-balanced.
// VRM offsets, fixed clock, sind alles 5 Jahre alte overclocking Tricks welche dank LDO's nicht mehr funktionieren können.
Eine fixierte Frequenz oder eine fixierte Spannung ist schlecht für die CPU & im besten Fall einfach nur langsam.
Da Package Throttle auch bei fixiertem clock geschehen kann. Selbst wenn wir hier CEP ausmachen müssen dass der Loadline exploit überhaupt funktionieren kann.
Man geht um das eigentliche Problem rum herum
Den man undervolted falsch.
Zuletzt bearbeitet:
ceti
Enthusiast
Hio;
@Veii
also....
nicht sauer sein, aber bisschen englisch- bisschen deutsch...bisschen hiervon und bisschen davon :``
aussagen einfach aufstellen und so ist das dann....meistens ohne das man versteht wie man darauf kommen sollte...
Es ist nicht leicht einfach alles mal so zu verstehen, für den einfachen User...
Das war mal alles etwas einfach oder besser erläutert...ist aber schon einige Tage her
Ich verstehe die letzten Seiten einfach nur Bahnhof....oder ich Investiere Stunden und Tage um einige sachen durch zu testen....ohne zu wissen ob dem dann wirklich so ist.
Ich komme darauf weil du hier einfach und oft etwas auf den Tisch legst, und so soll das dann sein und Punkt.
Ich verstehe und glaube da nicht alles, aber es ist nur meine Persönliche Meinung...
Sorry....
mfg
@Veii
also....
nicht sauer sein, aber bisschen englisch- bisschen deutsch...bisschen hiervon und bisschen davon :``
aussagen einfach aufstellen und so ist das dann....meistens ohne das man versteht wie man darauf kommen sollte...
Es ist nicht leicht einfach alles mal so zu verstehen, für den einfachen User...
Das war mal alles etwas einfach oder besser erläutert...ist aber schon einige Tage her
Ich verstehe die letzten Seiten einfach nur Bahnhof....oder ich Investiere Stunden und Tage um einige sachen durch zu testen....ohne zu wissen ob dem dann wirklich so ist.
Ich komme darauf weil du hier einfach und oft etwas auf den Tisch legst, und so soll das dann sein und Punkt.
Ich verstehe und glaube da nicht alles, aber es ist nur meine Persönliche Meinung...
Sorry....
mfg
Es native zu erklären erklären damit Leute es außerhalb diesem Forum ebenso verstehen ~ welche das Forum stalken
Finde ich einfacher.
Dann auf deutsch den deutschsprechenden zu Antworten ~ ja , schon, finde ich ebenso angebracht.
Dass ein komplexes Thema auf einer Fremdsprache schwer zu verstehen ist ~ kann ich ebenso nachvollziehen.
Was die restlichen Sorgen angeht, leider nein
Ich kann nur hoffen dass du dir Zeit nimmst die langen Posts durchzulesen
Und wenn es weiterhin nicht hilft, nun es ist wie es ist.
Von meiner Seite aus, gebe ich mein bestes Sachen so gut es geht simple und verständlich zu halten.
// Es gibt Zeiten wo ich die Posts mit google Translate abgleiche und ausbessere, da sich deutsch sehr unglücklich ins englische übersetzt.
Wenn auch das stört, nun ich denke mal "not my issue" ? 🤭
Aber da du denke ich einfach nur höfflich einem darauf hinweisen möchtest,
Kann ich wirklich nur ein "danke ?" - sagen , aber das Problem hier liegt nicht auf meiner Seite sondern bei dir.
Beitrag automatisch zusammengeführt:
Was den rest der Sorgen angeht,
Ich Teile was ich teilen darf, und behalte für mich information welche ich nicht Teilen darf.
Solch sollte nicht deine Sorge sein
Danke jedenfalls für die Ehrlichkeit. 🤭
Zuletzt bearbeitet:
tibcsi0407
Semiprofi
Hello @Veii
Progress:
First I kept the 48-40 40-34 setting and tought maybe I should try some huge VDDQ delta.
The bit rates were these: (slow and not constant) Tought maybe it's due to the stronger RON'S with weak MC Voltages.
Then I changed the RON to 40-48 there.
And the results here. (second picture is a PSU off then retrain)
So now I have huge in-mem delta, huge VDDQ delta and works like charm.
I will use this as a base for my 8600.
VDDQ_CPU:1.24V
VDDQ_MEM: 1.47V
VDD_MEM: 1.63V
VDD2: 1.518V
SA: 1.23V
Seems both my MC links are strong. That's why the higher TX caused trouble for me.
Progress:
First I kept the 48-40 40-34 setting and tought maybe I should try some huge VDDQ delta.
The bit rates were these: (slow and not constant) Tought maybe it's due to the stronger RON'S with weak MC Voltages.
Then I changed the RON to 40-48 there.
And the results here. (second picture is a PSU off then retrain)
So now I have huge in-mem delta, huge VDDQ delta and works like charm.
I will use this as a base for my 8600.
VDDQ_CPU:1.24V
VDDQ_MEM: 1.47V
VDD_MEM: 1.63V
VDD2: 1.518V
SA: 1.23V
Seems both my MC links are strong. That's why the higher TX caused trouble for me.
Zuletzt bearbeitet:
Funny and informative
Thank you for testing further !
Well done~~
Beitrag automatisch zusammengeführt:
* bit proud too 😅
You do good work
Soo we stay at 48-40-40-48 or 48-40-48-40 ?
For encore
ceti
Enthusiast
Nein alles gut, mir fehlt immo dir Zeit für das ganze hier.Es native zu erklären erklären damit Leute es außerhalb diesem Forum ebenso verstehen ~ welche das Forum stalken
Finde ich einfacher.
Dann auf deutsch den deutschsprechenden zu Antworten ~ ja , schon, finde ich ebenso angebracht.
Dass ein komplexes Thema auf einer Fremdsprache schwer zu verstehen ist ~ kann ich ebenso nachvollziehen.
Was die restlichen Sorgen angeht, leider nein
Ich kann nur hoffen dass du dir Zeit nimmst die langen Posts durchzulesen
Und wenn es weiterhin nicht hilft, nun es ist wie es ist.
Von meiner Seite aus, gebe ich mein bestes Sachen so gut es geht simple und verständlich zu halten.
// Es gibt Zeiten wo ich die Posts mit google Translate abgleiche und ausbessere, da sich deutsch sehr unglücklich ins englische übersetzt.
Wenn auch das stört, nun ich denke mal "not my issue" ? 🤭
Aber da du denke ich einfach nur höfflich einem darauf hinweisen möchtest,
Kann ich wirklich nur ein "danke ?" - sagen , aber das Problem hier liegt nicht auf meiner Seite sondern bei dir.
Beitrag automatisch zusammengeführt:
Was den rest der Sorgen angeht,
Ich Teile was ich teilen darf, und behalte für mich information welche ich nicht Teilen darf.
Solch sollte nicht deine Sorge sein
Ich verstehe nur teilweise was du schreibst, aber erstens; bin ich nicht so da drinnen in dem Thema zur Zeit, und zweitens; übersteigt es auch das, was ich Zeitlich darin investieren kann oder will.
Alles gut
tibcsi0407
Semiprofi
Couldn't find this out without your help. I played a lot with the TX and started getting better and better as I lowered it under 1.27V.Funny and informative
Thank you for testing further !
Well done~~
Beitrag automatisch zusammengeführt:
Soo we stay at 48-40-40-48 or 48-40-48-40 ?
For encore
Then on 1.24V it was stable but slow, that's where I thought you told me about the bitrates and RON's. That made me think to try it again.
It's 48-40-40-48, could be a good base for 8600 too, also the low VDDQ_CPU.
This took me some days to find out, but hey, it seems promising.
One shot from an amateur 🙃
Haha, ya typical "falling to rabbit hole of side issues" ~ issue
Soo if its that way then
40-34-34-40 can equally work
but i am a bit uncertain on delta
This is like , a lot ...
16gb "prediction" of before is spot on too (its 165 mV)
But 230mV on 24gb is quite a bit.
Guess its alright
Good to see stability on delta inside mem
but keep that one in mind as variable
Over 105mV you may face RTT issues with unclean power
Up to 300mV is allowed based on PMIC design. Up to 200 is what many kits can do and asus called "default max"
tibcsi0407
Semiprofi
Yes, it surprised me too.One shot from an amateur 🙃
Haha, ya typical "falling to rabbit hole of side issues" ~ issue
Soo if its that way then
40-34-34-40 can work equally
but i am a bit uncertain on delta
This is like, a lot...
16gb "prediction" of before is spot on too (its 165 mV)
But 230mV on 24gb is quite a bit.
Guess its alright
Good to see stability on delta inside mem
but keep that one in mind as variable
Over 105mV you may face RTT issues with unclean power
Up to 300mV is allowed based on PMIC design. Up to 200 is what many kits can do and asus called "default max"
I will retest a few days later as a double check, but seems okay to me.
On 8600 I will have much smaller in mem deLTA, but VDDQ delta probably remain the same.
Danke dass du an mich glaubst.Selbstständig arbeiten und weiter testen.
"Einfach die 8400 stabil bekommen" ~ haha
Ich denke auch dass du es schaffen kannst.
Aber mit spoonfeeding wird das nichts.
Sobald ich sehe dass du weiterhin rumtestest und selber forscht wie hoffentlich beigebracht
Helfe ich gerne weiter~
EDIT:
Ohne weiteres testen hilfst du zb auch nicht mir.
Moin
Dann den SA zwischen 1.18-1.22.
VDD2_CPU zwischen 1.38-1.46 für 8400MT/s.
VDD_MEM ist irrelevant bloß gleich oder höher VDD2.
VDD2_CPU darf nicht über VDD_MEM sein. VDDQ_CPU darf nicht unter VDDCR_SA sein.
An VDDQ zu VDDQ musst du leider wohl arbeiten.
Womöglich auf niedrigeren clock, bis man die max-delta von seinem eigenen Board und der CPU kennt. (nur ICCMAX limitiert)
Erst später kann man sich darauf fokussieren ob diese Delta kleiner sein muss, und schritt für schritt Probleme beseitigt.
Für manche sind 8200 einfach, für manche sind 8600 einfach.
Margins~
Um die Arbeit drum herum kommt man nicht
Über Remote auszuhelfen wenn du nicht selbstständig weitertestest ~ möchte ich ebenfalls nicht.
Ich werde weder dafür bezahlt, noch kann ich glücklich sein dass du etwas lernst & somit selbstständig arbeitest + dann für andere welche Hilfe brauchen da bist.
Da beides Fehlt, verschwende ich quasy meine Zeit.
Bitte arbeite selbstständig weiter und ich beobachte gerne deine weiteren Reports.
Klar teste ich weiter, wenn ich mehr Zeit haben werde. Am Abend nach dem Sport, will ich noch bisschen daddeln mit den Jungs. Leider fehlt die Zeit dazu. Aber werde es sicherlich machen und versuchen. Sonst lass ich es einfach. Wenn der Aufand so gross zum Etrag ist, lohnt es sich nicht. Du machst einen mega Job hier, keine Frage. Man lernt auch einges von dir. Für viele halt Bahnhof. Ich bin da nicht soo tief in der Materie. Einmal ist man auch am Ende, da ist man dann froh um andere Ratschläge.
Im besten Fall, hast du stabiles Training.
Für manche sind die "margins" einfach größer und niedriger clock fühlt sich einfach an.
Die Arbeit es genau hinzubekommen und clock zu pushen - bleibt in etwa die selbe
Die VDDQ zu VDDQ Delta herrauszufinden , ist lästig. Absolut.
Aber sie ist nahe zu identisch sobald man seine "maximum margins" kennt.
Das System wird identisch instabil sein auf 7600 & auf 8000MT/s. Bzw 8000 & 82000MT/s ~ wenn VDDQ_CPU unpassend ist.
Da auf dieser Wortwörtlich alles basiert, muss man sie korrekt hinbekommen und für sein Mainboard PCB herausfinden.
Leider ist das viel Arbeit. Allerdings weitaus besser als auf Random Training zu hoffen.
Beitrag automatisch zusammengeführt:
Die Frage weswegen es an dieser Information lackt bzw Fehlt ?
Ich weiß es nicht~~
Ich fühle mich oft als einzige Person welche interesse daran zeigt die Sachen zu entdecken bzw generell herrauszufinden.
Schon bei AMD so und auch bei Intel.
Ich weiß es echt nicht~
Zuletzt bearbeitet:
Sehe ich auch so. Ohne Kommentare bzw Herleitung.Das war mal alles etwas einfach oder besser erläutert...ist aber schon einige Tage her
Ich komme darauf weil du hier einfach und oft etwas auf den Tisch legst, und so soll das dann sein und Punkt.
Sorry....
mfg
Das Niveau war schon mal besser hier.
Auch nur eine persönliche Meinung.
