Leserartikel AMD Ryzen - RAM OC Community

[morph027]

Hm, da ich meine FCLK ja nicht auf 1900 bekomme hab ich mich erst mal an die trfc gesetzt und laut Reos Serviervorschlag für die S8B Dies auf 261 gesetzt. Test lief soweit durch.

 

[qiller]

Deine VSoc ist viel zu hoch. Stell die erstmal fest auf 1.1V, passt bei 1866MHz fast immer. Erst ab 1900MHz muss man evt. leicht anheben.

 

[tusen_takk]

Meine Empfehlung: Warte mal noch mit dem CO so ca. ne Woche und zocke jetzt ordentlich. RAM-OC kann durchaus auch grenzstabil sein. Morgens gelüftet und im Kalten mal ein Spiel gestartet und auf einmal stürzt der Rechner ab, obwohl zig RAM-Tests problemlos durchliefen. Alles schon gehabt^^.

Lief eine Woche jeden Abend 1-2 Stunden ohne Probleme, von Shootern über RPG und Strategie. Danke, jetzt geht's in Richtung CO.

Weiterhin viel Erfolg @Raptor85, bald kannst du deinen Rechner auch ohne Tests nutzen. 🥳

Was mich allerdings tatsächlich noch interessiert, wäre, ob ich mit der kommenden Karhu-Version vielleicht andere Instabilitäten finden würde.

 

[morph027]

Deine VSoc ist viel zu hoch. Stell die erstmal fest auf 1.1V, passt bei 1866MHz fast immer. Erst ab 1900MHz muss man evt. leicht anheben.

Ja, hab sträflicherweise noch alles auf Auto, das BIOS neigt da irgendwie bei allen Spannungen zur Übertreibung

 

[MehlstaubtheCat]

Hi!

@Raptor85

Ich bin hier im Thread für ca. 1 -1 1/2 Woche nicht mehr zu Gange
Private Umstände!

Nicht das du auf eine Antwort wartest.

Gruß
Mehlstaub

 

[Raptor85]

Nicht das du auf eine Antwort wartest.

Dann warte ich halt etwas länger auf eine Antwort. Mein "Status" ist ja schon ein ganz ordentlicher. Kann erstmal so laufen, wenn der Test auch erfolgreich ist.

Dann viel Glück/Erfolg/alles Gute bei deinen privaten Dingen! Nimm dir die Zeit, die du brauchst.
Bis dann!

 

[Raptor85]

Es geht leider in die Richtung, dass ich fast das gesamte Feintuning wieder zurücknehmen muss.

Am Ende hatte ich nach ein paar kürzeren Runs (bei denen ich nach und nach die Timings wieder angehoben hatte) noch einen, der knapp 6h durchlief, bevor es einen Fehler gab.
Das ist schon mal nicht so schlecht, aber natürlich kein Dauerzustand.

tRCDWR teste ich jetzt noch auf 18 (zuvor 17) und hoffe, dass das dann seine 12h gut macht. Aber das wohl erst Anfang der Woche.

Hier noch die ZenTimings. Temporär hab ich wieder die UV/CO-BIOS-Settings drin. Beim erneuten RAM-Test werden die selbstverständlich wieder rausgenommen.

 

[Raptor85]

Gut, an tRCDWR 17 oder 18 lag es jetzt wohl nicht zwingend. Ich habe nach knapp 4,5h Karhu den ersten Fehler gehabt. Mag auch am GDM = on liegen.
Jedenfalls komme ich jetzt erstmal nicht weiter. Ich warte aber gerne auch darauf, dass Mehstaub wieder da ist.

 

[morph027]

Kurzer Zwischenruf. Ist es irgendwie sinnvoll den RAM zu undervolten? Hab mal kurz etwas dran gedreht, aber da hat sich in den DIMM Temperaturen nicht so viel getan.

 

[Garrus]

RAM skaliert mit Spannung. UV kann RAM instabil werden besonders wenn man Timings straff zieht.

 

[morph027]

Ja gut, das ist ja bei CPU/GPU ähnlich. Aber da lohnt sichs bis zum Sweep Spot ja wegen der Temperaturen. Aber wenn das kaum lohnt und der Samsung ja sowieso recht viel abkann, dann lass ich da weitere Versuche einfach sein.

 

[Raptor85]

Bei RAM gibt es so was wie Temperaturprobleme ja eigentlich nicht. Und (daher) auch keine nervigen Lüfter.
Und ja, bis zu einem gewissen Wert ist es ziemlich unkritisch dem RAM mehr Spannung zu geben (auch auf lange Zeit gesehen).
Fürs Rumfrickeln, Spaß an der Freude und die Statistik kann man zwar mal damit, also UV, rumspielen, aber es hat keinen spürbaren Mehrwert im Ggs. zu CPUs/GPUs.
UV + OC bei GPUs kann ja regelrecht kleine Wunder wirken, wenn man einen guten Chip hat (viel weniger Verbrauch bei teilweise sogar gestiegener Leistung). Mit UV + OC bei RAM hat man eher keinen Spaß. Auch nicht bei guten Chips.

 

[qiller]

Solang wir hier nicht von richtig vielen Speicherchips sprechen (siehe Serverbereich), sind die Energieeinsparungen beim RAM eher marginal. Ich sehe immer sowas wie ~1.1W Leistungsaufnahme pro DDR5-Modul. Bei DDR4 sollen es 1.2W sein. Ist halt ein Witz gegenüber das, was man bei CPUs oder erst recht bei Grafikkarten an Energie einsparen kann.

Edit: Ich vermute mal, die Werte sind mit Jedec-Settings. Mit XMP/EXPO und mehr Spannung wird die Nachkommastelle sicherlich etwas höher ausfallen.

 

[Jaffech]

Bei RAM gibt es so was wie Temperaturprobleme ja eigentlich nicht.

Doch gibt es und ist der limitierende Faktor beim Tuning.
tREFI ist direkt Temperaturabhängig und je höher tREFI, desto besser.
Und daher gilt: Niedrigere Temperatur = höheres tREFI = höhere Leistung.
Insbesondere, weil tREFI mit eines der Performance relevantesten Timings ist.

Edit:
Bevor du dich fragst wieso tREFI hoch gut ist: tREFI ist die Zeit zwischen zwei refreshs (tRFC). Und je länger man den Refresh herauszögern kann, desto länger kann der RAM arbeiten bevor er im Refresh steckt und nix machen kann.

Und (daher) auch keine nervigen Lüfter.

Und daher Lüfter fürn RAM ("Ghetto Mod") oder direkt Wakü
Insbesondere bei DDR5 und vor allem bei DR Modulen kann ein Lüfter helfen tREFI zu stabilisieren.
65k tREFI kann teilweise schon bei 55°C Probleme machen(da der Sensor nicht im Chip, sondern aufm PCB sitzt ist das natürlich variabel), das erreicht man selbst mit moderaten Spannungen relativ schnell, bei DR Modulen ist das fast schon Gesetz.

Bei AM4 ist das aber natürlich vollkommen wurscht, weil tREFI kann man sowieso nicht einstellen, das bleibt hardstuck bei JEDEC Vorgabe.
Bei Intel ist man auch nicht bei 65k tREFI limitiert, da kommts dann teilweise auf jedes Kelvin an wenn man aufs ganze gehen will ^^

Solang wir hier nicht von richtig vielen Speicherchips sprechen (siehe Serverbereich), sind die Energieeinsparungen beim RAM eher marginal. Ich sehe immer sowas wie ~1.1W Leistungsaufnahme pro DDR5-Modul.

Im Idle vielleicht. Unter Last können das je nach Spannung auch gerne mal 4-6W sein (pro Modul bei SingleRank), sprich wenn man TM5 oder Karhu anwirft.

Aber du hast natürlich Recht, dass im Serverbereich völlig andere Dimensionen an Verbrauch statt findet. Lass mal ein 16 Channel System mit DualRank RDIMMs laufen... da biste locker flockig bei 100-200W nur für den RAM^^

Bei DDR4 sollen es 1.2W sein. Ist halt ein Witz gegenüber das, was man bei CPUs oder erst recht bei Grafikkarten an Energie einsparen kann.

1.1W bei DDR5 und 1.2W bei DDR4?
Kommt mir irgendwie so vor als verwechselst du gerade Watt mit Volt.

DDR5 ist für 1.1v spezifiziert und DDR4 für 1.2v, also zumindest nach JEDEC.
Deine 1.1 "W" bei DDR5 und 1.2 "W" bei DDR4 klingen zumindest stark nach Verwechslung, zumal selbst SR DDR5 Module weit über 1.1 W verbrauchen unter Last.


Aber ich würde jetzt auch nicht wegen Stromeinsparungen anfangen den RAM zu UVen. Wie schon angesprochen kann es dann Stabilitätsprobleme geben und wegen den 2, 3W die da eventuell möglich sind... Weiß ja nicht. Bei CPU und vor allem GPU ist massiv mehr Potential vorhanden.

 

[Raptor85]

@Jaffech Danke für die Info und Erklärungen. Wieder was gelernt.

 

[Jaffech]

@Raptor85 Hab gerade noch was zu tREFI und Intel hin editiert, weiß nicht ob du das gesehen hast

 

[bogge101]

Was fängt man mit den zusätzlichen Werten in der Beta Version an? (Gemini gibt folgende Infos)

Nitro
Die drei Zahlen stehen für spezifische Verzögerungswerte (Delays) in Taktzyklen, die der Speichercontroller für bestimmte Signale nutzt:
1. (Nitro RX Burst): Verzögerung beim Empfangen (Receive) von Daten.
2. (Nitro TX Burst): Verzögerung beim Senden (Transmit) von Daten.
3. (Nitro Control Line): Zusätzliche Latenz auf der Steuerleitung (Command Line).

tRDPRE (Time Read to Precharge) bestimmt, wie viele Taktzyklen der Controller warten muss, nachdem ein Lese-Befehl (Read) gesendet wurde, bevor er den Schließ-Befehl (Precharge) senden darf. Dieser Wert hängt oft direkt mit dem bekannteren Timing tRTP (Read to Precharge) zusammen.

tWRPRE (Write to Precharge) bestimmt, wie lange gewartet werden muss, nachdem ein Schreib-Befehl (Write) gesendet wurde, bevor die Bank per Precharge geschlossen werden darf. Dieser Wert basiert meist auf dem Haupt-Timing tWR (Write Recovery).

 

[qiller]

1.1W bei DDR5 und 1.2W bei DDR4?
Kommt mir irgendwie so vor als verwechselst du gerade Watt mit Volt.

Ne, findet man halt "so im Netz". Wie gesagt, die Werte werden wahrscheinlich mit Jedec-Settings sein. Aber so ganz glaub ich das auch nicht, dass das so wenig sein soll. Vlt. mit LPDDR, ka. Crucial meint selber, man soll mit 5W pro Modul rechnen.

Wer wirklich Leistungsaufnahme beim RAM einsparen will, sollte halt die Finger von XMP/EXPO lassen, und maximal 2 Module für den Dualchannel einbauen.

 

[Jaffech]

Ne, findet man halt "so im Netz".

Reddit... klingt aber so als würde er Watt und Volt verwechseln, zudem gehts da um SODIMM. Und das andere... naja die ändern ihre Watt Werte auch jeden Absatz und meinen dass RAM Takt in "MHz" angegeben wird, was schlicht falsch ist. Nichtmal Geizhals gibt MHz an, sondern korrekterweise MT/s. Würde da gar nicht viel drauf geben^^

Einfach in HWinfo schauen was dein RAM so verbraucht

Crucial meint selber, man soll mit 5W pro Modul rechnen.

Sage ich ja, so 4-6W unter Last sind eigentlich normal

Wer wirklich Leistungsaufnahme beim RAM einsparen will, sollte halt die Finger von XMP/EXPO lassen, und maximal 2 Module für den Dualchannel einbauen.

Wer anfängt seinen RAM wegen 2W zu UVen, sollte lieber ein SteamDeck kaufen, das braucht nur 15-25W. Oder halt den SoC statt "auto" einfahc um 0,05v senken, hat vermutlich sogar nen größeren Effekt.

Ergänzung (22. Januar 2026)

Was fängt man mit den zusätzlichen Werten in der Beta Version an?

Die Nitro Settings konnte man schon vorher anschauen auf der erweiterten Ansicht ^^

(Gemini gibt folgende Infos)

Nitro
Die drei Zahlen stehen für spezifische Verzögerungswerte (Delays) in Taktzyklen, die der Speichercontroller für bestimmte Signale nutzt:
1. (Nitro RX Burst): Verzögerung beim Empfangen (Receive) von Daten.
2. (Nitro TX Burst): Verzögerung beim Senden (Transmit) von Daten.
3. (Nitro Control Line): Zusätzliche Latenz auf der Steuerleitung (Command Line).

Je straffer, desto mehr Performance, aber desto instabiler.
1/2/0 ist für 6000 MT/s eigentlich üblich und klappt auch meist. 1/2/1 oder 2/3/1 oder 1/3/1 kann ggf. für 6400 MT/s nötig sein

tRDPRE (Time Read to Precharge) bestimmt, wie viele Taktzyklen der Controller warten muss, nachdem ein Lese-Befehl (Read) gesendet wurde, bevor er den Schließ-Befehl (Precharge) senden darf. Dieser Wert hängt oft direkt mit dem bekannteren Timing tRTP (Read to Precharge) zusammen.

tWRPRE (Write to Precharge) bestimmt, wie lange gewartet werden muss, nachdem ein Schreib-Befehl (Write) gesendet wurde, bevor die Bank per Precharge geschlossen werden darf. Dieser Wert basiert meist auf dem Haupt-Timing tWR (Write Recovery).

Gibt noch viel mehr Timings.
Bei AMD (und auch Intel) kann man bei weitem nicht alle Timings auslesen oder setzen. Gibt ja noch sowas wie tWPST, tRPST, tRTRS, tRDDQS, usw.
Die werden halt einfach automatisch trainiert ohne dass wir davon Kenntnis haben.

Bin mir aber gerade nicht sicher tRPRE einstellen zu können. Bei neueren BIOS Versionen habe ich aber zumindest tWPRE schon gesehen

 

[qiller]

Einfach in HWinfo schauen was dein RAM so verbraucht

Oh, hab ich da was verpasst? Also ich seh nur den Takt, Spannung, Timings, DIMM-Temperaturen bei mir. Verbrauch der RAM-Module gibts bei mir nich :|. Oder gibts die Anzeige erst mit DDR5-Speicher?