[Sammelthread] Ryzen DDR5 RAM OC Thread

[Wolf87]

@RedF und Veii ich habe die Änderungen über die zuletz freigegebene Excel von RedF vorgenommen. Im Changelog habe ich meine Änderungen entsprechend hinterlegt.
War das so falsch? Sorry wenn es jetzt durch mich zu einem Durcheinander kam. Welche Datei ist denn die richtige bzw. welcher Link

 

[RedF]

@RedF und Veii ich habe die Änderungen über die zuletz freigegebene Excel von RedF vorgenommen. Im Changelog habe ich meine Änderungen entsprechend hinterlegt.
War das so falsch? Sorry wenn es jetzt durch mich zu einem Durcheinander kam. Welche Datei ist denn die richtige bzw. welcher Link

Ja, die S war eigentlich nur ein Funktionstest. Sollten sie zur eigentlichen machen.

Beitrag automatisch zusammengeführt: 10.12.2023

CLDO VDDP 1,0V tPHYRDL 35/37 . CLDO VDDP 1,143V tPHYRDL 35/35

Jetzt habe ich eine Stellschraube : ).
Kann jetzt endlich XX-36-36-36 versuchen, hab damit nie die tPHYRDL gleich bekommen.

 

[LuxSkywalker]

@RedF

Danke!! - mit CLDO_VDDP 1.090V konnte ich endlich meinen tPHYRDL mismatch beheben

mir war vorher nicht bewusst wie ich das in den Griff kriege

 

[RedF]

@RedF

Danke!! - mit CLDO_VDDP 1.090V konnte ich endlich meinen tPHYRDL mismatch beheben



mir war vorher nicht bewusst wie ich das in den Griff kriege

Cool, danke für die Bestätigung : )

 

[Veii]

VPP_MEM unter 1.8v solange es kein auslese Fehler ist, wäre problematisch.
Das selbe mit tRP unter tRCD.

 

[LuxSkywalker]

@RedF

ich habe zu danken

wäre ich im Leben nicht drauf gekommen 👍

@Veii

MEM VPP ob 1.8V oder jetzt runter auf 1.72V kann ich keinerlei Unterschiede feststellen - bin aber insgesamt ein Freund von möglichst niedrigen Spannungen

aktuell wird CLDO_VDDP im BIOS schon "gelb" angezeigt (alles über 1.100V purple) - so richtig gefällt mir das nicht, aber anders bekomme ich den tPHYRDL Mismatch nicht behoben ^^

/edit

CLDO_VDDP Farben vertauscht ^^

 

[Veii]

MEM VPP ob 1.8V oder jetzt runter auf 1.72V kann ich keinerlei Unterschiede feststellen

1.1v VDD_MEM, 1.1v VDDQ_MEM
1.8v VPP_MEM
sind die Specifications für DDR5.

 

[LuxSkywalker]

@Veii

hab jetzt VPP_MEM wieder auf 1.8V gesetzt

@RedF

nach kaltstart musste ich CLDO_VDDP um 5mV auf 1.095V erhöhen - ansonsten wieder "mismatch"

ich beobachte das morgen nochmal wenn der Kasten über Nacht ausgekühlt ist

 

[RedF]

1,8V VPP ist sozusagen ein Hauptversorgungsstrang, gut funktioniert bestimmt auch mit weniger.
Aber wenn was instabil wird, würde ich das wieder hochsetzten.

 

[Gr3yh0und]

Erste Versuche mit den 8000 48er Kit sind eher durchwachsen, bekomme es nicht so richtig stabil. 25x TM5 laufen durch, Karhu dann bei 8K Fehler. Klingt weniger nach dem Kit als nach der CPU.
CPU ist stock alles. RAM wird max 55°C warm.

• VSOC: 1,3V
• VDD + Q: 1,55V (Wahrscheinlich zu hoch, aber erstmal das Kit mit ausschließen)
• VDDIO: Auto ~ 1,43V
• CLDO VPP 1,05V

 

[Wolf87]

Ich habe immer noch einen missmatch beim tPHYRDL VDDP hab ich bis 1.14 v probiert. Gibts noch etwas was den missmatch beeinflusst.

 

[Veii]

Gibts noch etwas was den missmatch beeinflusst.

CPU 1P8v Spannungsversorgung
Alle proc ~ ODT's
Alle RTTs
tRDWR
tWRRD
Alle SD's & DD's
EDIT: eventuell auch VDDIO (womöglich eher, anstelle VDDP)

Setze mal beide WRWR_SD/DD's auf 8 ?
Und procODT ein tick tiefer

Könnte MCR aus + Fastboot aus brauchen.
Den Timingsänderungen erzwingen keinen Coldboot.

 

[LuxSkywalker]

@Wolf87

ich hatte von Anfang an mismatch und wirklich alles ausprobiert um dies zu beheben u.a. auch die von @Veii im Vorpost geschriebenen Einstellungen.

Hat bei mir alles nix gebracht - bis @RedF mit der CLDO VDDP Spannung um die Ecke kam

 

[Wolf87]

Bei mir hat es leider nicht zum Erfolg geführt danke trotzdem. Dann muss ich einfach die Werte durchprobieren

 

[RedF]

Ich musste bei 6200 auf XX-37-37-37 und die gleich zu bekommen.

 

[Wolf87]

Danke hat auch nichts bebracht

 

[LuxSkywalker]

das ist ja mal total Strange - kannst du mal bitte einen ZT Screenshot mit deinen aktuellen Timings posten @Wolf87

hab übersehen das du schon zuvor einen Screenshot gepostet hast ^^

@RedF

ich musste CLDO_VDDP nochmals um 2mV anheben auf nun 1.097V um den Mismatch auch bei Kaltstart zuverlässig zu beheben

 

[Wolf87]

@RedF gibt es schon was zum Thema Ropbench🙂

 

[RedF]

Kannst damit jetzt sehr stabil die Latenz messen. Warum das mit jedem Kern einzeln geht, ist mir aber nicht klar.

Er will über die Feiertage die Core2Core Latenz Messung mit einbauen.

 

[QuaK3R]

Hat schon jemand 8000er Ram mit dem 7800x3d getestet? Mich würd interessieren wie der Speicher in CS2, Valorant und COD performt.

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

 

[Gelöschtes Mitglied 189335]

Nachricht gelöscht

 

[QuaK3R]

Hmm auch die 1% lows sind besser, gut zu wissen. Das nehme ich gerne mit xD

 

[Veii]

Ein weiterer Nutzer/Reviewseite welche Memory timings nicht skallieren können~

Wenn man schon sich die mühe macht ein Video zu schneiden
So sollte man wenigstens auch versuchen die Timings gleichzustellen.

Ebenso muss man gegentesten ob FCLK nicht schon beginnt zu trotteln wenn man aus heiterem Himmel 150mV wegschneidet.

Beitrag automatisch zusammengeführt: 13.12.2023

Abseits autocorrection , könnte es sogar gleich enden. Den einerseits sind Spiele keine Benchmarks und andererseits füllen sie kaum Ram bzw nicht jeder Test füllt den X3D Cache.
Aber hier testet man Äpfel vs Kirschen.
Birnen wären es , wenn man wenigstens PostPackageRepair bei Mem nicht erzwingen würde mit den "zuu niedrigen" 2ndaries bei 7800.

Äpfel vs Äpfel wäre es dann wenn man die Spannungen gleich lässt, und das 6400er Preset hochskaliert.
Oder beide auf 2100 FCLK rennt mit niedrigen Spannungen (da ansonsten Gear 2 womöglich nicht stabil sein wird)

Hier hat man 3+ Variablen und ich selber könnte nichtmal herausfinden was man überhaupt vergleicht
~ Skalliert der Titel mit MCLK
~ Skalliert der Titel mit niedriger Zugriffszeit
~ Kümmert es die CPU wie hoch UCLK rennt.

Ich weiß es nicht. Was testet man ?
Allerdings haben solche Ergebnisse zuu viele Variablen und man sollte es besser nochmal versuchen.

Beitrag automatisch zusammengeführt: 13.12.2023

Mich würd interessieren wie der Speicher in CS2, Valorant und COD performt.

COD als sehr unoptimierter Titel könnte sogar skallieren
Valo, nur wenn es mehr als 4 Kerne ladet
CS , eigentlich das selbe.
Apex womöglich das selbe. Recht unoptimiert und eine Große map + kann 24 threads belasten. Sollte rüberleaken

Alles nur wenn die Kerne auch den Max boost halten und der Nutzer nicht dank zuu niedrigem CO throttled.
Dann , könnte man eventuell im Cache limiter landen und erst dann ! , spielt es eine Rolle wie schlecht Optimiert bzw wie Groß der Titel ist den man rennt.

Nach all diesen Variablen
Sollte man 7600MT/s auf 4 dimm-slot Boards einfacher hinbekommen, bzw 7800 auf 2 Dimm-Slot Boards
Als das 6200/6400 Gegenstück. Bei niedrigerer Spannung.

Was 2100 FCLK dann benötigt ist eine weitere Variable
Aber für X3D CPUs ist die Interne Bandwidth nahe zu 500GB/s.
Es ist genug. FCLK ist halb/unwichtig.
Da spielen zwischen 80GB/s mem und 100GB/s mem kaum eine Rolle.
CoreClock aka Cache-Clock spielt eine wichtige Rolle ~ und dann je nach Titel ob Cache rüberleakt (aka zuu voll) oder der Titel ein IndieSpiel ist bzw keinerlei kerne auslastet.

Keine Kernlast = genug cache = mem unwichtig.
Soweit sehe ich keinen Reviewer/Public Media - auch nicht die Mainstream internationalen ~ welche es per SKU korrekt testen.
Damit inkludiere ich 25+ Reviewer und Tester - including Overclocker.
Es ist traurig. Man missversteht was man eigentlich testet.

EDIT:
Von dem kleinen Teil an Overclocker welche es versuchen zu testen kommt dann
"X skalliert nicht, Y ist zuu schwer zu rennen ~ brauchst du nicht. Not worth it"
Leider denke ich dass auch das eine fehlerhafte Zeichnung der Realität ist
Es muss nicht skalieren damit es in der Realität schneller sein kann/bzw schon ist.

Wenn MCLK immer skalieren würde wie bei Zen1/2, dann deutet das auf ein Architektur Problem.
Ja, X3D Leakt noch Cache (leider). Ich habe es selber getestet. Aber es ist soo selten und nur bei sehr unoptimierten Titeln. Bei voller Auslastung !
// NonX3D 1CCD umso mehr ~ aber die haben eher FCLK probleme.
Das macht Gear2 weiterhin nicht irrelevant oder "schlechter". Nur dass es aufgrund vielen anderen vorherigen! Variablen, Memory als solches selten beginnt eine Rolle zu Spielen.
// UCLK ist intern. MemoryClock ist extern , weit weg von der CPU.
Dennoch ist es einfacher 1850-1950MHz Gear 2 zu rennen, anstelle 3200-3300MHz Gear 1 🤭
Wie immer, das ist nur meine Sichtweise und Beobachtung. Man muss nicht unbedingt die selbe hegen~~

 

[Bullseye13]

Hat noch wer Verbesserungsvorschläge?
Läuft jetzt ziemlich rund.

 

[Veii]

Hat noch wer Verbesserungsvorschläge?
Läuft jetzt ziemlich rund.

Anhang anzeigen 948594

SD auf 1 oder 0 (wenn 0 ≠ Auto)
WRWR gleich RDRD oder CCDLWR Math
SCLs sind mathematische Formeln. Keine fixierten Werte wie 4 oder 8.

Dual CCDs haben als Problem erst die Intercore latency.
Sprich ring ist langsam. Es braucht FCLK bevor memory beginnt eine Rolle zu Spielen.

Core/Cache Clock über 5.5GHz sind mehr als genug.
X3D hat dieses Problem nicht.
X3D performt nur schlecht dank der Nutzer. Auf stock allerdings passt es. Nur wenn man CO nicht hinbekommt und Autokorrektur sich erzwingt;

2100 FCLK passen gut.
Ansonnsten MCLK +1 step und 2033/2067 FCLK
Die synchronization ist wichtig.
Nicht jeder MCLK step passt gut mit jedem FCLK step.
Laufen wird es, aber eines wartet auf das andere.

EDIT:
Die Kommunikation dessen, kann man mit SiSoftware Sandra , Inter-Thread tests gegentesten
Bzw microbenchmarks.

Man sieht deutlich wie sich alle Cache zwischenschritte verhalten und ab wann/bzw ob überhaupt memory clock eine rolle spielt.
Ab wann FCLK syncron ist, usw~~

 

[Gr3yh0und]

@Veii Wahrscheinlich tRFC zu niedrig? Nach Reous Liste sollten 24GB M-Dies aber auch bis ~160ns gehen oder? Irgendwie scheint da bei ~180ns bei mir Ende zu sein. TRAS ist auf Optimum. VDD/Q Spannung jetzt gerade mal 1,55, absichtlich etwas überhöht. Ich versuche noch einmal 186ns bei 1,5V über Nacht.

8000 hab bisher mit egal welchen Settings und Spannungen nicht ans laufen gebracht.

Werte großteils mit eurem Rechner eingestellt, danke dafür. Ein Verbesserungsvorschlag wäre noch eine weitere Tabelle, die die End-Werte so darstellt wie im Zentiming. Dann kann man schnell vergleichen, ob man falsch liegt/was vergessen hat

 

[Wolf87]

@Veii woran erkennt man das im Inter Thread Test bzw in microbench fclk syncron läuft

 

[Veii]

@Veii Wahrscheinlich tRFC zu niedrig? Nach Reous Liste sollten 24GB M-Dies aber auch bis ~160ns gehen oder? Irgendwie scheint da bei ~180ns bei mir Ende zu sein.

Kannst du mir/uns garantieren dass das Hynix und keine Micron's sind ?
Micron hat die JEDEC specs bis 8800MT/s ausgelegt.

^ 1.1v
Die letzten Corsairs unter 7200MT/s waren Micron's.
Microns sind nicht schlecht, bloß die ehmaligen 16gb dimms etwas immature.
Im Gesamtbild sind sie bis 8800MT/s worin Hynix nur bis 6400MT/s specs setzt.

@Veii woran erkennt man das im Inter Thread Test bzw in microbench fclk syncron läuft

AMD DDR5 OC And 24/7 Daily Memory Stability Thread

www.overclock.net

Das sagt eigentlich schon alles für mich aus, ohne mir X Spieltitel raussuchen zu müssen ~ ob Gear2 nun etwas bringen "kann" oder nicht
Klar und deutlich🤭
Natürlich muss man auch verstehen wann und wieso es skallieren würde, aber das wären nur Kleinigkeiten~

Moin

Beitrag automatisch zusammengeführt: 14.12.2023

Ich warte weiterhin dass man mich ohne ECLK einholt ~ aber ja
Inter-core & thread "usable" Bandwidth ist eigentlich das wichtigste. Als Gesammtbild.
Welche Datengröße kann wie schnell angesprochen werden , mit welcher Bandbreite.
Ein Resultat aus CoreClk x Ring x SOCCLK x UCLK&MCLK.

Der Rest skaliert dann je nach Titel manchmal weniger, manchmal mehr.
Man sollte bei Last welche nicht mal 80% der CPU belasten - keinerlei Skallierung erwarten.
Den L$ ist mehr als schnell genug auf den X3D's um Intern Daten hin-und-her zu tauschen.
Die Latenz ebenso ~ 9ns to 20ns max. Wortwörtlich vorbildlich.
Die CPU würden die 52-55ns Memory überhaupt nicht kümmern. Dafür kann es 2x die Daten schneller im Cache verarbeiten welche ebenso über 150GB/s erreichen.
Anstelle auf 50ns Mem mit ~100GB/s zu warten.

Bei den non X3D's und besonders die Dual CCDs mit ~60-65ns Roundtrip latency , sieht das Thema schon ganz anders aus.
Da kann und sehr wahrscheinlich wird es ebenso (da L$ zu klein ist), eher zum DRAM springen.
Wenn Ring schnell genug ist, aber nun ja.

Es sind einiges an Variablen im CPU-Design, als dass/bevor man es zu MCLK schieben kann/muss.
Einiges muss schnell genug sein, bevor MCLK überhaupt ~global~ etwas bringen kann.
Skalieren tut's immer. Ob es allerdings dazu kommt aktiv benützt zu werden, ist eine andere Frage.
Jeder Clock auf Ryzen ist loadbalanced Hoher FCLK zb bringt nicht immer was ~ wenn du eher Probleme im Core/Cache Clock hast.
RDNA includiert;

Skalieren tut's immer. Ob es allerdings dazu kommt aktiv benützt zu werden, ist eine andere Frage.

TL;DR
Es bringt immer was Gear2 zu rennen.
Es ist einfacher und es hängt von anderen Variablen (pro SKU unterschiedlich) ab, ob dein MCLK überhaupt ein Benefit liefert oder nicht.
"Verschwendet" wäre die Zeit nicht. Aktiv Geld dafür auszugeben muss man mit einer X3D CPU aber eher nicht. ~ An der haakt es an CoreClk zuerst.

7600 ist einfacher als 6400MT/s 🤭 Naja je nachdem.
Der Vergleichspunkt (ab welchem Clock es "Sinn" macht) skaliert je nach den vorherigen Variablen.
6200/7600 , 6400/7800-8000MT/s sind eher gleich auf.
6200MT/s sollten sehr viele CPUs können, 6400 aber eher die wenigen.
6600 womöglich nur 1-2%. 6400 womöglich nur 12-15%.

---

Kann skallieren.
Macht für manche Spaß
Man sollte keine Wunder erwarten.

Skalliert jederzeit oder skaliert später ~ SiSandra ist dein Freund. Hoffentlich auch bald RopBench.
Gibt keine Garantie dass es aktiv skaliert, da es 3 Variablen vor MCLK gibt welche ge'maxt werden müssen bevor es an MCLK haapert.
Das sollte als zufriedenstellende Antwort reichen~~
Einfach immer mit SiSandra gegentesten ob das Gesammtbild besser wird, wenn man selber keine Skalierung feststellen kann.

 

[Bullseye13]

SD auf 1 oder 0 (wenn 0 ≠ Auto)
WRWR gleich RDRD oder CCDLWR Math
SCLs sind mathematische Formeln. Keine fixierten Werte wie 4 oder 8.

Core/Cache Clock über 5.5GHz sind mehr als genug.
X3D hat dieses Problem nicht.
X3D performt nur schlecht dank der Nutzer. Auf stock allerdings passt es. Nur wenn man CO nicht hinbekommt und Autokorrektur sich erzwingt;

2100 FCLK passen gut.
Ansonnsten MCLK +1 step und 2033/2067 FCLK
Die synchronization ist wichtig.
Nicht jeder MCLK step passt gut mit jedem FCLK step.
Laufen wird es, aber eines wartet auf das andere.

Ich hab diesen Block eigentlich gemäß der Excel Tabelle eingestellt.
Falls das nicht passt, hab ich die Tabelle wohl nicht verstanden.

Kannst mir eventuell zum Screenshot die Zahlen schreiben?
Ich bin mir nicht sicher ob ich deine Abkürzungen alle richtig verstehe.

FCLK 2100 werd ich dann als nächstes versuchen.

 

[Veii]

FCLK 2100 werd ich dann als nächstes versuchen.

Müsstest zwischen 2033,2067,2100 gegentesten ab wann es sich am besten zu diesem MCLK verträgt. (sollte eine .5ns Reduktion bei der "random" Zugriffszeit" zu mem geben)

Kannst mir eventuell zum Screenshot die Zahlen schreiben?

Einfach die SD's für Single Sided dimms weg
Also so tief wie möglich rennen.
0 = Komplett Deaktiviert (nicht möglich auf AMD)
1 = Übersprungen, aber ODTEnableDly existiert.
2+ = Geladen und gegebenenfalls vom Controller korrigiert, fals zu niedrig.

Sie werden momentan als Puffer für 2ndaries benützt, aber du brauchst diesen nicht wirklich auf 16/24GB Single-sided DIMMs
Zb nur weil man Single Sided dimms rennt, heißt es nicht dass beide SD/DD/SC_Long nicht rennen~
Alles was du eingibst wird geladen. Manchmal durch SPD Hub logic übersprungen (wie zb das _L'ongs aktiv vermieden werden), aber alle Offset Timings werden aktiv draufgeladen.
Bloß hast du mit Single-Sided Dimms keinerlei Vorteil durch die _SD's. Mit den _DD's allerdings schon

Beitrag automatisch zusammengeführt: 14.12.2023

1 = Übersprungen, aber ODTEnableDly existiert.
2+ = Geladen und gegebenenfalls vom Controller korrigiert, fals zu niedrig.

Das selbe bei tWRRD.
Wird eigentlich auf Single-Sided DIMMs nicht benötigt.
Wert 1 = skip, instant
Wert 2+ = Geladen und potentiell korrigiert fals zu tief.

Kann man als Pause verwenden, muss man aber nicht.
Ich nehme es aus syncronizationsgründen zu anderen Timings bzw für PHYRDL und W/RPRE Delays.
Und weil der tWTRS Exploit auf 4 (half) nicht einfach zu rennen ist + jede Timing operation einen kleinen "breathing delay" irgendwo braucht * . Abseits dem Controller (PHY/ODT) delay.
Dafür ist RTP & WR eigentlich da, aber ich mag den Einfluss nicht welche diese Timings haben. WRRD und DD's sind gute Pufferzonen & Subchannels existieren. Somit passen sie gut~
* Einige persönliche Gründe.

Beitrag automatisch zusammengeführt: 14.12.2023

@Gr3yh0und

Bitte zuerst mit TM5 dann wieder mit Karhu gegentesten
Mir gefallen von Grundauf nicht deine RTTs (unnötig stark)
Zwischen WRRD 3 und 6, bzw 4 - solltest du gegentesten können. Mit Benchmate, Pyprime 2B (5x öffnen, Realtime Priority & consistency zwischen den Run's testen ~ bzw hier screenshotten und hier hochladen)
Oder TM5 sollte dir (wegen den SCL's) schon vorher schreien 🤭

Du hast noch viel Spielraum mit FCLK ~ aber später dann.
Denke 8000MT/s bzw eigentlich sollte 8800MT/s dein Ziel werden.
Alles dazwischen ist broken.
Nachdem alle ODTs & RTTs passen~