[Sammelthread] Micron 8GBit E-Die DDR4

[MHM]

Mit dem +50mV SoC Offset ist es wirklich stabil, mittlerweile auch jeweils über 12h Karhu und TM5.

Der Standard für Loadline Calibration Control @ "Auto" scheint vom Verhalten her "Mode 4" zu sein, damit liegt die Spannung idle bei 1,05v und unter Last bei 1,044v.
Mit "Mode 3" liegt die Spannung immer bei konstant 1,05v.

Gab nun schon wieder ein BIOS Update fürs MSI B550-A PRO:

7C56vAH
- AGESA ComboAm4v2PI 1.2.0.C update.
- Fix D-Sub port can't be work properly with 3000G CPU.

Damit haben sich nun auch die Standard CAD Bus Werte bei 3200 von 20-20-20-20 auf 24-24-24-24 geändert.

 

[MHM]

Habe mittlerweile einen Lüfter für den RAM eingebaut und eine ganze Weile 3200 CL14 ausprobiert.

Finde 3200 CL14 bei 1,36v (Einstellung) und knapp unter 1,35v laut Sensor sollte garnichtmal so schlecht sein.
Etwas eigenartig dass der RAM bei 3400+ selbst mit sehr lockeren Timings nicht will.
Ob diese 3200C16 Kits evtl trotz halbwegs gut gebinnter Chips künstlich im Takt beschränkt werden durch die Wahl der verbauten Terminierungswiderstände & Kondensatoren?
Denn es gibt auch schnellere Kits mit der selben Platine.

Fehlerquelle #1 bei mir war die zu geringe SoC Spannung.
Fehler traten dann vorallem auf wenn der PC nebenbei benutzt wurde.

Fehlerquelle #2 war dass tatsächlich RttNom bei nur 2 Modulen nötig ist.
Die Fehler traten nur selten auf, aber es ist reproduzierbar.

Fehlerquelle #3 war RttPark anders als 240 Ohm.
Lief mit 60 Ohm leicht kühler, hat aber seltene Fehler verursacht, mit 80 Ohm sogar teilweise kein boot.

tCL & tRP habe ich kleiner als 14 garnicht probiert.
tRCDRD 17 läuft stabil, mit 16 bleibt der Bildschirm schwarz.

tRFC 300ns läuft stabil, 290ns bleibt der Bildschirm schwarz.
Scheint also wirklich E-Die oder einer der Nachfolger zu sein.
Die Angabe von Taiphoon Burner dass es D-Die sein soll müsste wegen tRFC definitiv falsch sein.

1T ohne AddrCmdSetup 52 klappt selbst mit ClkDrvStr 120 Ohm nicht.

Nebenbei noch aufgefallen dass tRRD/tFAW 6-8-24 immer deutlich fehleranfälliger war als 4-6-16 wenn der RAM nicht richtig stabil war, keine Ahnung warum.
Letzteres (4-6-16) liefert zB in yCruncher mehr Durchsatz und lässt den RAM auch wärmer werden.
Ob da irgendwas zufälle eine Resonanz bildet?

Soll dann nun so reichen.

 

[MHM]

Habe die Kühlbleche letzten Endes doch noch komplett entfernt.
Es sind unterschiedliche RAM Chips verbaut.

Auf einem Modul sind nur die "SpecTek PP048-062E" verbaut.

Auf dem anderen Modul sind es "D9WFL PP069-062E" (die meisten) sowie "D9VPP PP069-062E" (einige).
Die D9VPP haben eine etwas hellere Kunststofffarbe.
Alle Chips besitzen hier beide Logos, von Micron & SpecTek.

Die Platinen selber sehen absolut identisch aus.
Stimmt wohl schon dass bei 3200C16 die Reste verbaut werden.

Es kam relativ dickes Klebepad zum einsatz, dass auf allen Chips gut und gleichmäßig saß.
Würde sagen die Module laufen so auf jeden Fall kühler.

 

[ispasion22]

Hi guys!
It's been a while since I've been reading about Micron here. Lots of advice, top expertise.
For first, 3 years ago, I tried to display my own knowledge. I found that 3600 16-18-18-36 CL1 and 1.38V is the limit. Too weak, but I abandoned it because I couldn't find the time to allocate...

Until a month ago! And I restarted the old research... and I see new things already.
Meanwhile, with the current settings, I found 25 cycles of 1usmus_v3 and 3 of absolutenew@anta777 keep the RAM stable.
However, it can be seen that there are unbalanced values and I am unable to tighten the latencies without errors or crashes. Also, the writing value in Aida seems a bit low.
I would greatly appreciate your advices.
Thank You.

LE: @MHM SpecTek is a low quality bin RAM from Micron

 

[MHM]

Habe es nun eine ganze Weile stabil auf 3200 CL16 am laufen.

3200 2T 16-16-18-16-48-64 @ 1,36v
RttNom 7, RttWr 3, RttPark 4
DrvStr 24-20-24-24
tRRD-TFAW 4-6-16
tRFC 320ns
tRTP-tWR 8-16
SCLs 5 (4 hat keine realen, messbaren Vorteile gebracht, dann lass ichs lieber untouched)

Fehlerquelle für die sporadischen Fehler war doch nicht RttPark RZQ/4, sondern tRTP-tWR 6-12 waren einfach zu niedrig (oder evtl nicht im korrekten Verhältnis zu tRFC).

Für 8GBit Micron E-Die gilt scheinbar:
tRAS = 3x tCL
tRC = tRP + tRAS (= 4x tCL)
Kann mittlerweile absolut bestätigen dass es genau so viel, wenn nicht sogar leicht bessere Real Leistung gibt als kleinere tRAS & tRC.

@Bread
Bei mir ist sowohl tCL als auch tRP beides auf 16.
Aber wenn diese unterschiedlich wären, ist es dann korrekt dass es 3x tCL ist und nicht z.B. 3x tRP?
Frage mich nur weil ich es in deinen älteren Beiträgen mal so und mal so gelesen habe.

Anscheinend gilt dann auch noch dass tRFC von tCL & tRC abhängig ist laut dem Calculator.
Wären bei mir dann mit 3200 CL16 und tRC 64 -> tRFC (512-380-234) = 320ns.

Also sollte ich nicht einfach auf 300ns oder weniger gehen obwohl der RAM es scheinbar könnte?

Und dann gilt scheinbar auch noch:
tRTP = clean divider of tRFCns
tWR = 2x tRTP

So ist es wirklich stabil.
Das ärgerliche sind diese seltenen Fehler die manchmal ewig nicht auftreten und manchmal ganz schnell, als wenn es irgend einen zufälligen Unterschied gibt wie der RAM beim einschalten trainiert bzw kalibriert wird.

 

[Bread]

Habe es nun eine ganze Weile stabil auf 3200 CL16 am laufen.

3200 2T 16-16-18-16-48-64 @ 1,36v
RttNom 7, RttWr 3, RttPark 4
DrvStr 24-20-24-24
tRRD-TFAW 4-6-16
tRFC 320ns
tRTP-tWR 8-16
SCLs 5 (4 hat keine realen, messbaren Vorteile gebracht, dann lass ichs lieber untouched)

Fehlerquelle für die sporadischen Fehler war doch nicht RttPark RZQ/4, sondern tRTP-tWR 6-12 waren einfach zu niedrig (oder evtl nicht im korrekten Verhältnis zu tRFC).

Interessant, danke für das Feedback. Fehler bei TM5?

Für 8GBit Micron E-Die gilt scheinbar:
tRAS = 3x tCL
tRC = tRP + tRAS (= 4x tCL)
Kann mittlerweile absolut bestätigen dass es genau so viel, wenn nicht sogar leicht bessere Real Leistung gibt als kleinere tRAS & tRC.

@Bread
Bei mir ist sowohl tCL als auch tRP beides auf 16.
Aber wenn diese unterschiedlich wären, ist es dann korrekt dass es 3x tCL ist und nicht z.B. 3x tRP?
Frage mich nur weil ich es in deinen älteren Beiträgen mal so und mal so gelesen habe.

Oh, dann muss ich das wohl ausbessern 3x tCL

Anscheinend gilt dann auch noch dass tRFC von tCL & tRC abhängig ist laut dem Calculator.
Wären bei mir dann mit 3200 CL16 und tRC 64 -> tRFC (512-380-234) = 320ns.

Also sollte ich nicht einfach auf 300ns oder weniger gehen obwohl der RAM es scheinbar könnte?

Kannst Du schon. Das ist ja das "lästige" beim RAM. Laufen tut alles irgendwie, und sogar ähnlich schnell und stabil. Also ja, kannst Du, aber mit mehr vDIMM in der Regel. <320ns ist bei mir zB grenzstabil, siehe Beispiel weiter unten.

Und dann gilt scheinbar auch noch:
tRTP = clean divider of tRFCns
tWR = 2x tRTP

"Notwendig" ist nichts davon, laufen tut es auch so. tWR = 2x tRTP läuft bei manchen subjektiv besser. Die erste Regel erschließt sich mir nicht, Zyklen als ganzer Teiler von ns? JEDEC sagt 350ns tRFC, egal welcher Takt & Timings.

So ist es wirklich stabil.
Das ärgerliche sind diese seltenen Fehler die manchmal ewig nicht auftreten und manchmal ganz schnell, als wenn es irgend einen zufälligen Unterschied gibt wie der RAM beim einschalten trainiert bzw kalibriert wird.

Genau diese Fehler sind typisch für tRFC Im Grenzbereich ist das bei mir temperaturabhängig, nach dem Booten Fehler, wenn der RAM warm ist nicht mehr. Kann auch tRCDRD sein, oder CAD-Bus / Setup, ...

 

[MHM]

"Notwendig" ist nichts davon, laufen tut es auch so. tWR = 2x tRTP läuft bei manchen subjektiv besser. Die erste Regel erschließt sich mir nicht, Zyklen als ganzer Teiler von ns? JEDEC sagt 350ns tRFC, egal welcher Takt & Timings.

Wenn ich alles so lasse und nur tRTP-tWR 8-16 auf 6-12 reduziere dann sind die seltenen Fehler wieder da.
Daran ändert auch RttPark 1 oder RttNom 0 zB nichts.
RttPark 3 statt 4 läuft beim ersten Booten, aber beim ersten mal neustarten bleibt der Bildschirm schwarz.

Kannst Du schon. Das ist ja das "lästige" beim RAM. Laufen tut alles irgendwie, und sogar ähnlich schnell und stabil. Also ja, kannst Du, aber mit mehr vDIMM in der Regel. <320ns ist bei mir zB grenzstabil, siehe Beispiel weiter unten.

War mir nicht sicher ob es für die Stabilität oder Performance abhängigkeiten zwischen tRFC und tCL+tRC gibt, wegen dem Calculator.
Wenn es die Abhängigkeiten nicht gibt dann wäre der nächste Schritt die Langzeitstabilität von CL14 und 300ns mal richtig zu prüfen.

Genau diese Fehler sind typisch für tRFC Im Grenzbereich ist das bei mir temperaturabhängig, nach dem Booten Fehler, wenn der RAM warm ist nicht mehr. Kann auch tRCDRD sein, oder CAD-Bus / Setup, ...

Bei 3200 würde tRCDRD 17 auch noch problemlos laufen, aber auf 16 kein boot mehr. Habe mit 18 einfach etwas Sicherheitsabstand gehalten.
Und die seltenen Fehler waren mal da und mal garnicht, nach dem Zufallsprinzip und Temperaturunabhängig.


Das Problem bei mir müssen die durchgemischten RAM Chips sein.
Auf dem einen Modul Chips mit Micron D9WFL & D9VPP Label zusammengewürfelt. Davon alle Chips zusätzlich auch noch mit SpecTek PP069-062E Label.
Bei den Micron D9VPP wurden von 2666 bei SpecTek plötzlich 3200 JEDEC.

Auf dem anderen Modul haben alle Chips nur das SpecTek PP048-062E Label und die selbe Gehäusefarbe..

Die Module sind aus einem Kit und mit fortlaufender Seriennummer.
Wenn beide Module zusammen betrieben werden will mehr als 3200 einfach nicht stabil laufen.
Halt die oft erwähnte 3200 CL16 Resterampe.


Hatte übrigens auch noch leichte Probleme mit USB 3.0 Dropouts.
An den hinteren USB Anschlüssen waren diese auch mit höherer vSoC ganz selten mal aufgetreten.
Seitdem ich Spread Spectrum im UEFI auf Auto gelassen habe sind die komplett weg.
Habe auch mittlerweile schon viele TB Daten drüber gejagt und per MD5 verifiziert.

Lediglich an den beiden Front USB 3.0 sind die noch vorhanden.
Aber ich glaube es sind minderwertige Kabel zum Frontpanel verbaut.
Wenn dort ein USB 3.0 Gerät wie zB Cardreader angeschlossen wird trennt es hin und wieder mal, und zieht dann manchmal auch Geräte an den hinteren USB Anschlüssen mit.
Sogar die USB 2.0 (oder älter) Maus trennt es dann mitunter kurz.

 

[Mr.Mito]

Kann mittlerweile absolut bestätigen dass es genau so viel, wenn nicht sogar leicht bessere Real Leistung gibt als kleinere tRAS & tRC.

Ich wollte das ja ehrlich gesagt nicht glauben, kann es aber auch bestätigen. Ich habe 34-62 und 48-64 verglichen.
Aida 64 0 Unterschied
Membench 0 Unterschied
Geekbench 3 je 4 Läufe gemittelt - Messtoleranz / kein Unterschied

Ich schau mal noch ob 32-58 schneller ist, glaube es aber nicht mehr. Wieder was gelernt.

EDIT:
32-58 auch 0 Unterschied.

 

[Bread]

Na bitte. Läuft jetzt entspannter und gleich schnell

 

[Mr.Mito]

Zumindest im Bezug auf nötige Vdimm änderte sich (leider) auch nichts. Das wäre ein netter Nebeneffekt gewesen.

 

[Bread]

Hatte übrigens auch noch leichte Probleme mit USB 3.0 Dropouts.
An den hinteren USB Anschlüssen waren diese auch mit höherer vSoC ganz selten mal aufgetreten.
Seitdem ich Spread Spectrum im UEFI auf Auto gelassen habe sind die komplett weg.
Habe auch mittlerweile schon viele TB Daten drüber gejagt und per MD5 verifiziert.

Interessant. Gerade wieder was gelernt. Rechner läuft 100% stabil mit diesen RAM OC Settings::

Hab jetzt mal testweise Spread Spectrum auf Enabled gestellt (vorher Disabled), da ging gar nichts mehr. Rechner hat manchmal noch gebootet, aber dann recht schnell Blackscreen und "Memory Test Failure" nach 5 Post Versuchen. Man liest ja widersprüchliches dazu, die einen sagen Spread Spectrum bringt Stabilität beim OC, die anderen sagen es kostet Stabilität.
Bei mir eindeutig zweiteres, Empfehlung: Spread Spectrum Disabled!

@MHM auf was war es vor "Auto" gestellt, Enabled oder Disabled?

 

[MHM]

Hatte es von Anfang an auf Disabled weil es überall empfohlen wird. Schon ewig bei jedem Mainboard.
Soll ja nur den Takt permanent leicht variieren um die Störabstrahlungen auf ein breiteres Spektrum zu verteilen, für die Zulassungen.

Jedenfalls bleiben nur auf Auto (Enabled garnicht probiert) die seltenen Dropouts an den hinteren Ports weg.

Könnte evtl mal probieren was passiert wenn es Disabled ist, ich jedoch die Front-Anschlüsse abstecke, bzw sie mit Adapter nur an USB2 anschließe.
USB 3 an den Front Anschlüssen ist immer instabil, egal was ich einstelle. Vermutlich die Kabel.

Hatte anfangs immer das RAM-Tuning im verdacht.