[Sammelthread] Ryzen DDR5 RAM OC Thread

Mich hat diese 3:2 Regel noch mal beschäftigt, habe deshalb mal ein paar Messungen angestellt

Grundlage ist folgendes RAM Setup mit 6400Mhz jeweils bei 2133 (3:2) bzw 2200 FCLK
Screenshot 2025-01-08 121659.png


Mittelwert aus je 20x Runs AIDA Latency im Abgesicherten Modus (damit möglichst wenig Einfluss von "außen")

Screenshot 2025-01-08 121523.png


Ich messe tatsächlich "keinen" Unterschied ob der FCLK nun 3:2 läuft oder nicht
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es lag wohl an den Spannungen... tWRRD 1 statt neu 2 wird nicht für die Neustarts verantwortlich gewesen sein. Ich hatte im letzten Run VDD / VDDQ / VDDIO um 0,2V gesenkt und prompt gab es nach ~25 Min. den Neustart. VDDIO wieder 0,2V hoch und Blend lief 45 Min durch. Ich probiere gleich VDD und VDDQ um 0,2V runter... VDDQ kann ich ja quasi frei einstellen, nur nicht über VDD gehen.

2025-01-08.png


Auf der 1. Seite steht, das VDD und VDDIO gleich eingestellt sein sollen - ist aber kein Muss, korrekt? Würde dann VDDIO auf 1,4V eher Stress oder bessere Stabilität bedeuten?
 
Hab jetzt mal mit den alten Settings Karhu laufen lassen, hab aber die VDD zumindest mal runtergedreht. 1,47V hat fehler bei 300% geworfen, 1,50V lief jetzt über Nacht durch. Nur wenn ich jetzt anfange an den anderen Timings zu drehen geht das ganze ganz schnell in 2F, 2A oder manchmal im zweiten Training sogar 00 im DEBUG, da ging mir schon kurz die Muffe.
1,5V VDD für deine Timings ist gut. Weiter herunter kommst du auch mit noch besseren Kits nicht, hängt einfach von mehreren Faktoren ab.

Du könntest noch das probieren. In Karhu fehlen dir noch 3MB/s, ist halt auch aus dem RRD_L & WTR_L geschuldet. Du kannst für RDD_L = 8 & WTR_L = 16 probieren. tWRWRSCL sollte eigentlich auch mit 1 laufen, ändere aber erstmal nur schrittweise.
1736335621896.png

Beitrag automatisch zusammengeführt:

Auf der 1. Seite steht, das VDD und VDDIO gleich eingestellt sein sollen - ist aber kein Muss, korrekt? Würde dann VDDIO auf 1,4V eher Stress oder bessere Stabilität bedeuten?
VDDIO & VDDQ sind bis 1,5V "safe". Viele CPUs mögen aber keine hohen VDDIO Spannungen weswegen hier meist 1,45V das Limit ist, sieht man auch an den ganzen Expo/XMP Profilen.
VDD/Q kann man im Alltag bis +1,51V oder höher (kommt auf die Kühlung an) betreiben. VDDQ muss auch nicht VDDIO matchen, es kann aber der Stabilität zugutekommen.
Die Spannungen welche die CPU wirklich belasten & Energie fressen sind VSOC & CLDO VDDP.
Beitrag automatisch zusammengeführt:

Ich messe tatsächlich "keinen" Unterschied ob der FCLK nun 3:2 läuft oder nicht
Es wird sich im Endeffekt nicht viel schenken. Solange dein FCLK bei 2200 stabil ist, würde ich es so belassen. Die paar MB mehr Bandbreite beim single CCD wäre mir wichtiger.
 
Zuletzt bearbeitet:
Mich hat diese 3:2 Regel noch mal beschäftigt, habe deshalb mal ein paar Messungen angestellt

Grundlage ist folgendes RAM Setup mit 6400Mhz jeweils bei 2133 (3:2) bzw 2200 FCLK


Mittelwert aus je 20x Runs AIDA Latency im Abgesicherten Modus (damit möglichst wenig Einfluss von "außen")



Ich messe tatsächlich "keinen" Unterschied ob der FCLK nun 3:2 läuft oder nicht
Zu dem Schluss bin ich auch gekommen. 3:2 hat keine Vorteile bei mir.
 
Da ich nach Beitrags-Meldungen @Tatilica dazu gerade schon per PM angeschrieben habe und mir dies auf den letzten Seiten auch bei anderen Usern aufgefallen ist, hier auch noch mal der allgemeine Hinweis für alle:

Bitte bindet Screenshots in hohen Auflösungen (FHD+) ausschließlich als Thumbnails und nicht als Full Size Images ein.
Selbiges gilt für Beiträge, die mehr als ein einzelnes Bild enthalten. Man kann im Forum zwischen mehreren eingebetteten Grafiken blättern.
Bilder sind gemäß §7 der Forenregeln aus Zitaten zu entfernen. Der Bezug wird durch den Beitragslink (weißer Pfeil) trotzdem klar.


All dies dient der besseren Lesbarkeit des Forums, nicht nur für Mobile User.
 
Thx for inline helping PM, appreciated, I replaced all the large full size images in my post, cheers 🙏
 
Ycruncher is a good tool and you should run all the tests there to generate enough stress and heat on the CCDs and IOD, because the high heat development often causes problems (especially with the IOD).
Hi, maybe I'll do all checked tests some day, but I always kept my own stability testing route for Ryzen, suggested here on Luxxe by master Jedi @Veii itself, it was my first lesson received from him years ago, whom I salute him by this way coz we miss him much on Luxxe already 🙏
I never saw someone here using Ycruncher N64 combo FFT/VT3, why just but only Karhu or only TM5 alone, coz I know surely your CO-30+ in range won't work and will crash by cores in no time if not stable enough, that's why y don't following better this route posted Here in a profi matter way 🙃
With TM5 50cycles passed on both 1usmus or Absolut in early debut mems testing, for checking timings only, and after than 50cycles Ycruncher FFT/N64/VT3 for harder AVX2 datashet scenario, you'll find your stability soon, and if all fine & passed well all stable, lately final run Karhu test with Cpu cache Enabled minimun 12h+ or 24h for better confidence will validate y Profile as stable indeed.
Frame times and frame drops are a good indicator of whether settings are working or not. Especially in games, different areas of the CPU are dynamically loaded, which can detect some errors and lead to crashes.
Oh boy, I did tested at last CP Liberty and founded lately harder Starfield on most demanding workload, coz was frezzing my build in no time cause wrong mems setup & CO-30 too short indeed, I can tell 👍
Beitrag automatisch zusammengeführt:

Anhang anzeigen 1062604
I always try to do a multi step approach, so my "stable" (which everyone defines differently of course) is more like: TM5 1usmus for identifying issues quickly (~1,5h), then 2-3h TM5 anta777 (more temperature on RAM) and then going over to 25k+ on Karhu. Normally then also followed by some hours of P95 Blend (for overall stability). Then some rounds of BF5 as this was in the past also very itchy in my experience.
Hi, understood your stable route, very similar to mine, posted already to @Vince96 my way, just but I find always Prime more appropiate for Intel scenario, due to his different way approach of testing parts and Ycruncher & his harder testing suite, which fit better for Ryzen 👍
As for gaming, yeah Starfield stays my harder preffered one for stable testing scenario, cheers!
 
Zuletzt bearbeitet:
GDM (GearDownMode) auf aus stellen
FCLK entweder 2000 oder 2200 (das musst du testen, am besten in Game & mit Prime95 Large FFT (AVX on).
Beitrag automatisch zusammengeführt:


teste am besten mit Karhu, TM5 schwindelt eh oft du siehst halt nicht den Testspeed... (oder verwende die 0.12.3)

Wo finde ich den Gear Down Mode? Ich habe das gesamte Bios durchforstet und nur einen "Power Down Mode" gefunden, der scheint aber etwas anderes zu sein.
Außerdem: Ist es normal, dass bei FCLK 2200 MHz die Latenz um 15ns hochgeht?
 
Wo finde ich den Gear Down Mode? Ich habe das gesamte Bios durchforstet und nur einen "Power Down Mode" gefunden, der scheint aber etwas anderes zu sein.
Außerdem: Ist es normal, dass bei FCLK 2200 MHz die Latenz um 15ns hochgeht?
Das kann ich dir bei Gigabyte nicht sagen, es gibt aber im Bios unten rechts ein Lupe Symbol womit du es suchen kannst.
Die Latenz wird steigen aber 15ns ist viel, kann auch am GDM & oder an instabilen Timings liegen.
 
VDDIO & VDDQ sind bis 1,5V "safe". Viele CPUs mögen aber keine hohen VDDIO Spannungen weswegen hier meist 1,45V das Limit ist, sieht man auch an den ganzen Expo/XMP Profilen.
VDD/Q kann man im Alltag bis +1,51V oder höher (kommt auf die Kühlung an) betreiben. VDDQ muss auch nicht VDDIO matchen, es kann aber der Stabilität zugutekommen.
Die Spannungen welche die CPU wirklich belasten & Energie fressen sind VSOC & CLDO VDDP.
Ok, dann ist ja alles safe mit meinen Einstellungen... Hatte heute den ganzen Tag Blend getestet und das läuft jetzt stabil - also sofern einem 2 Std. ausreichen.

Screenshot 2025-01-08 184841.png

Ich war gar nicht soweit weg, am Ende waren es nur kleine Schritte (Neu / Alt). Teils konnte ich die Spannungen sogar noch etwas verringern. Vllt. hätte es letzte Woche auch gereicht, nur VDDIO leicht zu erhöhen. Da ich aber alle Spannungen angehoben hatte, blieb die Differenz ja gleich groß uns so kam keine Stabilität rein.

2025-01-08 (1).png
2025-01-02.png


Gibt es irgendwelche Einwände?

edit: Karhu ist auch durch... nun hoffe ich, das alles passt.

Screenshot 2025-01-08 223004.png
 
Zuletzt bearbeitet:
Wo finde ich den Gear Down Mode? Ich habe das gesamte Bios durchforstet und nur einen "Power Down Mode" gefunden, der scheint aber etwas anderes zu sein.
Außerdem: Ist es normal, dass bei FCLK 2200 MHz die Latenz um 15ns hochgeht?
Direkt im OC Tweaker Menü unter DRAM Timing Config ganz oben.
 
Zuerst mal Ycruncher da das bei mir zuerst abkackt (allerdings auch wenn die CPU Settings nicht passen) , mal sehen ob das auch längerfristig stabil ist, ich kann´s mir nicht vorstellen imho alleine wegen der relativ niedrigen Spannungen.
1736363623787.jpeg

1736363651199.png
 
Wie schafft Ihr mit 6000er so niedrige Timings?
 

Anhänge

  • Screenshot 2025-01-08 202416.jpg
    Screenshot 2025-01-08 202416.jpg
    101,2 KB · Aufrufe: 54
Zuletzt bearbeitet:
....da komme ich nicht dran, scheint sehr gut mit schnellen timings statt bandbreite zu skalieren.
Frag da mal am besten @Hoschi -Beitrag-

ach, sehe gerade vlt spielen ja die 64GB auch ´ne Rolle.
1736368742330.png


Apropos: @Phoenix2000 hast du deine 48GB bekommen ?
 
Zuletzt bearbeitet:
Irgendwas ist da gerade borderline stable bei mir, hab versucht erstmal die Spannungen noch leicht zu senken, das lief aber dann doch in Probleme (VDDIO 1,4 - 1,425 + VDDQ bis 1,4 runter). Mal Karhu, dann wieder TM5. Dann hab ich Reset auf die Settings von heute Nacht und jetzt fliegt mir TM5 wieder...

Muss ich morgen nochmal VDIMM erhöhen und nochmal die alte Baseline wiederfinden :/
 

Anhänge

  • 2025-01-08 23_55_57-HWiNFO® 64 v8.16-5600 - Sensors Status.png
    2025-01-08 23_55_57-HWiNFO® 64 v8.16-5600 - Sensors Status.png
    270,9 KB · Aufrufe: 20
  • 2025-01-08 22_57_46-.png
    2025-01-08 22_57_46-.png
    239,6 KB · Aufrufe: 20
kann man eigentlich sagen das ein 8 Kerner AMD generell weniger VSOC braucht als ein16er ?
 
Hoschi hat auch 6800er RAM und fährt 1,5v auf dem RAM, dass ist mir doch zu heftig :)
Aber vermutlich sind meine 69,2ns gar nicht so schlecht im Vergleich zur Basis.
Da liegst du falsch das wird durch eclk Übertaktung nur falsch angezeigt.Er ist eher niedrig im Rakt und hat dafür straffere Timings.
 
Hoschi hat auch 6800er RAM
In beiden geposteten Bildern, wie auch im verlinkten Beitrag von Hoschi, geht es ausschließlich um 6000er Profile. Welche RAM Sticks du verwendest, ist erstmal ein anderes Thema.


und fährt 1,5v auf dem RAM, dass ist mir doch zu heftig :)
Sehr stramme Timings, brauchen halt Spannung. Ich fahr 1,390v/ 1,360v, bei minimal schlechteren Timings. Vermutlich geht auch weniger.


Aber vermutlich sind meine 69,2ns gar nicht so schlecht im Vergleich zur Basis.
Ist halt noch gut Optimierungspotenzial vorhanden. Verglichen mit meinem 6000er Profil zu deinem:

Read: 63.809 vs 70.144 MB/s
Write: 89.103 vs 93.299 MB/s
Copy: 62.377 vs 66.363 MB/s

Theoretisch solltest du mit 64GB sogar etwas bessere Werte haben.
 
Mit dem LN2 Jumper kann man das Limit umgehen.
 
Die SWAP APU Geschichte habe ich btw wieder deaktiviert. Man gewinnt 400 MB/s im Read, verliert aber 2.000 MB/s im Copy. Zumindest mir ist es das nicht wert.

Zum Thema synchrone tPHYRDL, die CLDO VDDp oder andere Spannungen oder gar Widerstände anpassen, hat bei mir gar nichts gebracht was das synchrone Training der tPHYRDL auf beiden Bänken angeht.

Was bei mir aber endlich geholfen hat, das er die tPHYRDL auf beiden Bänken gleich trainiert, ist die Option: ARdPtrInitVal P0 Control auf 1. Man kann da 0, 1 oder 2 probieren. Und siehe da, er trained endlich nicht mehr unterschiedlich auf A2/B2.

Das nur mal als Tip, ich denke das läuft ja bei dem ein oder anderen unsynchron. Performance bringt es keine, aber zumindest wäre mal ein Weg gezeigt, wie man das auf 9000-Series tatsächlich fixen kann! Die Option ARdPtrInitVal P0 Control ist im BIOS nämlich nur für die 9000-Series verfügbar!

Screenshot 2025-01-06 165004.png


Statt 35/37 (AUTO) trainied er mit Init Val bei mir mit 1 35/35, mit 0 trained er 33/35, also wieder asynchron. Das muss man testen.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh