@Veii Ich habe gestern noch testweise weitere Werte verändert, so wie ich es von deinen Posts verstanden habe. Bandbreite soweit gleich, wenn nicht ein bisschen besser. Latency in etwa auch gleich geblieben.
Das ist garnicht mal so schlecht
RRDLs hast höher, 12 wird nicht wirklich für 16gb dimms gebraucht (24gb eher). Nun, eventuell KLEVV Blacks bzw Green's.
Aber dann doch eher ab 8000MT/s und höher. Bei den 7000 brauchst du kein RRDL über 10 maximal.
So schlecht können die nicht sein
Der Rest sieht nahezu in Ordnung aus.
WTRL wäre etwas knapp (tight), aber wenn es stabil ist, wieso nicht.
Änderungen aber nur schnell mit Intel MLC und nur ein run Aida testen ist halt auch schwierig da eindeutige Ergebnisse zu erhalten, müsste man jeweils viel mehr Zeit investieren umd diese kleinen Änderungen herauszustellen.
Was für mich noch offen ist, was wäre für mich der "optimale" tWTR L/S - tWRRD sg/dg? Es gibt eine Formel für, aber die sagt ja nicht aus was optimal wäre?
mmm
_Longs würden in unseren Benchmarks kaum erkannt werden.
Ein performance drop gibt es nur, wenn sachen beginnen zu überlappen.
Bzw ein fühlbaren Perf-Uplift gibt es, sollte man vorher ein Problem haben und es nun durch extra verzögerung leicht beseitigt habe *
// * Es ist mem-stick controllers Arbeit, und ein wenig den der CPU ~ die freie Bankgroup zu wählen und die Arbeit zu verteilen. Sehr sehr selten geschieht es dass man _L (roundtrip back to same bankgroup) erwischt
Generell skallieren RRD & WTR tiefer dank den Terts.
Verschwende man Latenz bei denen:
~ hoher _SG, hoher _DG,
~ zuu tiefer WRWR_SG worin ein HALT entsteht,
~ zuu viel verschwende Latenz an RDWR_SG/DG
~ knappes FAW von 16, worin nur 2 1kb pagesize commands durchgehen können, sprich die halbe last und anforderung ffür RRD_
~ Nutzergewählte knappe tWriteRecovery, pro IC anstelle pro Bankgroup (das selbe Thema wie mit tFAW)
All diese Möglichkeiten werden dein minimum RRD und WTR beinflussen.
Laut specs, gehören WTRS und RRDL auf 8 clock.
RRDL wäre gleich CCDL und WTRL wäre gleich CCDLWR (CCDL²)
Ob WTRL nun 2* oder 3* RRDL rauskommt, kommt auf dem MemoryVendor bzw PCB designer an.
PCB Revision Topic.
Zb, bei meinen A0 Viper's (DDR4) bewege ich mich mit RRDS 6, RRDL 7/8 , bzw +1 obendrauf ~ ab 4200MT/s.
Bei den A1 PCBs gehe das etwas tiefer (short trace layout) und die A2's bzw B2/A3's (customs) bekommen es umso tiefer, aber es hilft einem weiterhin nicht RCD hinnunter zu bekommen
(Haupt variable für IC binning, nicht CAS)
Ein signatur trick von mir, wäre WTRS half-of RRDS..
Ich würde es als Exploit sehen, und es gehe nur wenn die Terts OK sind. Nicht zu tief.
Ebenso wird es im großen Bild nur möglich, wenn RAS kein ROW-Miss dank Nutzerfehler erstellt.
Macht er dass, geschehe weiterhin ein Halt, RP setzt zu früh an, RAS wird wiederholt und ended abprupt, das bewegt RC nach hinten und gleichzeitig enden RRD & WTR dann zu früh = error
Bei DDR5 hast du PPR, PostPackageRepair.
Ein ROW-Miss verhällt sich weiterhin Katastrophal
// (schwer erkennbar, da es alles wie RFC/REFI stoppt & dann RAS im gesammten wiederholt,
// bzw RAS nicht soo viel einfluss auf Bandwidth hätte, somit schwer erkennbar)
Aber der SPD-Hub ist deutlich inteligenter.
Er hat ~1000 API calls, von welchen nur ein Bruchteil (MSR) ob-boot fixiert werden.
Der rest ist dynamisch und jederzeit selbstständing anpassbar. "Leider" 🤭
Ein signatur trick von mir, wäre WTRS half-of RRDS..
Trick 15
Es kann bei hohem clock erwarten, dass du WR und RTP langsamer stellst. (höherer Wert)
Aber im Grundegenommen kommt es Bandwidth technisch aufs selbe hinnaus, mit der Ausnahme dass die Natur von "Writes are pretty instant" ausgenutzt wird.
Wertvoll für Spiele, kaum einen Unterschied für Benchmarks, da Zugriffszeit standartmäßig nicht schnell genug ist, bzw die CPU eher der Architektur Bottleneck wäre. Nicht DDR5
Es erwartet ebenso WRWR_SG auf 16.
Gleiche Read und Write delays.
Ansonnsten double für WRWR_SG (CCDLWR Grund) ~ jedoch eher nützlich für Dual-Sided dimms.
Geben und nehmen ~ tradeoffs