Veii
Enthusiast
- Mitglied seit
- 31.05.2018
- Beiträge
- 1.486
- Desktop System
- QA Platform
- Laptop
- ASUS 13" ZenBook OLED [5600U]
- Details zu meinem Desktop
- Prozessor
- Intel Core Ultra 9 285K
- Mainboard
- ASRock OC Formula
- Kühler
- Alphacool T38 280mm
- Speicher
- G.Skill Z5 CK 9600
- Grafikprozessor
- GTX1080ti KP [XOC ROM] // EVGA GTX 650 1GB [UEFI GOP]
- Display
- KOORUI GN10 miniLED
- SSD
- Samsung EVO 850
- Soundkarte
- ESI Ambier i1 & AKG P820
- Gehäuse
- Open-Bench
- Netzteil
- Corsair SF85 // Seasonic GX-550
- Keyboard
- Topre Realforce 108UBK 30g [Silenced]
- Mouse
- Endgame-Gear OP1 8K
- Betriebssystem
- Win11
- Internet
- ▼42 MBit ▲15 MBit
Danke !Doch @Veii
Ich habe alles gelesen und auch diese Regeln gelesen. Ich bin auch dankbar dafür!
Ich verstehe leider einiges von AMDs Denkweise nicht.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. ^^
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.



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
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:
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

Guten morgen allesamt
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.
Bzw der Vergleich
// 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

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:




