Leserartikel AMD Ryzen - RAM OC Community

Danke erstmal für Deine Tips @SeniorY !
Ich hab ja zum Glück mit Eurer Hilfe nen stabiles 6.200 Cl30er Setting gefunden - und dafür bin ich sehr dankbar!
Hat jemand ein HowTo geschrieben / zur Hand wie man schrittweise darauf aufbauend ein schnelleres Setting findet? Welche Timings lockern bevor man mit den Takt raufgeht etc... ich hab bisher den "roten Faden" noch nicht gefunden - vieles wirkt auf mich wie Trial & Error - und das versuch ich besser zu verstehen.
 
Verangry schrieb:
Und wie will man das herausfinden, ab welchem Timing die Fehlerkorrektur greift?
Nur so aus Sicht eines unerfahren Users.

Ach und was ist mit den Failsafe Werten?
Und was ist, wenn die Fehlerkorrektur so gut ist, dass es selbst mit Fehlern schneller ist als ohne und dabei auch keine Fehler entstehen, die das System korrumpieren?

Was ist mit den Timings die man nicht selbst einstellen kann?
Wie gut ist das Training und die automatische Einstellung der Widerstände?

Fragen über Fragen..

(PS: solange AMD da nicht alles offen legt bzw einstellbar macht, kann man eh "fast" alles einstellen was man will, solange es keine 2x32/48 oder Vollbestückung ist)

Sonst dürften einige Settings nicht Mal booten...
Anhang anzeigen 1455915

Sowas dürfte, wenn alles richtig funktionieren würde, nicht im Ansatz bootbar sein, aber solange das funktioniert kannst halt einstellen was du willst, solange es mehr performance bringt!
Kann man so machen, dann ists halt 💩. Man merkt ja beim gegentesten der Laufzeiten dass die "Dynamik" nicht stimmt. Oder man beharrt darauf, dass diese 💩Werte funktionieren und wundert sich dann, dass die Games ruckeln und das rendern länger dauert.
 
Also hast du auch keine Idee, wie man es testen kann welche Timings richtig sind und bis wohin es skaliert, bzw ab wann dann direkt die failsafe Werte greifen (und die sehr gute Fehlerkorrektur).

Kannst du doch so schreiben.

Von mir waren das tatsächlich ernstgemeinte Fragen, hätte ja sein können, dass es da inzwischen weitere Informationen zu gibt.

Stabilität schreibe ich sehr groß und ich vermute jeder andere würde das auch so sehen.

Aber wenn selbst die ganzen Tests alle ohne Fehlermeldungen durchlaufen, Spiele nicht ruckeln, keine Abstürze auftreten, wie soll man dann herausfinden was "richtig" und was "falsch" ist und was die ICs überhaupt können..

Und noch schlimmer ist, wie sollen das unerfahrene Benutzer es erkennen, eben wegen der nicht vorhandenen Fehler.
 
Zuletzt bearbeitet:
Sorry, war heute morgen etwas kurz angebunden.

Ich meine, Tests wie man Laufzeiten etc testet sollte einigermaßen bekannt sein. Gibt da ja verschiedene Ansätze wie 2,5b Benchmark YCruncher oder Linpack. Bei einigermaßen sauberen Windows sieht man auch, ob die AIDA Schreib-Lese-Durchsatz und Latenzwerte bei mehreren Läufen konstant sind. Wenn dies nicht der fall ist, greifen vermehrt Korrekturverfahren bzw die AMD-Ansätze der Dynamischen "Startpunkte" wie "tRAS/tRC" der IC's.
Um eine recht saubere optimierten DDR5 Standard Einstellung zu finden, kann für AM5 kann aus dem Hardwareluxx Thread der "DDR5 Timing Calculator for AMD" (Excel-Tabelle) genutzt werden. Veii hat dazu auch einige Erklärungen einfließen lassen. Damit hat man mMn eine vernünftige Grundlage für weiteres.
 
  • Gefällt mir
Reaktionen: Teckel Chef
Also hast du immer noch keinen Schimmer was die ICs selbst mit machen, danke mehr brauche ich nicht zu wissen.

Takt und Timings der unterschiedlichen ICs skalieren nicht selten mit Spannungen und wenn man diese Timings bis auf ein Minimum drücken will kommt man bei am5 zu keinem Ergebnis, da die Fehlerkorrektur(en) so gut sind, dass es selbst mit zu niedrig eingestellten Timings "fehlerfrei" und mit mehr Leistung durch alle Tests läuft.

Abweichungen in Benchmarks sind übrigens normal, da ja auch die CPUs unterschiedlich hoch boosten bei hoher und geringer Last und auch bei Temperaturschwankungen, eine Abweichung von X zu Y ist also vollkommen normal, selbst wenn man es "Stock" laufen lässt.

Solange da keine Möglichkeit gegeben ist das auf das kleinste Mögliche auszuloten kann man diese Ansätze (bei AM5) vergessen.

Immer wenn ich "Timing Calculator" lese wird mir schlecht, was wird da "kalkuliert"? Oder sind es nur vorher eingegebene Werte die dann abgerufen werden?

Gibt es eine Berechnungsformel?
Auf welcher Grundlage werden diese Kalkulationen ausgeführt und und und.
Es mag in der Theorie wie gesagt so sein, in der Praxis lässt sich das aktuell einfach nicht umsetzen und eben mit geringeren Timings als eigentlich "möglich" bessere Ergebnisse erzielen.

Aber jeder wie er will, Hauptsache stabil.


Nachtrag:
Ich habe mir mal die Excel-Tabelle angeschaut, Daten eingegeben und mir die Timings "berechnen" lassen.
Ergebnisse packe ich mal in den Spoiler.

Mit den angeblich "minimalen" aber "richtigen" Timings -> H24M tRFC 528 bei 6600 gibt es nicht mal -> habe ich schlechtere Werte, als mit meinen stabilen Werten und die sind stellenweise noch niedriger als es eigentlich (laut Theorie) machbar wäre (sein dürfte).
Erst immer meine Timings, dann im Vergleich dazu die aus der Tabelle "errechneten"
AIDA - my timings.jpg
AIDA - calculator - settings.jpg
LinePack Bench 1.jpg
LinePack Bench -calculator- settings.jpg
PyPrime 7 Runs My Timings.jpg
PyPrime 7 Runs calculator.jpg

Und da soll noch jemand sagen, einige Timings "müssen" so eingestellt werden wie es dort in der Tabelle aufgeführt wird.

Das stimmt eben nicht und man kann sich noch so sehr daran aufziehen, es bleibt einfach ein Problem mit AMD bzw der AM5 Plattform, dem Training und den hinterlegten Failsafe Werten, solange das alles nicht stimmt, kann man eben soviel Theorie nutzen wie man will, Benchmarks, Stabilitätstests und was weiß ich nicht noch sprechen eine andere Sprache.

Und auch RAM über 8000 wäre mit den normalen CPUs eine willkommene Erweiterung, dazu bedarf es aber ein SMU Update, die APUs (8700G etc) machen ja vor was möglich wäre.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: NameHere und cm87
Ich finde die Tabelle ist eine prima Grundlage, vor allem für Anfänger. Und sie funktioniert vermutlich in den allermeisten Fällen.

So weit liegt doch dein erarbeites Ergebnis vom -ach so schlecht- berechneten gar nicht auseinander. Hätte also eine super Grundlage für dich sein können. Ich freue mich immer, wenn ich so eine gute Hilfe bekomme.
 
ach du meine Güte...

Prinzipiell ist der Rechner keine üble Hilfe für Anfänger - wir greifen da lieber auf Presets zurück (auf Basisdaten der Community und verschiedenen Benchmarks - ich für mich am liebsten keine synthetischen Benchmarks) und "rechnen" auch zum Teil.

Was sich da jetzt in die Quere kommt ist die Meinung, dass man laut Datasheets nicht tiefer mit den Timings gehen darf/kann/soll oder was auch immer. Die Realität spiegelt aber was anderes - und Timings skalieren (je nach ICs) immer noch mit der Spannung (das Vorgehen wird in den Datasheets der ICs Hersteller nicht berücksichtigt). Dass die Fehlerkorrektur auch sein Ding macht, ist auch kein Geheimnis.

Hier trennen sich zum Teil die Wege der Theorie zur Praxis - und anstatt sich sachlich mit Daten und Fakten außereinander zu setzen, kommen nur irgendwelche Wall of Texts... @Verangry hat zumindest mal Benchmarks nachgereicht und gezeigt, dass es einen Unterschied gibt - man könnte auch mit weiteren Gamingbenchmarks ebenfalls den Gain und das Zusammenspiel von höherer Spannung und strafferen Timings zeigen.
 
Ich habe nie behauptet, dass es schlecht ist, ich habe mich nur an der Aussage gestört, dass einige Timings so und so hoch müssen, weil sonst die Fehlerkorrektur greift.

Daten belegen eben, dass man auch tiefer gehen kann als die Theorie es vorgibt, da AM5 was das angeht einfach undokumentiert ist und teilweise zu viele nicht einstellbare Timings hat, die dann bei jedem Start trainiert werden.

Das so eine Tabelle den unerfahrenen Nutzern vielleicht helfen kann ist klar, darauf zu bestehen, dass alle anderen Timings aber scheiße (oder falsch) sind und die Fehlerkorrekturen greifen, somit die Ergebnisse schlechter werden oder gar Systeme zum Absturz bringen ist halt nicht die feine englische Art, ganz besonders nicht, wenn man eben nicht weiß, ab welchem Zeitpunkt die Korrekturen greifen.

Ausloten der minimalst Timings (unterschiedlicher ICs) ist aktuell nicht drin und solange es mehr Leistung gibt, das System stabil ist, keine Ruckler auftreten und auch die synthetischen Benchmarks positiv auf geringere Timings reagieren, wieso also nicht einstellen?

Das und nur das ist die Aussage die ich treffen wollte.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SeniorY und ZeroCoolRiddler
Moin, ich wollte nochmal nachfragen ob meine Werte so passen bzw. stimmig sind?
Da öfters mal erwähnt wird, Wert X sollte das 4fache von Y sein oder so ähnlich.
ZenTimings_Screenshot.png
 
im großen und ganzen passt das. tREFI noch auf 65535, solange die Dimms nicht zu warm werden. Aber da sehe ich keine Gefahr. Falls das Hynix A-Die ist, geht tRFC auch 120 bis 130ns. Macht aber zu 160ns nicht den wirklich großen Unterschied.
 
  • Gefällt mir
Reaktionen: Iceman021
tRTP 12 und tRDWR 16 würde ich noch in den Ring werfen. tWRRD 4 oder gar 1 könnte man auch noch probieren, außerdem den zweiten *SCL ebenfalls auf 8.

Aber wie SeniorY schon sagte, am meisten bringt möglichst scharfe tRFC1 und max. tREFI.
 
tFAW ist besagtes Timing, dass 4x den Wert von tRRDS haben sollte.
Also in deinem Fall 16.

Sollte das nicht funktionieren, Versuche 6/12/24 , 7/14/28 oder 8/16/32.

Man kann auch 8/8/32 testen.

tWTRL den doppelten Wert von tWTRS.

Viele der Timings haben aber eh failsafe Werte hinterlegt, (FAW z.B. gehört dazu) die bei 2x16 und 2x24 irgendwann greifen.

Sobald 4 Dimms verbaut sind oder 2x32 / 2x48 ändert sich das Verhalten.
 
Verangry schrieb:
tFAW ist besagtes Timing, dass 4x den Wert von tRRDS haben sollte.
Also in deinem Fall 16.
hallo - ich lese hier ab und an man mal mit
fFAW ist bei Ryzen 7000 MemController auf 20 limitiert. Du kannst auch "1" eintragen. Der RAM Controller setzt es dann wieder auf 20.
Ergänzung ()

00_6400_OC_2024.png

hier sind meine 6400 Timings (sind glaube ich Hynix M-Dies)
Ergänzung ()

newtimings6400_2024_oc_2133fclk.png
 
Ich kann mir auch ein Loch ins Knie bohren und Wäsche drin waschen.

Ich sagte ja es gibt Failsafe Werte die automatisch gesetzt werden, wenn man zu tief ansetzt und dennoch gibt es teilweise mehr Leistung, weil die Korrekturen so gut sind.

Nachtrag:
Woher kommt die Annahme, dass tFAW 20 Minimum ist?
Wurde das von AMD mitgeteilt oder selbst getestet / heraus gefunden und wenn ja, womit?
 
Zuletzt bearbeitet:
Vielen Dank für die vielen Antworten.
tRefi kann ich so aktuell nicht weiter anheben. Ich habe den Wert Stufenweise getestet und mehr als 25K war nicht mehr stabil.
 
Verangry schrieb:
Ich kann mir auch ein Loch ins Knie bohren und Wäsche drin waschen.

Ich sagte ja es gibt Failsafe Werte die automatisch gesetzt werden, wenn man zu tief ansetzt und dennoch gibt es teilweise mehr Leistung, weil die Korrekturen so gut sind.

Nachtrag:
Woher kommt die Annahme, dass tFAW 20 Minimum ist?
Wurde das von AMD mitgeteilt oder selbst getestet / heraus gefunden und wenn ja, womit?
Hatte Buildzoid in einem seiner Ryuen 7000 Overclocking-Guides mal gesagt. Ist aber schon ein paar Monate her.

Ich test jetzt gerade tFAW->16 auf meinem TestPC. Übernommen wird das Setting. Wird also nicht mit 20 überschrieben (aktuellstes Bios auf einem Asus B650-A). Ich nehme momentan an, das es vermutlich mit alten Agesa Versionen nicht ging (lt. Actually Hardware OC).

TestMem5 mit anta777 läuft. Ich teste dann auch Karhu, Y-Cruncher VST, etc. Würde mich dann nochmal hier melden.
 
Buildzoids Aussage bezog sich nach meinem Verständnis aber auch auf einen bestimmten Hersteller (Gigabyte? MSI?) wo man im UEFI nicht unterhalb 20 setzen konnte. Daraus hat er dann gefolgert, dass es bei anderen Herstellern (ohne UEFI-Restriktionen an dieser Stelle) keinen Sinn machen dürfte, unterhalb 20 einzustellen. Weil sich dieser eine Vendor an die untere Grenze (im Register) des Ryzen 7000 - Speichercontrollers für tFAW orientiere. Er verglich das dann mit diversen anderen RAM-Timings, insbesondere bei Intel, wo man irgendwas einstellen kann, obwohl der Speichercontroller dafür gar kein Register hat oder die Werte absurd seien. Soweit seine Mutmaßung.

Bei ASUS geht das m. W. schon die ganze Zeit (also tFAW 16). Tools wie ZenTimings weisen das dann auch aus. Die Frage ist eben, was der Speichercontroller aus der Eingabe macht. Das sieht man nirgendwo. Siehe die Ausführungen von Verangry zum Thema Failsave.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: patze812
Iceman021 schrieb:
Buildzoids Aussage bezog sich nach meinem Verständnis aber auch auf einen bestimmten Hersteller (Gigabyte? MSI?)
ah ok, dann macht das auch Sinn - ich habe bisher nur ASUS Boards mit RAM OC >(B650), X670E) getestet, andere Hersteller bisher nicht. Danke!

Memtest läuft seit 90Minuten und hat noch keine Fehler. Also ich denke tFAW <20 geht. Ich lass trotzdem noch Karhu und VST laufen und geb euch dann bescheid. Die CPU die ich grad verwende ist nicht die Beste (Ram Controller geht nur bis 3100 bei 1:1).

//Edit1: anta77 lief 3xdurch mit 0Fehler
//Edit2: Karhu auch stabil

VST Spar ich mir. hat jetzt insgesamt 4h Zeit gekostet. Anta lief 1,5h - hab allerdings das Fenster zugeklickt bevor ich nen Screenshot machen konnte. -> Somit widerufe ich meine Aussage, das tFaw <20 nicht geht.

Grüße


Iceman021 schrieb:
Die Frage ist eben, was der Speichercontroller aus der Eingabe macht.
In Zentimings werden die 16 ausgelesen (siehe Screenshot). Ich wüsste jetzt aber nicht wie man das Feststellen kann, ob es wirklich mit 16 läuft. Die Differenz im AIDA64 könnten auch Messtoleranzen sein.
 

Anhänge

  • tfaw16.png
    tfaw16.png
    36 KB · Aufrufe: 89
  • karhutfaw16.png
    karhutfaw16.png
    15,4 KB · Aufrufe: 81
  • Screenshot 2024-02-29 181018.png
    Screenshot 2024-02-29 181018.png
    280,8 KB · Aufrufe: 82
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Verangry
Zurück
Oben