Leserartikel AMD Ryzen - RAM OC Community

[Raptor85]

Ok, interesting. Hatte ich noch nie, dass das nicht läuft.

Wie @MehlstaubtheCat anfangs sagte: Mein meine ICs sind halt nicht die geilsten.
Irgendwo musste ich da ja auch an eine Grenze kommen, die "eigentlich" noch laufen sollte.

Kurzer Zwischenstand dazu:

• tRCDRD = 19
• tRRDS/tRRDL/tFAW = 4/6/16

Fehler nach knapp 1 1/4h. Mein Kit hat also klar eine Schwäche bei tRRDS/tRRDL/tFAW.
Ich probiere es dann nächste Nacht mit 6/6/24 testen und tRCDRD dann wieder auf 18.

 

[Tronado]

Wie lange hast du gebraucht, um das jetzige RAM-Setup zu definieren?

Nicht so lange. Wichtig ist, dass man die CO Kurve erstmal auf Standard lässt, PBOSC auf auto und ohne OC den RAM ausprobiert. Sonst kommt man schnell durcheinander. Ist schwer manchmal, RAM-Fehler und OC/UV-Fehler auseinanderzuhalten.

 

[qiller]

Mein Kit hat also klar eine Schwäche bei tRRDS/tRRDL/tFAW.

Sieht fast danach aus. Hab ich zwar noch nicht gehabt, aber hatte auch noch nicht mit 2x 32GB Modulen zu tun. Von daher gut möglich, dass es da bei den voller bestückten Modulen mehr Probleme gibt. Ist nur schade, weil tRRDS/tRRDL/tFAW zusammen mit tRFC und den Haupttimings auch am meisten beim RAM-OC auf AM4 bringen.

 

[Tronado]

Ich wusste nicht dass man TRP, TRAS und TRC so weit herunterschrauben kann. Erst in den Skatterbencher- und anderen OC-Videos hab ich es gesehen. So läuft es jetzt:

Gehe ich noch tiefer, merkt man irgendwann wie der Durchsatz wieder sinkt, vielleicht durch Fehlerkorrekturen. Trotzdem läuft dann der OCCT RAM-Test noch ohne Fehler 10 Minuten durch.
CPU-Takt +200 kann ich aber vergessen, das war auch beim 265K so, hoher Takt heißt weniger RAM-Potential. VSoc kann man trotzdem gesund begrenzen, VDDIO muss hoch bleiben über 1,4V, sonst geht nicht viel beim RAM. Aber das kann am alten Board liegen.

 

[Raptor85]

Ich probiere es dann nächste Nacht mit 6/6/24 testen und tRCDRD dann wieder auf 18.

Nach 1:40h sagt Karhu: Nö, ich mag nicht mehr.
Ich denke, von den 6/8/34, die stabil laufen, komme ich wohl kaum mehr runter.

Ist nur schade, weil tRRDS/tRRDL/tFAW zusammen mit tRFC und den Haupttimings auch am meisten beim RAM-OC auf AM4 bringen.

Dann können meine ICs da wohl nicht viel beitragen, was das betrifft. Schade.
tRFC ist ja zumindest halbwegs okay. Und die Haupttimings ganz solide. Jetzt alles nicht übertragend, aber akzeptabel.

 

[qiller]

Nach 1:40h sagt Karhu: Nö, ich mag nicht mehr.

Strange. Der Typ im Luxx, der praktisch dasselbe Setup hat wie du, hatte auch komische Werte für tRRDS/tRRDL/tFAW. Denke aber bei dem wird irgendne Fehlerkorrektur gelaufen sein (tFAW müsste bei dem eigt. 28 sein). Ansonsten probier noch die tFAW runterzubekommen: 6/8/24 o. 6/8/30.

Hier hab ich noch 2 im Thread mit Zen2 (ist ja derselbe IO-Die) gefunden:

4/4/16 @3733MT/s
https://www.hardwareluxx.de/community/threads/micron-16gbit-b-die-ddr4.1276765/page-9#post-28045805

5/8/20 @3600MT/s
https://www.hardwareluxx.de/community/threads/micron-16gbit-b-die-ddr4.1276765/page-3#post-27719987

 

[Raptor85]

Danke! An den Thread im Luxx hatte ich zuletzt gar nicht mehr gedacht.

Aber da Durchsatz über Timings geht, muss ich natürlich schauen, dass ich bei 3800 MT/s bleibe.
Aber man sieht auch an dem Beispiel mit 3600 MT/s, dass es da nicht immer ganz nach oben geht. Wobei das ggf./wahrscheinlich auch noch etwas suboptimale Timings sind.

Der Typ im Luxx, der praktisch dasselbe Setup hat wie du, hatte auch komische Werte für tRRDS/tRRDL/tFAW.

Wenn man sich die restlichen Timings anschaut, ist das aber auch ne Art Golden Sample mit zusätzlichem Jackpot! Wenn das wirklich fehlerfrei läuft (angeblich ja, laut Screenies). Sogar mit GDM off.
Aber dann sowas wie tRCDWR bei 8. Holy Moly!

 

[qiller]

Aber da Durchsatz über Timings geht, muss ich natürlich schauen, dass ich bei 3800 MT/s bleibe.

Klar, das war auch nicht als Vorschlag auf 3733MT/s runterzugehen zu verstehen. Nur bei Timings muss man ja auch immer bisschen die Taktfrequenz im Auge behalten. Wenn da echt nichts mehr geht, dann lässt du das natürlich so. Auf 3733MT/s würd ich da auch nicht runtergehen.

 

[Raptor85]

Hui, bei 6/8/24 ist er mir eben schon nach 29 min ausgestiegen. Das lief schon besser vorher mit niedrigeren Timings. Mein PC ist wohl auch nach der Woche durch.

Gut, dann noch ein letzter Versuch auf 6/8/30.

 

[qiller]

Ich würde auf jeden Fall nochmal 6/8/34 validieren, wenn jetzt 6/8/30 auch aussteigt. Das Problem hatte ich auch schon oft. Man hatte ein Zwischen-Setting eigt. schon als stable markiert, dabei war es das gar nicht zu 100%. Teilweise temperaturabhängig. Solche hohen Timings bei tRRDS/tRRDL/tFAW sind auf jeden Fall ungewöhnlich.

 

[Pizza!]

Bei mir geht nix unter 8/8/32, zumindest das sollte doch laufen.

 

[qiller]

Wir reden hier ja von DDR4.

 

[Raptor85]

Also nen etwas kürzeren Run von 2-3h gebe ich ihm noch (um auszuschließen, dass er wieder nach so kurzer Zeit aussteigt).
Aber auf 8/6/34 lief er von Anfang an, als ich mit dem RAM OC angefangen habe. Und ich habe sicher knapp 10 12h-Runs gemacht mit all den anderen Timings. Wenn da was wäre, hätte ich das sicherlich schon gemerkt.

Dann liegt da halt die Achillesverse meines Kits. Nicht geil, aber ist dann leider so.

 

[Raptor85]

Kapier ich jetzt nicht. War doch zuvor alles stabil. Und er ist ja jetzt echt früh ausgestiegen.

Mit exakt den Timings hab ich schon erfolgreich 12h testen können. WTF!?

Die CPU hängt zwar teilweise an den 80°C mit all den zusätzlichen Stressfaktoren, aber das ist schon die ganze Zeit so. Klar, WLP wollte ich mal dieses Jahr neu machen. Aber das bringt jetzt sicherlich auch nur ein paar Grad.

 

[qiller]

Genau das meine ich :>. Es lag nämlich gar nicht an den tRRDS/tRRDL/tFAW Settings. 6/8/34 ist ja praktisch Autosettings und die sind immer eher konservativ gesetzt.

Edit: Mein Vorschlag. Erstmal noch etwas entschärfen
-tRC = 66
-tRFC = 600

Und dann würde ich nochmal tRCDRD prüfen, ob 18 wirklich 100% stable ist. Ich vermute nämlich mal, dass der Fehler da herkommt.

Edit: Besser @MehlstaubtheCat 's Entschärfungsvorschlag nehmen.

 

[Raptor85]

Und jetzt? Am ehesten denke ich, dass es noch an tRAS, tRC oder tRFC liegen kann.

Boah, nee! Liebes Kit, lauf doch endlich mal einfach. Das würde mich echt glücklich machen.
Seit Anfang Januar hänge ich dran (auch wenn die Vorgehensweise anfangs nicht die richtige war).

 

[MehlstaubtheCat]

Hi!

Ich würde die tRCDRD auf 20 setzen,
tRC sogar auf 68 probieren und tRFC wäre dann eine 612 ( tRC * 9)
Wenn das nicht geht mal tRC * 10 = 680.


Gruß
Mehlstaub

 

[Raptor85]

Danke! Ich habe jetzt erstmal nur tRC und tRFC hochgesetzt. Wenn der Fehler bei tRCDRD liegt, sollte ich das in spätestens 2h wissen.

 

[Raptor85]

Man nähert sich des Pudels Kern. Abbruch des Tests "erst" nach 2:43h.

Jetzt ist die Frage, ob ich tRCDRD trotzdem auf 20 hochsetze und dann teste oder erstmal tRFC auf 680.

 

[Raptor85]

Es lag an tRC/tRFC.

Gut, dann ist halt vor allem tRFC jetzt echt hoch. Aber was willste machen.
In der CL16-Baseline (vor Optimierung der Timings) standen da 80/660. tRFC ist jetzt sogar leicht schlechter, aber gut, is halt jetzt so.

Ich hatte da so ne Vermutung, weil Karhu auch vor ein paar Wochen schon mal so nach 2:45-3:00h weggeknickt ist. Und da hatte ich auch vor lauter Verzweiflung schon 16-20-20-20 bei den Primärtimings am Laufen. Nur da war der Fehler noch nicht so gut einzugrenzen.

Jetzt kann ich wenigstens wieder tRRDS/tRRDL/tFAW = 4/6/16 versuchen. Vielleicht läuft das ja jetzt.