RRDL bestimmt CCDL auf AMD, indirekt.
Disclaimer und FW Regelwerk:
CCDL wird selbstständig Pro Clock generiert.
CCDL wird ebenso auf die Nutzer Timings angepasst.
Direkten Zugriff zu CCDL wird einem nicht gewährt, allerdings kann man es indirekt beinflussen.
Der anliegende CCDL Wert, ist der höchste Wert entweder von RRDL oder SC_L.
Man nehme als Beispiel:
RRDS 8
RRDL 10
WTRS 8
WTRL 20
Dies verwendet das CCDL und CCDLWR Regelwerk.
CCDL wäre minimum 10 , und CCDLWR somit minimum 20.
Das heißt RDRDSC_L wäre minimum 10-8+1 (3).
Hat der Nutzer allerdings nun RDRDSC_L auf 4 stehen, setzt die Firmware die CDDL auf 11 hoch.
Bzw nachdem alle Bankgroups ausgeschöpft sind, und es "round trip" zurück zu der selben kommt
// _L = same group (SG) , roundtrip, long jump
// _S = different group (DG) , short jump
hast du ein freien nicht verwendeten Jump von 1 tCK
(11 angesagt, 10 benützt, 1ner nicht verwendet , 7 fehlend bis RRDS minimum delay von 8)
Das sammelt sich für 7*, und erst bei dem 8. mal erlaubt es dir entweder einen RRDS oder RRDL auszuführen und die 11 möglichen werden gefüllt bis zum RFC oder REFI.
= ~14% langsamer im gesammten Bild. Bzw ein verfehlter IC.
Ein weiteres Beispiel:
RRDS 8
RRDL 8
WTRS 7
WTRL 40
Das sagt der Firmware CCDS & CCDL dürften 8 sein.
Es sagt der Firmware das Shorts und Longs sofort hin und her springen dürfen.
Allerdings wenn wir das 5 mal nehmen, bis alle jumps fertig wären. 5 Reads ala 5x 8tCK RRD_X
Erst nach dem 5. mal kann ein Writeback passieren, zu der selben Bank worin man 1x Zugriff darauf hatte.
Im Grundegenommen nicht soo katastrophal, da writes überall landen dürfen und nahezu instant sind.
Sprich eher WTRS genutzt wird, und man zu den _Long's nur fällt, wenn alles andere voll ist. RRDL, WTRL, SC_L werden selten benutzt;
Aber wieder im längeren Bild gedacht , verzögest du Potentielle writes um fast den doppelten delay.
Ein drittes Beispiel:
RRDS 8
RRDL 8
WTRS 7
WTRL 16
Das hier klingt optimal, aber ist es weiterhin nicht, da WTRS höher ist.
Write to Read Short/Instant jump.
Abseits dass es 3 clock höher ist als es eigentlich sein kann (kann WTRS 4 sein)
Rechnen wir es mal aus
CCDL 8 - ReadChop 8 + ODTEnableDly 1 = 1 clock.
1 clock für RDRDSC_L gehe nicht.
Du kannst realistisch nicht durch 4 Bankgroups pro IC * 4 oder *8 Pro dimm seite, in einem einzigen clock durch.
Mit 2 clock würde es eventuell gehen bei RDIMM - welche 2 commands pro strobe gleichzeitig! ausführen können = echtes dual rank
Das würde alle 4 ICs Pro Seite ~ Pro subchannel füllen.
Jedoch in der Realität und mathematisch ist sowas nicht möglich.
Es würde von dir erwarten dass du entweder RTP (breathing delay after done RAS)
Oder WR (write recovery delay) höher stellst als die minimum 12 & 48.
Bzw würde 8 ICs füllen und dann auf RFC warten müssen, da die _Long delays zu kurz sind und apprupt abbrechen.
Sprich, selbst wenn es gut ausschauen mag und für small-dataset benchmarks schneller aussehe (welche kaum bis garnicht einen einzigen IC füllen)
Im gesammten Bild ist das langsamer.
Disclaimer und FW Regelwerk [Teil 2]
Im Specification Sinne, hat RRDS (minimum Strobe delay von 8 tCK)
nun, auf 8 zu sein
~ solange wir nur ein Signal zu beiden subchannels (A & B, 2 pro dimm) haben.
Und RRDL skaliert dementsprechend hoch mit dem Clock. 8++
WTRS hat der selbe Wert wie RRDS -1 zu sein, da ein Read schon geschehen ist und ODTEnableDelay nicht mehr benötigt wird.
Sprich minimum 7.
Nur wie man von der groben Formel oben eventuell sich vorstellen kann ~ bzw um einen guten OCer zu zittieren:
Wäre ein missed command ~ um die 50% Verlust.
Bloß ist es hier nur ein verfehlter jump und kann gegebenenfalls nur 8 clock mehr dauern. Kein roundtrip delay wie tRDWR_SG/DG
Dank dem habe ich einen "kleinen" eigenen exploit gefunden.
DDR4 & DDR5 können innerhalb 2 writes pro Read ausführen.
Eigentlich etwas mehr, aber sie schaffen 2 Stück.
Als Beispiel:
RRDS 8
RRDL 12
WTRS 4
WTRL 24
RDRDSCL = 12-8+1 = 5
Das heißt,
Wenn CCDLWR verwendet wird und WTRL genau doppelt von RRDL wäre (normal)
Wenn die SC_Longs ebenfalls korrekt sind (die minimums) und RTP nicht zuu tief.
Dann endet der Loop genau im richtigen Zeitpunkt um WTRS auf halben clock zu rennen.
Wenn nicht, wäre ein delay irgendwo zwischen Reads zu langsam oder zu kurz.
tWR & tRTP als Hauptvariablen.
Das selbe gehe auch mit RAS
Die eigentliche "always no row-miss" formel ist kürzer.
Nvidia verwendet das gerne für derren GDDR5++
Thema "optimal row buffer locality".
Aber ich bin noch ein amateur und habe den Trick noch nicht ganz rausgefunden
EDIT:
Jedenfalls sind RAS und RC dynamisch
Und RC habe mehrere MSR calls um refreshes dementsprechend anders zu verarbeiten,
Seit DDR4/LPDDR4 Zeiten schon. Bloß konnte nicht jedes DIMM PCB , alle API calls ausführen.
DDR5 nun habe 1000 verschiedene (MSR wurde zu API) calls. Es ist weitaus komplexer mit umso mehr spielerein, um irgendwie den langsamen RFC bottleneck zu umgehen
Ein langer RAS delay ist nicht soo schlimm. Mehrere Timings werden gleichzeitig ausgeführt und haben gleichzeitig abzuschließen.
imgur.com
