[Sammelthread] Ryzen DDR5 RAM OC Thread

[xST4R]

lol das ist komisch , hat vielleicht der windoof defender was blockiert ? im oc forum steht dazu auch irgendwas

 

[Induktor]

Liegt wohl an der Version 1856

Hab ich installiert, siehe Screenshot vom Donnerstag (Beitrag)

 

[Neon Knights]

lol das ist komisch , hat vielleicht der windoof defender was blockiert ? im oc forum steht dazu auch irgendwas

nun kann ich nicht mehr.... das KB deinstalliert (wird wieder angeboten) und dennoch...... da geh´ ich kaputt...

Beitrag automatisch zusammengeführt: Gestern um 19:03

ich mach jetzt mal den üblichen Kram : chkdsk -, sfc scannow usw....

 

[Tatilica]

It reads mine. I also have the update installed.

How did you get it to read VDDG? I also have an MSI, but it only has a Carbon Wi-Fi.

I also have MSI & Agesa 1.2.0.3a all info has been read

 

[webmi]

Neue Version zeigt jetzt zwar endlich die VDDG, dafür aber eine andere tWRPRE sowie auch bei mir die AGESA nicht mehr ...

Beitrag automatisch zusammengeführt: Gestern um 20:22

1856 zeigt mir die AGESA, zudem glaube ich hat er einfach tRDPRE mit tWRPRE vertauscht in der 1858!

Da muss er noch mal ran!

 

[Vince96]

Danke, aber ich kann mich im Moment nur wundern............... screen ist aber ohne Neustart..... aber mit Löschen der Dateien iv.bin und key.bin.

Anhang anzeigen 1146210

Es ist gut möglich das es nicht immer funktioniert. Die Methode wie er die Agesa ausließt ist aktuell noch Bruteforce.

 

[Neon Knights]

Ich würde sagen, 496 = 160ns läuft schlechter als meine 488. Muss ich einmal testen.
465 = 150ns sind 99%ig nicht möglich.

tRP = tCL+4 geht bei mir auch nicht, meine ich. Teste ich noch einmal.

komme von den 47 trp auch nicht runter - ist instabil mit Karhu fehlern oder direkt reboot.....

was ich auch interessant finde:
Das Apex hat bei denjenigen mit >7000 Mt/s Ram schön niedrige Dram DQDs Widerstände was ich bisher so gesehen habe.. Bei mir ist selbst 40 Ω schon instabil.

Edit für ein paar benches reicht es zwar ist auch messbar etwas schneller, aber was nützt mir das ?

 

[HardyEbw]

Den Punkt DramDqDs nehme ich direkt auf und checke damit nochmals mein 2:1 Profil, welches ich zuletzt nur fast stabil bekommen habe.👍

 

[Vince96]

komme von den 47 trp auch nicht runter - ist instabil mit Karhu fehlern oder direkt reboot.....

was ich auch interessant finde:
Das Apex hat bei denjenigen mit >7000 Mt/s Ram schön niedrige Dram DQDs Widerstände was ich bisher so gesehen habe.. Bei mir ist selbst 40 Ω schon instabil.

Edit für ein paar benches reicht es zwar ist auch messbar etwas schneller, aber was nützt mir das ?
Anhang anzeigen 1146315

Stell die CL auf 40 oder heb die Spannung an, dann kannst auch RP, RCDWR weiter anpassen.

 

[Vince96]

tRDWR = tCL - tCWL + BC8 + ODTEnDly (1) + WRPRE + SafetyDly (1)

Das kann aber nicht ganz stimmen, oder es fehlt etwas. Denn auch 8400 läuft mit RDWR 14 obwohl WRPRE 3. Es ist aber auch je nach Kit unterschiedlich, ob es funktioniert oder eben nicht.

 

[webmi]

Naja, das JEDEC Formeln kein Recht auf exklusive Richtigkeit der Funktion haben, wissen wir ja.

Außerdem ist das (tRDWR) ja nur ein minimaler Wert als Wartezeit, soweit ich das verstanden habe.

Zudem können wir die tCWL eh nicht ändern aktuell mit AM5, sodass sich da in der Formel eh schon ein „Fehler“ versteck und es aktuelle eben immer tCL - tCWL = 2 ist.

So sehr wundert es mich also nicht

 

[Vince96]

Naja, das JEDEC Formeln kein Recht auf exklusive Richtigkeit der Funktion haben, wissen wir ja.

Außerdem ist das (tRDWR) ja nur ein minimaler Wert als Wartezeit, soweit ich das verstanden habe.

Zudem können wir die tCWL eh nicht ändern aktuell mit AM5, sodass sich da in der Formel eh schon ein „Fehler“ versteck und es aktuelle eben immer tCL -2 ist.

So sehr wundert es mich also nicht

Die Jedec Formel ist schlichtweg nur die halbe Wahrheit. Mit einem anderen, etwas älteren Kit, läuft es nämlich nur mit 15+.
Der SafetyDelay ist also hier notwendig, oder das Problem der Berechnung liegt an der Formel selber oder dem Weg den AMD geht.

 

[webmi]

Ich denke vor allem der Umstand tCL - tCWL = 2 macht tRDWR unabhängig vom MT/s oder tCL eher zum pauschalen Ergebnis - festen Wert - und wenn ein System da mal +1 Delay (mehr) braucht, denke ich ist das als normale Schwankung in der Schärfe des Wertes selbst zu betrachten.

Aktuell muss man da gar nicht rechnen, es gilt tRDWR 14-15 sollten das Minimum sein das wir nutzen können, egal wie schnell der RAM taktet, egal welche Latency (tCL).

Warum wir tCWL nicht ändern können, wirft in mir ein größeres Fragezeichnen auf

Beitrag automatisch zusammengeführt: Heute um 14:11

Ich spiele gerade an der tRFC, bis dato hatte ich auf yolo-fist-try ja 368 / 115ns laufen

356 = kein Boot
357 = 111.5625ns
358 = 111.8xxxns

Die 357 laufen jetzt mal Extreme@anta777

Ist zwar ein krummer Wert dann, aber gleichzeitig auch das absolute Minimum und an sich sind 111ns schon ziemlich wild 😝

Ergebnis in hoffentlich 1.5h ☺️

Evtl komme ich danach mit 359 oder sowas auf gerade 112ns, damit es gerade ist 😂

 

[webmi]

SWAP APU und Latency Killer mit tRFC 360 / 112.5ns

112ns bzw eine gerader Wert geht nicht, ist immer krum, 111.5xxxns, 111.8xxxns, 112,1xxxns etc

 

[HardyEbw]

@webmi Du scheinst recht gehabt zu haben, ZenTimings 1860 zeigt einen anderen Wert für tWRPRE.
Auch läuft trotzdem tRDWR = 14.

 

[webmi]

1860 zeigt immerhin die AGESA wieder

PRE´s immer noch andere als in den Versionen zuvor

Beitrag automatisch zusammengeführt: Vor 2 Minuten

meanwhile endlich 80GB gemacht

 

[HardyEbw]

Meine tWRPRE ist zumindest eine andere als zuvor. Interessant.

Danke übrigens für den Tipp bzgl. AVX512!
Habe ich deaktiviert, CO -5 zusätzlich, Boost Override +25 zusätzlich, läuft wie Sau...😉