[Sammelthread] Ryzen DDR5 RAM OC Thread

Doch @Veii
Ich habe alles gelesen und auch diese Regeln gelesen. Ich bin auch dankbar dafür!
Danke ! :giggle:
Aber:
Es ergibt in meiner Welt einfach keinen Sinn. Auf OCN stehen im AMD DDR5 OC Thread beispielsweise folgende Regeln:

1.) tWRRD = tWRWR_DD

tWRRD
ist bei mir derzeit auf "8". Dementsprechend müsste ich tWRWR_DD auch auf die "8" packen. Bei mir ist es aber auf "7" stabil. Soll ich es jetzt trotzdem um 1 erhöhen?
In Deinen Regeln sagst Du "tWRRD = 4". Wenn ich tWRRD = tWRWR_DD beide auf "4" setze, dann bootet mein System nicht mehr.

2.) tRDRD_DD = tWTRS

tRDRD_DD
steht bei mir auch auf 7 und ist stabil. Das dürfte es aber normalerweise gar nicht sein, weil Du in Deinen Regeln sagst: "tRDRD = 8". Mein Wert ist hier um 1 zu niedrig. Zudem: Wenn ich tWTRS auf 7 setze, dann ist es nicht mehr die Hälfte von tRRDS.

Ich verstehe jetzt gerade gar nichts mehr. Ich habe mir alle Regeln angeschaut, aber sie funktionieren nicht zusammen.

Wie sollte ich denn meine Timings Deiner meiner nach setzen, wenn es Stand jetzt so bei mir stabil ist?
Ach ja, tRDWR = 16 ist korrekt bei mir und tWRWR steht auch auf 7 und wäre damit auch um 1 zu hoch.

Ich bin leider maximal verwirrt. ^^
Ich verstehe leider einiges von AMDs Denkweise nicht.

Ein paar timings zeigen deutlich dass sie doppelte MC links benützen. Den ansonnsten braucht du den delay nicht.
Andere defaults wie WRWRSC_Long aka eine CCDLWR Nutzung, werden nur gebraucht, sollte man den Zugriff zu beiden Subchannels (pro seite)
Nicht simultan ansprechen.
1700978775392.png1700978917575.png
brave_jUBYfMvGcn.png
brave_4oFJCDFl0t.png
1700979321830.png


Da mir niemand genau beantworten kann ob AMD nun dual MC links benützt oder nur einen.
Welches layout genau gewählt wurde, kann ich dir auch nicht die exakten minimums sagen.
Aufgrund mehreren Problemen

tBURST ist auf der CPU Seite als 3nCK (AMD Only) erzwungen.
Es kann nur ein 133/100 synronization's Topic sein. Aber ich verstehe es nicht ganz.
Beide subchannels werden individual zu der CPU gezogen , in unserem Fall der APU und dort interleaved und scheduled.
Normalerweise sollte Bank bzw Rank scheduling auf dem DIMM selber passieren.

Bei beiden brechen Intel und AMD die eigentlichen Specifications von DDR5.
Das macht es weiterhin ein unklares Argumentation Thema. Mit mehreren richtigen "it depends" Antworten.


Sorry zu deiner Frage nun,
Der Grund weswegen es verwirrend ist, abseits des Logik Thema's
Ist dass der Hauptpost nicht von mir gewartet wird, und doch einiges an Zeit zwischen den Posts vergangen ist :)

WRWR_DD zu tWRRD matching, wurde benötigt, als AMD noch Schwierigkeiten mit dem RTL bzw IOL ~ in unserem Fall tPHYRDL & WRRD hatte.
War dieser Wert nicht exakt identisch, so hattest du PHYRDL missmatches und dank denen kaamen dann #0er in memtests.
"Dropped DQS thanks to missmatch in channel delay and so missmatch unstable delays = unstable clock and generally a mess'n'a half"
So in etwa 🤭

Es zeigt auch deutlich, dass _DD timings im Einsatz kommen, aber auch nur weil es ein RTL und Syncronizations Topic ist.
Obwohl ehmalige zb Anandtech Artikel "Subchannel" als "eine falsche Ausgabe der Realität" betiteln.
Leider gibt es einen großen Unterschied zwischen den design-specifications und der Realität die wir hier haben.
DDR5 is a mess :) Unsere fehlerhafte Umsetzung macht es nicht einfacher.
Ich wünschte der Start wäre anders und wir würden DDR5 korrekt benützen. Das heißt ebenso FGR an !!! mit korrektem clock halting :rolleyes2:
Mir fehlt die motivation die Biose für alle Boards zu patchen damit es endlich weitergeht . . . Etwas ausgebrannt immer nur ein one-man-army Rebell zu sein.

Jedenfalls:
1700981776977.png

Diese Werte sind korrekt.
Solange man RRDS über 8 hält.

Sollte man RRDS unter 8 laufen lassen, in dem Fall RRDS 4 (GDM trickst, RRDS4 ohne GDM braucht spezielle Vorraussetzungen)
Dann wären die minimums, 4-8-2-3 anstelle 8-16-4-6


Es gibt leider ein weiteres "it depends"

Und zwar ob wir nun den CCDLWR Spec nützen möchten oder nicht.
Das heißt welchen Wert wir für WRWRSC_L angeben.

Man könnte die CCDL Formel nützen und nur RRDL als CCDL bezeichnen bzw nehmen.
Dann wäre das effektive SC_L minimum, RRDL (also CCDL) - BC8 +1.
SC_L sind samechip (roundtrip) latency.
Was wir ausrechnen ist der CPU-Interface (HOST) delay, minus dem Mem-Interface delay + den ODTEnableDelay)
Sprich SC_Short wäre so oder so instant = 1
SC_Long wäre dann ODTEnableDly (pulled high). Der Reine offset zwischen beiden , aka zwischen read to read oder write to write commands.

Das sollte hoffentlich auch erklären weswegen WRWRSC_L tiefer kann.
Bzw hofffentlich erklären weswegen manche XOCer diesen als "its just not used" betiteln.

Nun Fehler stacken.
Es ist schon ein Hauptproblem dass man RAS zu tief setzt, aber nun ja.
A never ending discussion :')
Somit tut mir leid sollte ich sehr harsch zu solchen Leuten reagieren~~

SC, SD/DR, DD, SC_L ~ sind alles transition delays.
Sie sind keine ! fixen Timing delays :)
Nicht nur manche OCN nutzer gehen mir auf die nerven, sondern auch Boardpartner.
Ich muss jedes-mal Leuten nachrennen damit die Industrie weitergeht. Tut mir leid sollte ich jemanden mit meinem gestrigen Kommentar verletzt haben :coffee2:
Guten morgen allesamt :geek:
Beitrag automatisch zusammengeführt:

Ah,
Selbst wenn ich falsch liege und es nicht wissen kann ~ sprich AMD wirklich sich korrekt verhält und aus "panik?" FGR bzw Mixed-Mode nicht einschalten möchte;
Sollten die Werte doppelt so hoch sein, kann RAM sich von BL16 zu BL32 ändern.
Das gleicht die Latenz und zugriffszeit an, mit minimal langsamerer Peak Bandwidth ~ auf deutlich niedrigereren Spannungen.

@RedF
Eigentlich ist dein Ergebniss nicht soo schlecht, wenn ich mir mein Safedisk vs Veii Beispiel aus dem Post #3,124 ~ anschaue :)
Bei dir sind beide recht gut balanciert und werden durch die Architektur limitiert.
M41CywTmlT.png

Bzw der Vergleich
1700982627816.png

// RFC und ODT sind absichtlich gleich gewählt.

Ich bin etwas langsamer im max-write Zugriff.
Sollte es sich auf BL32 benehmen, erklärt es den Grund. Denke allerdings dass es an WRRD liegt, da beide RDWR & WRRD sehr auf die BW gehen.
Brauche jedoch nur ein Bruchteil der Spannungen und somit wäre SI besser :)
1700982695127.png

Es ist kaum bis garkein Latenz Unterschied.
Im Copy welches eine Rolle spielt wäre ich sogar effizienter dran.
Aber AIDA gibt nur das Potential an und ist weit von der Realität

Die Realität testet man anders und ist je nach SKU etwas anders.
SiSoftware Sandra ist dein Freund bei dem Thema :)
Und Riftbreaker Demo, müsste ebenso dezent gut skallieren.
// Es würde die GPU Auslastung ändern (ins positive), wenn Zugriff zum L3$ und dann leakage zu Mem ~ effizienter wird.

Es heißt weiterhin nicht dass es "Sinnlos" wäre
Aber dass man nicht wirklich so tief gehen muss um die selbe bzw in manchen teilen +1% in anderen -1% Leistungsverlust hätte - auf 50-100mV weniger Spannung
Grund ~ die Architektur kann damit nichts anfangen, und nun ja ~ das MC Thema ist seit über einem Jahr noch nicht geklärt.
Die transition delays zwischen den Timings spielen eine wichtige Rolle. Auf welchem Startwert diese sind bzw wie tief sie wirklich gehen, ist ein komplett anderes ~noch unklares~ Thema.

Jedes Timing geht in paaren bzw dreier ~ (pre timing, timing, past timing infuence)
Niedriger heißt nicht gleich besser~~
Ich hoffe man versteht mich.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Vielen herzlichen Dank. Ich habe es noch nicht komplett verstanden, aber werde mich in die Thematik einarbeiten und schauen, was stabiler und konsistenter läuft.

Also 4-8-2-3 vs. 8-16-4-6 in Abhängigkeit von tRRDS. Das heißt wohl trial and error! :-)

Danke für Deine Zeit auf jeden Fall. Das ist ja auch immer eine Menge Arbeit solche langen Posts zu schreiben. Ich bin von der Sache her eigentlich mehr Praktiker, aber die Theorie dahinter sollte man meiner Meinung nach zumindest wissen.
 
Ich bin von der Sache her eigentlich mehr Praktiker, aber die Theorie dahinter sollte man meiner Meinung nach zumindest wissen.
Use SiSoftware Sandra - Interthread latency test
Der Rest der "benchmarks" schaffen es kaum über einem IC zu gehen, geschweige den überhaupt die Buswidth limits zu erreichen.
Aida testet diese Buswidth limits, aber es ist eine Bruteforce methode. Weit weg on der Realität, jedoch ok um throttle oder ECC zu bemerken.

Höre nicht auf mich und vergleiche es mit einem guten Tool :)
Höre lieber auf das was AMD macht.
Fast alles hat einen Grund weswegen es sich so benimmt wie es sich benimmt.
Durch "Leistungstests" findet man allerdings diesen Grund nicht heraus. Nur dass es schneller sein kann, jedoch "wieso".
Natürlich sind niedrige timings in irgendwas schon schneller, wenn ECC noch nicht einsetzt. 🤭
 
Zuletzt bearbeitet:
Ah @drival0605
1700986678503.png

Nun sollte hoffentlich alles klar sein :d
AMD nützt kein SD/DR/DD für RDWR bzw WRRD.
Und tRDWR bzw tWRRD sind andere Timings.
Ich meinte dort nur die _DD's bzw _SD's.

RDWR und WRRD sind komische AMD-HQ Timings.
Aber die Formel davon steht extra.
Hoffentlich verständlich beschrieben.

Theoretisch kann RRD(S) tiefer sein, mit höherem vom Board angelegtem CCDL
Aber die Regel im ersten ersten Post gilt weiterhin.
Es wird mathematisch das minimum CCDL ausgerechnet (dank user timings)
Weswegen es sehr wichtig ist SC_L's korrekt zu haben, selbst wenn man WRWRSC_L gleich RDRDSC_L stellen möchte (wobei der WTRS Exploit bricht und mehr tRTP & tWR braucht)

Wären SC_L's falsch bzw RRD_L's höher als die minimums.
Also RRDL höher als SC_L, dann wird SC_L hochgerechnet.
EDIT ~ Example:
RRDL 8 ~ minimum CCDL 8
RDRDSCL 5 (minimum CCDL 12 ~ da 12-8+1 = 5 SCL)
= 12 liegt an, RRDL 8 ist eine Verschwendung

RRDL 15 (CCDL 15)
RDRDSCL 3 (CCDL 10)
= 15 liegt an, zwischen reads with noch ein tAL on 5 nCK eingesetzt ... im besten Fall. Im schlimmsten crasht es
Es haut immer den höchsten delay rein.
Im gesammtbild, macht es wenig sinn commands zu queue'n , wenn CCDS und CCDL der Limiter sind.
// Aber natürlich bemerkt man sowas nicht, wenn man kaum mehr als 1024MB auslastet mit seinem Benchmark. 🤭
Sprich es macht wenig Sinn diese Timings niedrig zu halten, obwohl es "nur" der Bankgroup swap delay ist (RAS to RAS different/same bankgroup = RRD)
Im gesammtbild, geht mehr schief. Selbst wenn es "kleine" benchmarks, als schneller darstellen.

Abseits davon,
Bei hohem clock, musst du zurück auf den richtigen Werten, aka RRD minimums 8+
Und sollte ich mit RRDS, bzw CCDS falsch liegen und es 3 oder 4 sein [dank double MC] - passt es dennoch, da BL32 eine Sache ist.
Nun ja :)
 
Zuletzt bearbeitet:
Ich lasse das jetzt erstmal so:
1700988373370.png

Kann schon sein, dass das noch niedriger geht, aber ja, reicht mir erstmal. Spannungen sind auch akzeptabel für mich (VDD = 1,38 V; VDDIO = VDDQ = 1,3 V; VSoC = 1,225 V; restl. Spannungen auf auto).

tRAS habe ich die "optimale" Variante genommen, also tRCD + tRTP + 8 (Burst?)

Wenn ich Lust und Zeit habe, schaue ich mir diesen SiSoft Sandra Test mal an.
 
Ich lasse das jetzt erstmal so:
1700988318286.png

Das ist schön balanciert :) Bottleneck CPU Arch, nicht mem.
AMD kann seine instant writes wann-auch-immer ausführen (ReBAR spielt ebenso eine Rolle, viele AMD trickserein),
und du kannst manche timings nun tiefer setzten und solltest verbesserungen feststellen können.
Ich würde aber erstmal GDM weghauen. Nummer 1 :)

Danach würde ich versuchen ob tWRRD auf 4 oder 5 eine Verbesserung bringt.
// nicht sicher ob 5 oder 4 hinkommen. AMDs Formel ist ... falsch ? , komisch definitiv. Sollte gleich WTR sein bzw +/- 1 dank PhyDly.
Und die WRWR's danach um 1 absenken.
Bzw SD's sind immer höher als DD's. Laut specs haben sie gleich zu sein, aber ja.
// ^ single side braucht keine SD's. Reine delay Verschwendung.

Danach wenn du damit fertig bist es auszuloten (bzw bei keinem sichtbaren Unterschied mit SiSoftware Sandra Inter-thread test gegentesten)
VDDIO = VDDQ = 1,3 V
Das ist halt ... misst :d
Dann kann ProcDQ zum schwächeren Wert (größere ziffer) und VDDIO tiefer :)

Da du eine Delta zwischen VDDQ_MEM und VDD_MEM hast
Muss VDDIO (VDD2_CPU/MC) mindestens um die selbe Delta hinunter.
// ^ versteckte VDDQ_CPU synchronization Thematik ~ AMD macht es automatisch, bei Intel muss man selber ran.

Später wenn dir langweilig wird, kannst du gegentesten wie tief VDDQ_MEM bei dir sein kann.
Je tiefer, desto besser ist die Signal Integrity. 50mV gehen immer, ab 100mV wirds schwer und instabil (Tm5 reports bitte hier-her)
Es kann sein dass du dich mit den ODT's spielen musst.
Beitrag automatisch zusammengeführt:

Ah
RDWR kann runter bis zum Wert von 13.
Das minimum hängt von WPRE ab, und der Wert hängt vom Training ab bzw Nitro settings.
Er ist pro clock unterschiedlich
Aber es sollte dir helfen die echten minimums rauszufinden, nun wo die Timings sich nicht gegenseitig stören.
^ dafür muss GDM weg. GDM gaukelt dir Stabilität vor.

Nur nicht vergessen, alles geht in Paaren.
RDWR 14-15 müsste auf Dual sided rennen. Ich denke 14(+1 für stabilität, micron) wäre gut genug.
Bringt am meisten Bandwidth, aber es wird nicht "ein" benchmark sein, der auschlaggebend sein muss.
Alle müssen positiv skalieren, ansonsten macht man als Timing-Tuner irgendwo etwas falsch. (ein Timing stört das andere)
 
Zuletzt bearbeitet:
Jetzt ist das doch total untergegangen 😅
Trainiert dir das Board selber die SD & DD's ?

FCLK ist kein Timing oder Voltage Thema.
Es ist ein ODT/Impedance Thema.
// Du kannst es kaum bis garnicht mit VDDG und SOC lösen.
// Es hängt von der APU ab wie hoch max UCLK & FCLK sein kann. Nun FCLK hat mehr Variablen.
FCLK kann sich selbstständig korrigieren, da es loadbalanced ist.

On-Die ECC existiert in der CPU und an dem DIMMs. Genannt PPR (Post Package Repair);
Zu hoher FCLK hat eher eine negative Skallierung.
EDIT: Das selbe mit zu hohen (-) CO Werten.
Clock-gating Thema. Bleibt stabil, skaliert negativ und auto-korrigiert VID. (dcBTC ~ AVFS Thema)
Sehr-schwer zu überprüfen, da clock im 1ms Abstand fällt. AMDs (RSMU) API ist weitaus zu langsam.
 
Zuletzt bearbeitet:
@Veii

Vielen Dank für Deinen ganzen Input. Das ist enorm hilfreich!

Allerdings funktioniert der erste Tipp leider schon einmal nicht:
Ich würde aber erstmal GDM weghauen. Nummer 1 :)
Wenn ich GDM ausstelle und TM5 1usmus starte, dann wirft es innerhalb von SEKUNDEN Errors und crasht unmittelbar danach (Blackscreen - PC Neustart). Mir ist dabei aufgefallen, dass "tPHYWRL" von 16 auf 15 springt, wenn ich GDM ausschalte. Ist das die Ursache?
1700992286865.png

Mit GDM an läuft TM5 1usmus rockstable durch (STUNDEN). Hat das eventuell etwas mit (falsch gesetzten) Spannungen und/oder Widerständen zu tun?


tWRRD auf 4 läuft aber auf jeden Fall!

edit:
Ach ja, und "tPHYRDL" springt von 36 auf 35.
 
@RedF Korrektur für RTP
1700992251287.png

^ source Anta
Beitrag automatisch zusammengeführt:

Wenn ich GDM ausstelle und TM5 1usmus starte, dann wirft es innerhalb von SEKUNDEN Errors und crasht unmittelbar danach (Blackscreen - PC Neustart). Mir ist dabei aufgefallen, dass "tPHYWRL" von 16 auf 15 springt, wenn ich GDM ausschalte. Ist das die Ursache?
PHYRDL springt tiefer. Bitte überprüfe ob es für beide Dimms identisch wäre.
Aber ja - wie gesagt, GDM gaukelt einem Stabilität vor :d

Bleiben wir mal bei
SD/DD als 8

Kannst du 2T nehmen, anstelle 1T ?

Wir werden sehr viel mit ODTs spielen müssen
Alleine RTT_NOM sieht mir komisch aus.
Naja eigentlich erwarte ich von ASRock nichts als perfektion.
AMD hat sie dieses Generation als Boardpartner-of-Trust ausgewählt.

Bitte versuche dir zu notieren welche errors du bei TM5 bekommst :)
 
Aber ja - wie gesagt, GDM gaukelt einem Stabilität vor :d
Ja, das habe ich bemerkt. Allerdings. ^^

Bitte überprüfe ob es für beide Dimms identisch wäre.
Leider nein.

DIMM 1 (A2): tPHYWRL = 15 & tPHYRDL = 35
DIMM 2: (B2): tPHYWRL = 15 & tPHYRDL = 37
Kannst du 2T nehmen, anstelle 1T ?
Ich weiß leider nicht, wo ich das einstellen kann. Hm.

Alleine RTT_NOM sieht mir komisch aus.
Ja, ich habe zunächst einmal einige Spannungen und die Rtts sowie Proc/Dram wieder auf auto gesetzt:
1700993726694.png

1700993775728.png



Und das habe ich noch eingestellt um die Stabilität zu unterstützen:
1700993745111.png


Bitte versuche dir zu notieren welche errors du bei TM5 bekommst :)
Mache ich!

edit:
Jetzt lief es zumindest mal ~2:30 Minuten durch bis zum ersten Error. Eben kam der innerhalb von 5-10 Sekunden.

Also ich würde die Fehler gerne posten, aber die wurden nicht augezeichnet im Log-File. Wo sollen die genauen Fehlertypen stehen?
1700994405257.png
 
Zuletzt bearbeitet:
Und das habe ich noch eingestellt um die Stabilität zu unterstützen:
1700993745111.png
Ich würde RX & TX Data auf Auto lassen
TAPS sind ein anderes Thema.

Das könnte helfen: #4,852
1700994364106.png

Meine Ehemalige foundation auf dem Taichi Carrara :)
Bis auf die Ausnahme, dass 6400 C26-36, 1.65v braucht, und ich hier effizienter ran'ging.
Taichi hatte kein Renesas Unlock. Bis heute nicht.

Und wenn dir nach etwas lernen ist #6,338 & #6,283
1700994694802.png

Mit VMISC würde ich abwarten. Ich hatte zu viele reports wo Leute iinstabil waren, sowie AMD es auf 1.1 versperrt hat.

EDIT:
Dual sided
steamwebhelper_bD4iu4RmdT.png

Würde ich versuchen.
Hi-Z ist ein auslese Fehler für 23? ohm, das niedrigste.
 
Zuletzt bearbeitet:
Trainiert dir das Board selber die SD & DD's ?

FCLK ist kein Timing oder Voltage Thema.
Es ist ein ODT/Impedance Thema.
// Du kannst es kaum bis garnicht mit VDDG und SOC lösen.
// Es hängt von der APU ab wie hoch max UCLK & FCLK sein kann. Nun FCLK hat mehr Variablen.
FCLK kann sich selbstständig korrigieren, da es loadbalanced ist.

On-Die ECC existiert in der CPU und an dem DIMMs. Genannt PPR (Post Package Repair);
Zu hoher FCLK hat eher eine negative Skallierung.
EDIT: Das selbe mit zu hohen (-) CO Werten.
Clock-gating Thema. Bleibt stabil, skaliert negativ und auto-korrigiert VID. (dcBTC ~ AVFS Thema)
Sehr-schwer zu überprüfen, da clock im 1ms Abstand fällt. AMDs (RSMU) API ist weitaus zu langsam.
Die Timings sind ein aus einem OC Profil von meinem AUS B650 Board. Ich habe lediglich TREFI angepasst, GDM OFF und spannung ausgelotet. In diesen Profil sind alle Timings wie z.B. die SD&DD Werte vorgegeben. FCLK beobachte ich mal. vorher hatte ich es immer auf 2100 Mhz bei 1,1V laufen. CO z.B. lass ich bei -15, Gibt es kein Benchmark, der überprüfen lässt ob ECC, etc. da rein pfuscht? :(
 
edit:
Jetzt lief es zumindest mal ~2:30 Minuten durch bis zum ersten Error. Eben kam der innerhalb von 5-10 Sekunden.

Also ich würde die Fehler gerne posten, aber die wurden nicht augezeichnet im Log-File. Wo sollen die genauen Fehlertypen stehen?
Steht im fenster. 0er
Hard dropouts from CPU Side. Link dropouts.
Verringere mal die VDDQ delta. Mehr VDDQ oder versuche einfach mal das Taichi profil von mir zu übernehmen mit Auto RTT's.
ProcODT 43ohm müsste passen. 2100 FCLK ebenso. 2133 wäre gewagt vorerst.
 
Grüß euch. Ich bin momentan überhaupt nicht up to date was DDR5 Tuning angeht.
Kann mir einer mal ungefähr passende Settings für mein Riegel vorschlagen?
Bei mir ist noch vieles auf Auto.

ZenTimingsScreen.png
 
Wie viel Spannung (24/7) darf man den DDR5 Kits eigentlich geben?

(Ohne den RAM besonders zu kühlen).
REFI 66535 ~ 1.45 , etwa bis 44-46°
REFI 32767 ~ 1.5v , bis etwa 60-62°

Ansonnsten je nach airflow oder open-bench gehen 1.55 noch durch.
24/7 wäre ok bis 1.65v mit aktiver Luftkühlung.
VDDQ_MEM setzt die Hitze vorraus. Die Spannungs ist nicht alles :)

Temp welche du ausließt ist PMIC temp.
IC Temp wäre ungefähr +15° oben drauf.
Grüß euch. Ich bin momentan überhaupt nicht up to date was DDR5 Tuning angeht.
Ich würde sagen, beginne von https://www.hardwareluxx.de/community/threads/ryzen-ddr5-ram-oc-thread.1324121/page-57 jeden Post zu lesen
Es sind nur 3 Seiten 🤭
Drei lange seiten, aber nur 3 stück. Eine Pro Tag sollte gehen :coffee2:

Den durchs Spoonfeeding lernt man garnichts.
 
Zuletzt bearbeitet:
Ich würde RX & TX Data auf Auto lassen
Alles auf auto?
Also so:
1700997073911.png

TAPS sind ein anderes Thema.
Danke für die Spannungen! Habe ich mir angesehen und für mein Taichi Lite so übernommen!

TAPS sind ein anderes Thema.
Alles klar. Bei mir stand "RX2D Voltage Step Size (2*n) auf 2. Ich habe es jetzt aber auf 1 gesetzt, so wie in dem Screenshot in dem Post, den Du mir verlinkt hast. Richtig so?:
1700997235097.png


Mit VMISC würde ich abwarten. Ich hatte zu viele reports wo Leute iinstabil waren, sowie AMD es auf 1.1 versperrt hat.
In Ordnung, dann bleibt die erstmal auf 1,050 V.

Würde ich versuchen.
Hi-Z ist ein auslese Fehler für 23? ohm, das niedrigste.
tausend Dank für die Widerstände! So sieht's jetzt aus:
1700997362033.png
1700997387500.png

Wie man sehen kann, ist tPHYRDL immer noch asynchron (35/27). Vielleicht muss ich auf DDR5-6200 oder DDR5-6000 runter?

Steht im fenster. 0er
Hard dropouts from CPU Side. Link dropouts.
Verringere mal die VDDQ delta. Mehr VDDQ oder versuche einfach mal das Taichi profil von mir zu übernehmen mit Auto RTT's.
ProcODT 43ohm müsste passen. 2100 FCLK ebenso. 2133 wäre gewagt vorerst.
Danke. Ich teste dann einfach mal weiter.
 
Alles auf auto?
Also so:
1700997073911.png
Training BL kann auf MAX
Alles klar. Bei mir stand "RX2D Voltage Step Size (2*n) auf 2. Ich habe es jetzt aber auf 1 gesetzt, so wie in dem Screenshot in dem Post, den Du mir verlinkt hast. Richtig so?:
1700997235097.png
Es war ein zittat eines kumpels, aber ich würde es auf Auto lassen wenn möglich
AMD weiß wie sie derren DAC's rennen sollen. Ich würde mich gerne damit spielen mein AM5 system ging vor dem großen Gear2 update schon weg.
Erst nachdem ich zu Intel ging, kaam plötzlich das Spannende update. Aber eigentlich tat mir das Intel Ecosystem sehr gut. Ich hab viel dazu gelernt :)

TX2Dimm DFE kann auf enabled , aber ich würde so viel es geht auf AUTO lassen. Besonders auf ASRock Boards.
TAPs kann manuel sein.
In Ordnung, dann bleibt die erstmal auf 1,050 V.
1.1v ist der standart, aber es müsste tiefer gehen - wenn es das Board erlaubt.
Ich denke es ist komplett ok tiefer, AMD sagt nein.
Wie man sehen kann, ist tPHYRDL immer noch asynchron (35/27). Vielleicht muss ich auf DDR5-6200 oder DDR5-6000 runter?
Eventuell auf 6200 aber es ist ok wie es ist.
Ist ne firmware sache. Unschön etwas langsamer aber ok wie es ist.
Danke. Ich teste dann einfach mal weiter.
Viel Glück !
 
:( (Das ist schon mit Deinen Spannungen).
DIMM PCB crash.
Ok , hmm

Aber kein #0 & kein #6, das ist gut
RTTs also.

Kannst du eventuell ProcDQ höher stellen ?
Findest du es ?
Auf 40 ohm anfangs.

Schwächere procODT würde es lösen (48ohm) , aber das limitiert dich im FCLK.
Bzw VDDQ_MEM noch tiefer würde es lösen,
Side-issue fix :d also ne. Wir brauchen das "key-issue" Problem.

Eventuell müsste es auch RTT_NOM auf 60ohm lösen, aber nein :)
Voerst nicht.
 
Ich habe zunächst einmal ProcDqDs von 34.9 auf 40.0 gestellt und starte nun einen neuen Run.

Ich würde den FCLK echt super gerne auf 2133 MHz lassen. ^^
 
Ich habe zunächst einmal ProcDqDs von 34.9 auf 40.0 gestellt und starte nun einen neuen Run.

Ich würde den FCLK echt super gerne auf 2133 MHz lassen. ^^
64gb GDM off wird lästig werden :)
Aber sollte machbar sein.

FCLK müssten wir schauen.
Das Problem ist, TM5 schafft es durch eine unstabile CPU zu errorn
Es wurde designed, dass es so gut es geht kaum auf die CPU geht und nur memory testet (nicht direkt controller)
Aber naja, weiterhin beinflussbar.

y-cruncher FFT musst du stabil rennen können , sollte FCLK wirklich passen
Und das länger als 60min.

Wir schauen mal
Step by step.

#4 ist nicht direkt ein FCLK problem.
Sondern ein crash auf dimm's seite.
#0 & #6 waren ein CPU to mem problem.
#6 kann ebenso ein IMC problem sein.
 
Zuletzt bearbeitet:
Danke Veii. Der erste Cycle lief gerade durch. Ich melde mich, wenn es einen Fehler gibt. ^^
Nun ist tRRDS = tWTRS = tWRRD = 8
 
Danke Veii. Der erste Cycle lief gerade durch. Ich melde mich, wenn es einen Fehler gibt. ^^
Nun ist tRRDS = tWTRS = tWRRD = 8
Gerne~
Bitte beobachte die DIMM temperatur genau, und öffne nichts anderes außer TM5 und meinetwegen HWInfo oder HWMonitor.

Ich brauche eine Dokumentation welcher error wann kommt und welcher error nach dem anderen kommt.
Bzw ob es eine explosion von dem selben error wäre (5 pro sekunde) usw :)

Ansonsten kann ich dir keine konkrete Fehlerdiagnose abgeben.
25 loops auf 2x32gb müsste so in etwa 3:30-4 Stunden dauern. (double density, double duration)
So ungefähr ab dem 6. cycle wird es eher zum Thermal und Signal Integrity Problem

Dein RFC ist sehr niedrig für dual sided 16gb , aber wir schauen mal~
Ebenfalls sind 2x32gb dimms weitaus schwerer zu OCn - besonders auf Gear 1 und dann noch GDM off (full signal strength), als 2x24gb single sided.
Beitrag automatisch zusammengeführt:

Eigentlich kannst du es mit einem Screenshot (i need Data, i dont trust text) ab dem 4. "stable" Cycle beenden und WTRS wieder runter auf 4.
Nur der RRDS/2 = WTRS exploit, braucht alles perfekt. Es ist eine sehr unüberlegte idee damit zu starten.

Nun, da es wohl ein error zwischen bankgroups ist, müssen die RTTs nochmal daran glauben :)
Irgendwas stimmt mit denen nicht. RRD/WTR verlangsamen bringt Stabilität, aber es ist nicht die Lösung von dem Problem (side issue, haha)
Scheint als wäre Gigabyte's ODT+RTT preset nicht optimal (war es so oder so nicht, procDQ zu stark) & mir fehlt die 32gb dimm's Erfahrung.
ODTs tuning ist lästig, besonders ohne stabile foundation. Aber bekommen wir hin~~
 
Zuletzt bearbeitet:
Error 16 nach ~44 Minuten
#15 ist ein RFC oder core crash :)
FCLK runter vorerst.

Und dann testen wir gleich mal WTRS 4.

Step by step.
RFC muss später vlt auch noch dran glauben, aber erst später.
WRRD bleibt vorerst auf 8, bzw Auto bis ich die Formel rausgefunden habe

EDIT:
Ah, memory 1.0v rail bitte auf 1.1v
Es droppt mir etwas zu stark.
1701002506205.png
 
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