[Sammelthread] Ryzen RAM OC + mögliche Limitierungen

[Veii]

best shoot IF2000 so far GearOFF, needed your magic touch, wish me luck 🤓

Its hard work, not magic
From GDM to 1T GDM Off + Setup times, is difficult.

One starts with 2T

Sure, got 10 pieces Kernel eachtime after boot 9x 42 & 1x 5 here screen after boot,

Yea each #42 counts as one sensor-loaded log
a #5 counts as sensors utilized log.
10/10 , soo PCI ARI is on
SRIS maybe too.

You dont need those.
Guess MSI defaults.

9/10 is fine
Some CPUs are on 5-6/10, ones who bugged with Microcode and patch injection.
Was good to know.

Beitrag automatisch zusammengeführt: 14.05.2024

your tip 56-0-0 included, added +0,10mv to ccd & iod, also RDWR & RDDD/WRDD +1

Neither of those would weaken the signal to dimm.
But maybe it was due to SETUP timing issues.
#4 is a amperage issue.
very rarely a timing issue.

Reads like #14 is a trace dropout issue too
Soo if #4 is a side-issue, then SETUP timings would've fixed it

You rarely to never need to touch VDDG once you found a value that doesnt throttle, nor fails y-cruncher.

 

[Lic]

Mine sample is one "bugged" microcoded: 5/10 active kernel sensors. Perhaps this explain the reason I've so few wheas playing games or light loads.
I've tried the "inversed" CCD/IOD voltages, CCD 0,985 -> 1,065 and IOD 1,065 -> 0,985. More wheas, my CPU don't love these.
Reverted back to my profile settings and tried to raise CPU PLL from 1,825 to 1,885. Same wheas (perhaps few, but not free) no sensibles changes.
In any case I can define my profile stable? Not "rock stable" but simply stable? 14 iteration of y-cruncher, all tests, are enough?
Is summer, not hot in this moment, so I love to not torture my CPU night and day without a reason.
Mem test 50 1usmus_v3 passed without wheas. Memory is fine.
Y-cruncher 13 iteration passed with thousand of wheas, 14th failed at VT3 (stable?)
Benchmark: my best time in Pi-2.5b: 93.732 sec (personal record)
MaxMemm2: over 50 GB/sec, in-line result for DDR4-4000 from Intel side.
Perhaps 1,872V on Cpu Pll have done something right, not the solution but could be the right way.

The other step is to rais VSoc to over 1,20V, planned to test the max i will do: 1,25V! Hoping this could be the final test to understand if the "brute force voltage" OC is a whea-solution for this winter (of course, I'm not so crazy to maintain 1,25V on the Soc side for this summer, I don't love AC).

Y-Cruncher

IBT - MaxMem - Pi-2.5b

 

[Lic]

Oh well, my 3800c15 give me 95.737 sec. So I don't have penalty also with whea during y-cruncher test, 94-93 sec at IF2000 is better.
I've tested today also the PCI-Ex bandwith in 3dmark with best result, over 28K.
Some, with other configuration, but similar to me, have only 27K. So I can assume that also regarding PCI-ex my whea don't lower nothing.

Just to share, no way (same whea) also with 1,20V and 1,25 VSoc. Brute force isn't the solution for my system.
Also CPU PLL, moved until 1,9V but nothing, same whea (obviously combined with my actual profile and also with altered VSoc as before).

Ah, to the end and just to share some curiosity regarding AM4: I've solved a lot of boot problems (when changing some little voltages as for CCD and IOD, like 0,001V) simply moving the bios ram test from 3 to 5.

 

[Tatilica]

Just to share, no way (same whea) also with 1,20V and 1,25 VSoc. Brute force isn't the solution for my system.
Also CPU PLL, moved until 1,9V but nothing, same whea (obviously combined with my actual profile and also with altered VSoc as before).

Hi enthusiast, we'd like to see clean picture from Luxxers in here, with real stable results in progress, hopeing to find stability & wheas free in all scenarios hard workload Apps & Gaming and just but not living happily in games only wheas free🎆
WHEAs-free in games means nothing, but only testing in apps can quickly expose data fabric instability.
Your last 1usmus #4 error posted in OCN, no.17 wheas in only 1min30sec cruncher Benchmate 2.5b and also thousands in VT3 combo, means a lot IF instability to me, as 14 iteration VT3 failure, guess about how many wheas you can found in N64, if you can be able to pass it, but surely y can not 🤕
So be aware HWinfo can easily lies in wheas report during TM5, don't forget to keep open Event in Verbose checked by Kernel Wheas Range Time next run 👍

Please work harder if you want clean IF2000, is not just about luck or only running wheas free only in games, everybody can choose how to use his own setup, but keep in mind there are a lot of reduction PBO to be made for wheas free on X3D, and high voltages to be kept up in combo indeed💪
You are running pretty much high PBO & Limits PPT 104(73%) EDC 123(88%) and also questionable low-voltages for cpu to be wheas free at IF2000, your sample cpu looks like any hungriest X3D default
Here some mine's IF2000 Bios settings to compare👍

 

[Bread]

Frankly I do not get the idea of reducing PBO Limits like EDC so heavily, as this is limiting performance in demanding All-Core applications? My take is still, if you are about finding a setup that covers all usage scenarios with full stability, this is not the way to go.

 

[Tatilica]

Hi, that's an example for @Lic as IF2000 wheas free for gaming only is possible, as I found EDC limits over 60A will land you in wheas party, surely not for daily or benche's, but just fine for extra FPS, won't hurt from default cpu settings in extra long-gaming session 12h and not limiting performance by wheas penalty indeed, daily apps stick with PBO=Disabled 3800 4,7mhz👍

 

[Lic]

Hi Tatilica, thank you for your advice.
The ones you listed are the steps I am taking. I have not given up so far because the main use of the home PC is just for recreation. I play games and surf the Internet. Nothing more. I have dozens of office PCs, servers and professional PCs of which I troubleshoot and have fun with configurations and assembly.
The home PC only plays games. So I think my voltages are better than yours, and I don't need to reduce PPT, EDC or similar. Same for the timings. I started from c19, the XMP profil,e and step by step reduced until c16, really comfortable with low voltages (1,455 VDimm)
I would like to be able to eliminate whea, which is why I try, but on a personal level and not for anything else. I have been trying to figure out how this CPU works and to optimize the system so that I don't have strange behavior while using it. I don't have them, of any kind.
Since IF 2000 is not easy to achieve without whea, I was intrigued by my system. I tested and found whea, but not everywhere or with any application. Only in specific applications, and you know what they are. And I can't overclock bclock. My system have 3 x NVME drives , 2 x SSD and 2 x HDD. No way bclock.
In my previous posts I have tried to explain these reasons, and consequently advice and help in setting up my system better than I am now.
I have also offered myself as an example, in several threads, where repeatedly (and you are among them) it is said that it is not possible to play and not have whea with IF 2000, showing evidence and pictures, as here, for that matter.
Anyway I thank you again for your advice.

 

[Tatilica]

Hi guys, great update, fresh NEW start from origins, 3800CL14 pure 1T LCLK min/max 800 capped out of the box, just reflash same Bios Agesa 1.2.0.A & fresh Win10 reinstall indeed, bring me my precious 4,7mhz & L3 cache back on BCLK route, happy me 🎆

 

[ApolloX]

Still impressive what you CPU does.
I find it interesting how you approch the IF 1900 from the lower end. Did you ever try to see what happens if you overshoot the exact IF1900? It's our common sense here that IF1900 is the very last step where WHEAs don't occur (if settings are correct) for most Ryzens and from 1933 on they occur. The way you tune you system is interesting, indeed. How much BCLK can you do? Therefore, you would need a BCLK of ca. 103.7+ MHz. How far can you go?

My concrete question would be:
1. You use a tough Anta TM5 configuration such as extreme or absolute - where it's clear that we'll reprodicibly see WHEAs beyond IF1900.
2. You slowly exceed IF1900 by you BCLK method (requires 103.7 MHz and higher) and investigate when do WHEA 19 start to show up. It is really the very next step after IF1900? Is it another threshold, let's say IF1905, etc?
Ok, this is less a simple question and rather a small research task - and it requires that your CPU can do 103.7 and more.

Last one: Why do you now always show the ZenPTMonitor screenshot now? Can you recognize and interpret something from it yourself - and thus, it's a benefit for you? Or are you hoping that Veii will praise you for it? I can't interpret anything here and I doubt that anyone here can.

 

[Tatilica]

I find it interesting how you approch the IF 1900 from the lower end. Did you ever try to see what happens if you overshoot the exact IF1900?
2. You slowly exceed IF1900 by you BCLK method (requires 103.7 MHz and higher) and investigate when do WHEA 19 start to show up. It is really the very next step after IF1900?

Hi, long story short version, done with researches:
I'am capped to use only 103.5 bclk but not cause of wheas fest, my sample can run just fine straight IF1900 & 1933 wheas free, tested before, it's just I cannot pass +1mhz over 1900 with 103.75, will do instant reboot, not from bclk, mem freq will fall into 1900-1933 hole, so no boot at all in range 👎
Tested already my sample 104.5 bclk with 6600XT, cause RTX40 new architecture cannot hold that much, only Radeon gpu's can do it, already got my 4070 in 4000mhz scenario with earlier stable 3866 +103.75 bclk, but wheas are invited, so nope thx 🤕
As for ZenPT screen, I did not posted for you, no ofense here, was for me, I opened it from the beginning of TM5 run, as @Veii teached me to stay under MP5_busy=40 for cpu, looking for LCLK min/max spikes & more info to follow inline for 🤓
No need for your cpu to be in much autocorectable route (busy) all time, especially when you are testing, looking for most stable Profile, cause already got too much rock stable of them, all mem freq in different BCLK scenario, hard to decide which one is for my needs: IF2000 gaming only, IF1977 bench'es included, IF1900 CL14 & CL15 103.5 bclk daily & gaming 4,7ghz, perhaps last one 👍

 

[Bread]

If I remember it correctly, I did exactly what @ApolloX wanted, and even with 1910MHz I ran into WHEA - while BCLK 103,75 runs fine.

 

[ApolloX]

OK, war mir nicht bewusst, aber danke dir!

 

[Mr.Mito]

Vielleicht kann mir hier jemand helfen. Damals hatte ich stabile OC Settings gefunden und war damit auch lange glücklich. Leider hat sich mit einem AGESA Update etwas geändert und bei meinen Subtimings ist etwas nicht mehr stabil. HCI und co laufen weiterhin fehlerfrei durch, aber z.B. in GTA 5 gibt es (ab und zu) nach Stunden mal einen kick to desktop. (Weniger Takt scheint nichts zu ändern, daher auch die Vermutung ein Subtiming will so gar nicht. Nehme ich die raus(auto), läufts scheinbar.)

Jemand eine Idee bei welchen/m Subtiming ich ansetzen könnte? Alter HCI Lauf. tRCDWR ist schon auf 16, nicht mehr auf 8 - half nicht.

 

[Bread]

@Mr.Mito Ich seh da einiges, was man sehr schnell optimieren könnte. Wenn es wirklich am RAM liegt, würd ich vor allem mal tRFC auf 320ns setzen (608 bei 3800), das ist das "most launisch & zickig " Setting.
Dann tRCDWR auf 16, Platz 2 der zickigen Settings.

Auch kommen mir Deine Spannungen recht niedrig vor. Ich weiß es gibt Leute, da läuft das so, aber versuch doch mal vSOC 1,05 - 1,10 / VDDP 0,855 - 0,90 / CCD 0,90 - 0,95 / IOD 0,95 - 1,00.
ProcODT ist wiederum viel zu hoch für Ryzen 5000. 30 - 32 Ohm bitte, und RttNom auf 7 = 34 Ohm. Rtt dann mal 7/3/3 oder 7/3/4.

AddrCmdDrvStr auf 20, also 24/20/24/24, oder gleich 20/20/20/20.

Abgesehen davon geht bei den Timings einiges. Fangen wir mit den tertiären Subs an,
tWRWRSD auch auf 6.

• tRTP = 6 (wegen tWR = 12 / 2, siehe nächster Punkt)
• tWTRS 4 / tWTRL 12 / tWR 12 (mit tRTP 6).
• tRRDS 4 / tRRDL 6 / tFAW 16

Damit ist mal das alles bei den Subs "geradegezogen".

Am Schluss noch die primaries mit tRC auf 48, also also 16-16-19-16-32-48 (tRC 48 = tRAS + tRP mit tRAS 32 = 2x tCL).
tRC 48 packt ev Dein RAM nicht, dann ist die safe Variante: 16-16-19-16-39-55 (tRAS 39 = tCL + tRCDRD + tBL 4 / tRC 55 = tRAS + tRP).

Warum diese Werte? Weil sie sich bei den allermeisten Usern bei DDR4 3800 bewährt haben, also praktisch empirisch erprobte Best Practice sind.
Natürlich geht immer noch mehr, und es gibt hier Gurus, die unterschiedlichen Setting-Kombos noch viel mehr Zeit widmen würden - aber mit dem obigen hast Du mal 95% des erreichbaren. Sollte ggf sogar mit 1T GDM off funktionieren wenn Du darauf Lust hast - bringen tut es halt recht wenig, fühlt sich aber gut an

Beitrag automatisch zusammengeführt: 02.06.2024

Ergänzt oben: tRC 48 packt ev Dein RAM nicht, dann ist die safe Variante: 16-16-19-16-39-55 (tRAS 39 = tCL + tRCDRD + tBL 4 / tRC 55 = tRAS + tRP).

 

[Mr.Mito]

tRFC kann ich ausschließen, die geht selbst bei 2000 1:1:1 <=290ns.
tRCDWR ist bereits auf 16, wie geschrieben.
Die Spannungen haben bereits eine (ordentliche) Sicherheitstoleranz nach oben drauf, hatte ich aber dennoch schon versucht und daran lags wie zu erwarten nicht. Die CPU schafft die 2000 1:1:1 stabil, Screeni mit 2500% HCI kann ich auch noch reinpacken - geht aber am aktuellen Problem vorbei.
Ich will das jetzt nicht aufdröseln und verstehe deine Ansätze bei den Widerständen, aber es liegt nicht daran. Die sind ja auch je nach Board/CPU/Speicher einfach anders.
Ich vermute aktuell die tRAS (bin von 32 auf 34), aber das Problem ist halt, dass ich nicht einfach ein Testtool anwerfen kann um es festzustellen. Ich muss eher 8-10h spielen, pro "Durchlauf".
Vielleicht kennst du noch ein Tool/Grafikbenchmark, den ich nutzen könnte? Karhu, TM5 (config egal), HCI ect. laufen ewig.

tRTP interessiert mich jetzt aber wirklich wieso man hier tWR/2 nehmen sollte. Das ist mir neu. Wobei niedriger ggf. gehen mag, aber mich einer Lösung für mein aktuelles Problem eher nicht näher bringen wird, oder?
Das gilt auch für die anderen Subs. Ich will ein Problemtiming finden und indem ich andere Subs straffe, schaffe ich mir da nur mehr potenzielle neue Probleme, aber nicht weniger.
Wenn ich weiß wo mein Problem liegt, klar, dann gehe ich gerne nochmal ans Feintuning. GDM off mag die CPU/IMC leider gar nicht, wobei ich mit der ClkDrvStr noch schauen könnte, ob der IMC sich "überreden" lässt.

Aber wie gesagt, das geht ja am aktuellen Problem vorbei. Ein Timing ist bereits jetzt schon zu stramm und die tRFC kann ich leider bereits ausschließen.

 

[F|Marsman]

Als erstes würd ich mal die Proc runter setzten, wie bereits erwähnt viel zu hoch. 36,9 isn sehr gängiger Wert.
tFAW 20 hatte ich auch nur Probleme mit, runter auf 16 (tRRDS 4 *4 =tFAW).
Es muss nicht zwingend an zu scharfen Timings liegen.. können auch einfach aus der Reihe tanzen was dann Probleme macht.
AddrCmdDrvStr 20 würd ich auch empfehlen.
Ansonsten SC/SD/DD mal wieder auf 1/5/5, 1/7/7... scheint bis jetzt jeder RAM zu schaffen.
Ich finde die Spannungen für IOD/CCD für nen dual CCX auch recht niedrig, aber seis drum wenn das wirklich stabil läuft...

 

[Bread]

Ich vermute aktuell die tRAS (bin von 32 auf 34), aber das Problem ist halt, dass ich nicht einfach ein Testtool anwerfen kann um es festzustellen. Ich muss eher 8-10h spielen, pro "Durchlauf".
Vielleicht kennst du noch ein Tool/Grafikbenchmark, den ich nutzen könnte? Karhu, TM5 (config egal), HCI ect. laufen ewig.

Na dann mach doch mal das hier wie beschrieben mit tRAS 39: 16-16-19-16-39-55 (tRAS 39 = tCL + tRCDRD + tBL 4 / tRC 55 = tRAS + tRP).
Kostet kaum Performance, ist "nach Lehrbuch", und dann weißt Du es - und kannst den Rest optimieren

Wg Tests: ich nutze TM5 AbsolutNew@anta777 , und ggf Y-Cruncher VST / VT3 für RAM. Härtester Test CPU / Gesamt bei mir ist bisher CoreCycler mit HNT / C17 / VST im Hintergrund während dem Zocken. Crashed nach 5-60min, wo einzeln alles stundenlang läuft.

tRTP interessiert mich jetzt aber wirklich wieso man hier tWR/2 nehmen sollte. Das ist mir neu. Wobei niedriger ggf. gehen mag, aber mich einer Lösung für mein aktuelles Problem eher nicht näher bringen wird, oder?

Da heißt es in den Foren immer, das wäre nur für Micron relevant - aber auch bei Micron funktioniert auch tRTP = tWR fehlerfrei und performant. Allerdings gibt es etliche User, die berichten, dass bei ihnen Spiele gefühlt deutlich flüssiger / responsiver laufen bei Einhaltung von tWR = 2x tRTP - auch ohne Micron ICs. Einer davon hat sich hier auch schon mal ausdrücklich persönlich bedankt für den Tip, weil´s dann viel besser lief - also wird schon was dran sein.

Das gilt auch für die anderen Subs. Ich will ein Problemtiming finden und indem ich andere Subs straffe, schaffe ich mir da nur mehr potenzielle neue Probleme, aber nicht weniger.
Wenn ich weiß wo mein Problem liegt, klar, dann gehe ich gerne nochmal ans Feintuning. GDM off mag die CPU/IMC leider gar nicht, wobei ich mit der ClkDrvStr noch schauen könnte, ob der IMC sich "überreden" lässt.
Aber wie gesagt, das geht ja am aktuellen Problem vorbei. Ein Timing ist bereits jetzt schon zu stramm und die tRFC kann ich leider bereits ausschließen.

Zu stramm, oder einfach nicht "stimmig"? Hatte wie @F|Marsman tw bei lascheren Timings wie zB tFAW 20, tWR 18 auch mehr Probleme / schneller Fehler als mit 16 / 10.

 

[Mr.Mito]

ProcODT ist halt default. Vermute ASUS geht da einfach ans obere von AMD empfohlene Ende und da die 2000 damit auch liefen, bliebs einfach so. Ich war da einfach pragmatisch unterwegs.
Vor Jahren, als ich eben am testen war, bin ich damit auch mal testweise runter - änderte einfach nichts (außer ich ging deutlich zu tief). Da die 60Ohm on-die terminierung keinerlei Nachtiele haben, solange die Signale durchkommen, bliebs halt so. (Mir ist bekannt das es Stimmen gibt, die behaupten, dass höhere Werte für mehr Abwärme sorgen - ka obs stimmt.)
Gestern hab ich viel gespielt und es gab keinen kick (tRAS auf 34), daher warte ich jetzt erst mal ab.

Viel auf einmal ändern will ich mit meinem "Nutzsystem"(OS) nicht. Da es keine reine Spielekiste ist, ist das einfach zu riskant. Sollten die kicks wegen erhöhter tRAS weg sein, werde ich wenn die Zeit da ist mal die Werte im Gesamten anpassen und einen HCI Dauerlauf vom WinToGo starten. Vorher halt mit TM5 (absolutenew hab ich auch) vortesten.

Allerdings gibt es etliche User, die berichten, dass bei ihnen Spiele gefühlt deutlich flüssiger / responsiver laufen bei Einhaltung von tWR = 2x tRTP -8

Nicht böse sein, aber das hat Anflüge von Kabelklang. Außer halt man hatte vorher schon massenahft Fehler auf dem Bus, was man dann hätte mit AIDA (Latenz) hätte sehen können und das hat durch Zufall geholfen. Aber selbst das dann "zu spüren" klingt halt nach purer Einbildung. Hätte man dann auch in Benchmarks klar sehen müssen, frametimes, scores ect.

Danke auf jeden Fall für die Hilfe/Denkanstöße. tFAW 16 lief damals im Übrigen nicht, wobei ich nicht mehr weiß, welche tWR Kombis ich versucht hatte. Das werde ich bald mal wieder testen.
Die 2000 liefen damals eben auch mit ähnlichen Settings stabil. Ich hoffe einfach ich habs mit tRAS direkt getroffen. Wisst ihr wie weit M8E im Schnitt mit der tRC bei 3800/4000 runter können?

Na dann mach doch mal das hier wie beschrieben mit tRAS 39: 16-16-19-16-39-55 (tRAS 39 = tCL + tRCDRD + tBL 4 / tRC 55 = tRAS + tRP).
Kostet kaum Performance, ist "nach Lehrbuch", und dann weißt Du es - und kannst den Rest optimieren

Werde ich versuchen, sollte es mich mit tRAS 34 wieder kicken.

 

[Mr.Mito]

@Bread:

Hab gestern noch rumgegoogelt und hab dich dann auch bei Overclock. net gefunden. Da bin ich auch immer wieder mal stiller Mitleser. xD Wie es bisher aussieht, war wirklich die tRAS schuld.
Kannst du mir folgendes vielleicht noch beantworten?

Wisst ihr wie weit M8E im Schnitt mit der tRC bei 3800/4000 runter können?

tRAS+tRP als Faustformel ist ja schön und gut, aber liegt z.B. eine tRC von 50 (bei 3800) für M8E überhaupt im Bereich des Möglichen?

EDIT2:
Nö, tut es in meinem Falle schon mal nicht. tRC 58->50 = cmos clear. tRC 58->56 -> relativ flott HCI Fehler.

EDIT:
Hab jetzt mal aus Spaß bissel rumgespeilt im WinToGo. GDM off geht einfach nicht mit meinem 5900x, ClkDrvStr hilft hier auch nicht.
ProcODT von 60 auf z.B. 48Ohm sorgt dafür, dass man (geringfügig) mehr Vdimm braucht. Wieso sollte man ProcODT überhaupt drücken, wenn es auch mit 60Ohm gut läuft? Wo liegt denn dann der Nutzen?

Das hier z.B. wirft mit 1,370Vdimm bei 60Ohm beim kurzen antesten keine Fehler. Mit 48Ohm brauche ich dafür 1,380V, sonst gibt es relativ flott vereinzelt welche.

 

[ApolloX]

@Mr.Mito misst du gegen mit Aida? Die genannten Tipps lassen sich in der Regel mit besserer Performance des RAMs belegen, aber meist nicht spürbar, sondern nur messbar, z.B. per Aida. Trotzdem ist das hier ne Community, wo man auch nur rein messbare Verbesserungen sucht.

 

[Mr.Mito]

@ApolloX

Klar nehme ich i.d.R. auch Aida, wenn ich Leistung vergleichen oder mittels Latenzprüfung SoC/IoD Spannungen abklopfen will.
Worauf beziehst du dich denn konkret bzw. worum geht es dir? Das erschließt sich mir gerade nicht so wirklich.
Das man hier als Community auch nach minimalen Verbesserungen sucht, ist mir klar. Macht ja auch Spaß. Wobei ich zu Anfang vor allem nach einem Problemtiming suchte und scheinbar mit der tRAS scheinbar *auf Holz klopf* auch fand.

Durch einige der vorgeschlagenen Änderungen ergaben sich zwangsläufig Fragen, einfach aus technischer Neugier heraus. Die ProcODT zu senken z.B. bringt keine Leistung, trotzdem wird einem immer wieder dazu geraten. Selbst dann, wenn höhere Werte (innerhalb einer normalen range) problemlos laufen. Wieso sollte man sie dann trotzdem senken? Negativer Nebeneffekt etwas mehr Vdimm ist ja bekannt und tritt bei mir z.B. auch ein. Natürlich hinterfrage ich auch Faustformeln, wenn diese Werte ergeben, die man mit M8E nicht einmal booten kann. Kann ja sein, das es sinnvolle Gründe dafür gibt, die ich eben nicht kenne.
Die "16-16-19-16-39-55" nach "Lehrbuch" (welches Lehrbuch?) bringen btw. auch sofort Fehler in HCI, da meine M8E mit der tRC bei 3800 nicht einmal ansatzweise stabil sind. xx-34-58 dagegen laufen 2000%+ (und sind obendrauf flotter).

 

[Bread]

@Bread:
Hab gestern noch rumgegoogelt und hab dich dann auch bei Overclock. net gefunden. Da bin ich auch immer wieder mal stiller Mitleser. xD Wie es bisher aussieht, war wirklich die tRAS schuld.
Kannst du mir folgendes vielleicht noch beantworten?

tRAS+tRP als Faustformel ist ja schön und gut, aber liegt z.B. eine tRC von 50 (bei 3800) für M8E überhaupt im Bereich des Möglichen?

EDIT2:
Nö, tut es in meinem Falle schon mal nicht. tRC 58->50 = cmos clear. tRC 58->56 -> relativ flott HCI Fehler.

Genau, Microns und tRC ist anders als bei S8B und anderen. Bei M8E ist meist bei 56 Schluss wenn ich´s richtig im Kopf hab. Meine M16E packen gerade mal so tRC 54.

Bei M8E soll theoretisch die Formel tRAS = 3x tCL, tRC = 4x tCL was bringen, gleich schnell oder schneller bei einigen. Wäre bei Dir dann 16-16-19-16-48-64.
Dann sollte das ganze super entspannt und dennoch flott sein.

Hab jetzt mal aus Spaß bissel rumgespeilt im WinToGo. GDM off geht einfach nicht mit meinem 5900x, ClkDrvStr hilft hier auch nicht.

Dachte ich auch - nach ca 6 Monaten lief es dann aber

ProcODT von 60 auf z.B. 48Ohm sorgt dafür, dass man (geringfügig) mehr Vdimm braucht. Wieso sollte man ProcODT überhaupt drücken, wenn es auch mit 60Ohm gut läuft? Wo liegt denn dann der Nutzen?

Nach meinem Verständnis ist ProcODT ein Abschlusswiderstand, der Signalreflektionen verhindert, indem er das unter Spannung stehende Bauteil belastet ("Strom verbrät") dadurch auch Wärme entwickelt (wohl beim IMC). Je größer der Widerstand, desto mehr Wärme + weniger Stromfluß, was wiederum die Signalqualität beeinflusst. In meiner Erfahrung sieht es so aus: GDM off 1T mit straffen Timings konnte ich nur mit ProcODT 32 / Rtt 7/3/4 mit straffen Subs zum Laufen bringen. 36,9 lief glaub ich auch noch durch, war aber die Obergrenze. Die allermeisten in allen OC Foren fahren 30 - 36,9 und erreichen damit gute Ergebnisse.

Hier meine Settings für M16E 64GB (2x32). Sogar mit SVM / Core Isolation, was ein wenig Leistung kostet - aber so nutze ich es halt im Alltag.

Die Subs sind eigentlich unnötig straff, das läuft mit 4-6-16 tFAW und 4-10-10 tWR fast genauso - aber die entspannten Primaries erlauben es, und bissi angeben muss sein

Sehr spannend finde ich, dass M16E mit 19-19-22-19-38 fast so flott ist wie M8E mit 16-16-18-16-32 ( vgl hier bei @ApolloX zB). Bedeutet für mich, dass wir sowieso hauptsächlich tRFC limitiert sind-
Also unterstreiche ich meinen Punkt nochmal: schau doch einfach wie gut 16-16-19-16-48-64 läuft?

Beitrag automatisch zusammengeführt: 04.06.2024

@ApolloX
Durch einige der vorgeschlagenen Änderungen ergaben sich zwangsläufig Fragen, einfach aus technischer Neugier heraus. Die ProcODT zu senken z.B. bringt keine Leistung, trotzdem wird einem immer wieder dazu geraten.

Bringt auch nicht direkt keine Leistung, sondern Stabilität im Grenzbereich --> indirekt Leistung.

Selbst dann, wenn höhere Werte (innerhalb einer normalen range) problemlos laufen. Wieso sollte man sie dann trotzdem senken? Negativer Nebeneffekt etwas mehr Vdimm ist ja bekannt und tritt bei mir z.B. auch ein. Natürlich hinterfrage ich auch Faustformeln, wenn diese Werte ergeben, die man mit M8E nicht einmal booten kann. Kann ja sein, das es sinnvolle Gründe dafür gibt, die ich eben nicht kenne.

Nur zu, ich finde kritischen Diskurs super, hinterfrage auch selbst so viel ich kann um zu lernen

Die "16-16-19-16-39-55" nach "Lehrbuch" (welches Lehrbuch?) bringen btw. auch sofort Fehler in HCI, da meine M8E mit der tRC bei 3800 nicht einmal ansatzweise stabil sind. xx-34-58 dagegen laufen 2000%+ (und sind obendrauf flotter).

Mit XMP 16-19-19-19-39 werden viele Kits ausgeliefert (inkl. mein neues im Kasten), und tRC min = tRAS + tRP ist die anerkannte tRC Formel.
Wäre dann also 16-19-19-19-39-58 nach XMP + min Formel.
Oder eben 16-16-19-16-39-55 etwas optimiert nach RAM-Potential. Sorry, habe übersehen dass Du M8E hast, da ist 55 halt echt knapp bis unmöglich, einige (inkl. @ApolloX ) schaffen aber 56.

 

[Mr.Mito]

Du vergleichst bei den Aida64 Scores unterschiedliche BenchDLLs. Wars nicht so, dass die nicht vergleichbar waren?
Ich komme auf folgende Werte mit meinen Standardtimings (die vom 3800er HCI run). GDM off booten/benchen kann ich btw problemlos, auch mit default ClkDrvStr/ProdODT Werten. HCI Fehler gabs aber bisher immer relativ flott, wobei ich ClkDrvStr nie auf 120Ohm hatte. Wäre aber auch ein Weg, den ich nicht bereit wäre zu gehen.
Mit meinem 1600er hatte ich da einfach mehr Glück (3467 1:1:1 CL14 GDM off mit den gleichen M8E)

der Signalreflektionen verhindert,

Signalreflektionen? Ich hatte es als Terminierungswiderstand im Bezug auf SNR verstanden. Zu hoch und es kommt vielleicht etwas nicht durch, zu niedrig und zu viel "rauschen" kann durchkommen. Von der Problematik mit der Hitze bzw. ggf. sogar Schädigung des IMCs mal abgesehen. Robert Hallock sagte ja mal, nicht >80Ohm ohne LN2, wobei das noch Zen1 war.

Bringt auch nicht direkt keine Leistung, sondern Stabilität im Grenzbereich --> indirekt Leistung.

Konnte ich bei mir halt nicht wirklich beobachten. Das ich mit niedrigerer ProcODT etwas mehr Vdimm brauche, wenn ich genau auf der Kante bin, ist aber reproduzierbar. (Ich schlag i.d.R. eh bissel was auf am Ende, als Sicherheitspuffer.)
Aber ich werds mal versuchen zu drücken, sei es nur drum um den IMC etwas zu schonen. Auch wenn es jetzt schon Jahre mit 60Ohm lief.


Ich hatte leider eben wieder einen kick aus GTA. Der Witz ist, dass ich So/Mo echt viel spielte ohne jegliche Probleme und eben kegelte es mich nach 1Min raus. Am Ende liegts an GTA ...
Nervt mich das ich den Benchmark nicht einfach loopen kann. (Firestrike ect. loopt Stunden ohne Probleme.)

 

[Bread]

Nein, die sind ziemlich gut vergleichbar - AIDA Updates ändern sich nix in den Werten bei mir, seit 2 Jahren jedenfalls nicht. Dein Dual CCD ist allerdings tatsächlich nicht vergleichbar mit unseren Single CCDs
Wg GTA Problem: und Du bist sicher, dass das am RAM liegt, und nicht an der GPU, an CO, ...? Irgendwelche WHEA im Eventlog?

 

[Mr.Mito]

Ich hatte in Erinnerung, dass sich das durch die bench DLLs auch ändern kann. :-/ Dual CCD ist klar bei write, aber sollte read/Latenz nicht theoretisch gleich sein?
Mein gestern gestarteter HCI Lauf schmiss mir heute morgen leider einen Fehler. Einen ...
GPU bei GTA kann ich ausschließen, CO nutze ich nicht. WHEA hatte ich mit der CPU noch nie, nicht mal bei 2000. Die wirft irgendwie keine.
Kann durchaus auch an was anderem liegen, würde mich auch nicht einmal wundern, wobei kicktodesktop mir für ein zickendes Subtiming halt leider bekannt ist/war.

Der eine HCI Fehler erinnert mich an damals. Damals versuchte ich bei dem Problem mehr Vdimm/SoC/IoD/CCD ect - das halt alles nichts. Weiß nicht mehr welche Timings ich am Ende entschärfte, damit es lief.
Ich frage mich jetzt, ob der 2000% Lauf am Ende nicht einfach Glück war ...

10840] Wed Jun 05 06:14:52 2024 >> Memory error found copying between 0xfa8094f0, 0x6f8494d8, difference =20

Ist natürlich sau nervig zu testen, dauert ja ewig und frisst sack viel Strom.

Mögliche Gedanken aktuell dazu:

- Temperaturproblem? Aufgrund der Laufzeit. (Kein Lüfter vor den Kühlern, Case Belüftung ist gut, Lage der Speicher aber blöd)
- tRAS/tRC auf komplett relaxte Timings folgt als nächstes
- Doch Spannungen (glaub ich eig. 0)

Vielleicht hast du ja noch eine andere Idee.

 

[Bread]

Ich würd wie gesagt auch tWTRS 4 machen, und vor allem

• RttNom 7 bei DR
• AddrCmdDrvStr 20, also 24-20-24-24

Ist einfach bewährte Best Practice bei Ryzen 5000.

 

[Mr.Mito]

tWTRS/tWTRl hab ich schlicht weg vergessen, wobei ich mich schon frage, woher das tWTRS x3 kommt. Zwischen min bei beiden Werten liegen z.B. 5 cycle (2/7). Glaub die 5/10 sind sogar ASUS stock. Wenn ich mir screenis anschaue, finde ich meistens 4/10.

RttNom stellten sich mir auch ein paar Fragen.

https://www.reddit.com/r/overclocking/comments/ahs5a2/demystifying_memory_overclocking_on_ryzen_oc/

RttPark

From what I can decipher, when RTT_NOM is disabled/off, this value seems to take over.

Würde mich ja schon interessierenm ob das korrekt ist. Wenn RttNom disabled bedeutet RttNom=RttPark wäre off bei vielen Settings, meinem ja auch, quasi RttNom 1/240Ohm. Von 240Ohm auf 32Ohm ist dann echt direkt ein "ordentlicher" Sprung, quasi von max auf min.

Ich frage mich da zwangsläufig, woher die Empfehlungen im Endeffekt stammen bzw. auf welcher technischen Grundlage sie basieren (sollen). Man findet dazu wenig, leider. Überall wird das immer wieder wiederholt und klar, mag viele Leute geben, die eben auch gute Erfahrungen damit gemacht haben. Mich interessieren bei so etwas einfach die technischen Hintergründe.
Leider findet sich mit google auch bei reddit oder overclock.net nur wenig, vielleicht suche ich aber auch falsch.

Ist schade das es dazu keine guten Infos gibt, z.B. von Halleck, buildzoid o.Ä. Oder kennst du vielleicht eine Anlaufstelle, wo ich diesbezüglich mal herum lesen könnte?

Aktuell läuft HCI wieder mit relaxten tRAS/tRC Settings. Wird also dauern, bis ich weiß, ob es daran liegt. Widerstände kann ich danach mal ändern und hoffe. Ich bin da ehrlich gesagt skeptisch, mag aber sein das mein IMC da einfach eine Ausnahme ist und ihm das daher "relativ" Wurst ist. (Zumindest damals beim rumtesten.)

 

[Bread]

Woher das kommt? Ganz einfach, vom Ausprobieren. Ich hab bei RttNom off deutlich schneller Fehler bekommen, als mit 7. Und offenbar viele andere auch. Wir reden in meinem Fall von ~400 dokumentierten Testläufen á 4-7h über Nacht mit viel Stromeinsatz Natürlich nicht alle auf RttNom bezogen.

Zu den Grundlagen: Dynamic ODT ist was du suchst, Seite 249 functional description. Ich find das online bei Micron nicht mehr, und zum Anhängen ist´s zu groß. Hier die Doc# im Google Suchlink, damit findest Du´s.
"Micron 16Gb: x4, x8, x16 DDR4 SDRAM Features": https://www.google.com/search?q="CCM005-1406124318-10453"

Tatsächlich widmen sich diesen Themen nur Datenblätter, oder ein paar weniger Forenuser, und deren Ausführungen zu verstehen ist jedenfalls für mich schwierig
Hier ein Intel Artikel, der auf ein recht kompaktes Micron Dokument verweist: https://www.intel.com/content/www/us/en/docs/programmable/683385/17-0/dynamic-odt.html
Aber "TN-41-04 DDR3 Dynamic On-Die Termination" ist auch nicht mehr mit dem alten Link zu finden, ev findest Du´s ja irgendwo in der "aufgeräumten" Micron KB.

 

[Mr.Mito]

Gehtst du dann einfach an eine bekannte Vdimm Grenze und versuchst es dann? Ich werds definitiv mal an der Vdimmgrenze testen, bin ja nun doch neugierig.
Danke für die Links, werde ich mir mal anschauen.
tRAS/tRC hoch läuft im Übrigen noch. Der Grund wieso ich 34/62 und nicht 48/64 nahm war einfach Glücksspiel. Hätte ich 48/64 genommen und es wäre gelaufen, hätte ich 34/62 nochmal testen müssen.
Wenns jetzt läuft, dann nicht. Wenn es einen Fehler wirft, hab ich die "Arbeit" natürlich umgekehrt.

Sollte ich hier die 3000% schaffen, werde ich mich im nächsten Anlauf mal den WIderständen widmen bzw. testen, obs einen Unterschied gibt und schneller/langsamer Fehler wirft.
Ist bei tWTRS/tWTRl 4/10 auch ok? Die 10 scheinen ja zu gehen und wenns egal ist (was ich denke), würde ich die tWRTS einfach nur von 5 auf 4 drücken. Testläufe auf Ryzen bin ich sicherlich auch schon höher 3 stellig. Oben drauf frisst es halt einfach irrwitzig viel Zeit und Strom. Das aktuelle Testen sind auch paar €/Tag - ist echt verrückt.

EDIT:

Hast du die alten Links zu TN-41-04 DDR3 Dynamic On-Die Termination noch?
Ist im Anhang. Vielleicht interessiert es ja noch jemanden.

DDR4 PDF gibts hier: https://community.nxp.com/pwmxy8765...elopment-tools/8290/1/MT40A1G16RC-062E-IT.pdf
Und für die Ewigkeit nun (hoffentlich) hier: https://web.archive.org/web/2024060...elopment-tools/8290/1/MT40A1G16RC-062E-IT.pdf

 

[Bread]

Ganz genau Ich starte mit 1,45 VDIMM, teste die Timings aus, und senke dann am Schluss die vDIMM an die Stabilitätsgrenze.
S8B macht ja bis zu 1,70 VDIMM (mit Luftkühlung besser 1,55V), aber 1,45V sind für Micron etc kein Problem. Werden ja auch oft schon so verkauft.