[Sammelthread] Ryzen DDR5 RAM OC Thread

Anhänge

  • ZenTimings_v1.32.1251-debug.zip
    568,6 KB · Aufrufe: 83
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
VDDQ_MEM ≠ VDDIO or VDD2 (MC-LINK)
VDDIO < VDD_MEM
 
VDDIO/VDD/VDDQFür bestmöglichste Stabilität sollten VDDIO/MC (Speichercontroller) und VDD synchron eingestellt werden.
Nach aktuellem Stand ist aber auch eine niedrigere Spannung möglich.
Bei Auto Einstellung wird vom Board automatisch 1:1 die VDD Spannung für VDDIO/MC übernommen.
VDDQ darf nicht höher sein als VDD.
?
 
halte ich für überholt die Regel

VDDIO = VDDQ
VDDQ < VDD

bringt auf meinem System Stabilität
 
bei meinem B650M-HDV/M.2 geht VDDIO nur bis 1,35V, denke das ist ein Bug. Ich kann nichtmal VDDIO=VDD=VDDQ machen. Also wenn ich alle 3 Werte zB auf 1,40v stelle hab ich dann 1,35v VDDIO und 1,40v VDD und VDDQ.

Ich denke der Bug limitiert mich auch bei meinem Memory OC, für 8400 hab ich schon teilweise echt miese Timings gebraucht und es wollte nie 100% stabil werden. deshalb bin ich jetzt auf 8000c38 runter, das ist stable as a rock.

Und wenn wir schon bei Bugs sind, Geardownmode und ProcODT Einstellungen im Bios sind bei mir auch ohne Funktion.
 
Und wenn wir schon bei Bugs sind, Geardownmode und ProcODT Einstellungen im Bios sind bei mir auch ohne Funktion.
Das war bei meinem Taichi anfangs auch so, hat sich mit nem Update irgendwann erledigt.
 
Alter Asus standard.

VDDIO = < / = VDD_MEM
VDD2_CPU link aka VDDIO aka MC, ist eine eigene Spannung ~ erstellt in der CPU

VDDQ_MEM
& VDD_MEM sind eine eigene Spannung, erstellt auf der anderen Seite des Boards.
PMIC controller. Allerdings LDO's

VDDQ_CPU & VDDIO , können ähnlich sein ~ WENN VDDQ_MEM & VDD_MEM gleich sind.
Allerdings ist VDDQ_CPU automatisch bei AMD, und mitterweile rennen wir
1707662821363.png

Nur das wie gesagt, VDDQ_CPU auf AMD automatisch antrainiert wird.

Beide Werte
1185 & 1410 mV = nahe zu selbe (A)
Den Spannung bedeutet garnichts.

Es kommt auf die CPU impedance, und für VDDIO die procDQ impedance ~ an
VDDIO = VDD2 = DQ :)
Die Bedeutung.
VDD2 = DQ (CK, CA, CS) Vref
Es wird VDDIO genannt, da die APU mitversorgt ist.
Es bleibt eine LDO wie fast alle Spannungen. ProcODT als Haupt influencer von dem Rest.
 
Zuletzt bearbeitet:
Hallo ihr Lieben,
leider war ich beruflich bedingt unterwegs und hatte keine Zeit weiterhin RAM OC zu betrieben.
Ich freue mich zu sehen, dass das Forum noch lebt :)

Zu meinen Ungunsten habe ich ein Biosupdate (Gigabyte B650E) gemacht (F8 auf F21) welches ich mittlerweile wieder Rückgängig gemacht habe, jedoch sind leider alle meine Einstellung weg.
Von meinen Timings und Spannungen habe ich genügend Screenshots und auch hier im Forum zum Glück einen meiner letzten Posts.

Wenn ich in der Vergangenheit von 0 begonnen hatte, sah mein Weg wie folgt aus:

BIOS Settings: --> = BIOS Save and restart
iGPU off--> MCR off --> Power Down off --> GDM off --> Spannung setzen --> FCLK setzen --> Timings setzen --> fertig ( natürlich noch Tests und Co, aber im Bios wars das)
Aktuell bekomme ich MCR deaktiviert, jedoch nicht GDM und Power Down. Beim Start hänge ich dann im black screen und das Bios setzt sich wieder auf Werkseinstellung. (MCR ebenfalls wieder an)

Fast Boot Off
TSME Auto
TPM switch AMD CPU fTPM
IOMMU Auto
SVM Mode off
SMT Mode Auto
PSS Support on
PPC Adjustment PState 0
Global C-state Controll Auto
SMT Mode Auto
Power Slow Slew Rate Auto
CPU Vcore Loadline Cal. Auto
Async CPU/PCIe Clock off
GFX Glock Frequency Auto
PBO off
CSM Support Off


VDDG Voltage Control (CCD00 = 950 mV, IOD00 950mV)

CPU Clock Control Auto
Habe ich irgendetwas vergessen aktivieren bzw zu deaktivieren?
 
Zuletzt bearbeitet:
Ein weiterer Nutzer/Reviewseite welche Memory timings nicht skallieren können~
Anhang anzeigen 948571

Wenn man schon sich die mühe macht ein Video zu schneiden
So sollte man wenigstens auch versuchen die Timings gleichzustellen.

Ebenso muss man gegentesten ob FCLK nicht schon beginnt zu trotteln wenn man aus heiterem Himmel 150mV wegschneidet.
Anhang anzeigen 948566
Beitrag automatisch zusammengeführt:

Abseits autocorrection , könnte es sogar gleich enden. Den einerseits sind Spiele keine Benchmarks und andererseits füllen sie kaum Ram bzw nicht jeder Test füllt den X3D Cache.
Aber hier testet man Äpfel vs Kirschen.
Birnen wären es , wenn man wenigstens PostPackageRepair bei Mem nicht erzwingen würde mit den "zuu niedrigen" 2ndaries bei 7800.

Äpfel vs Äpfel wäre es dann wenn man die Spannungen gleich lässt, und das 6400er Preset hochskaliert.
Oder beide auf 2100 FCLK rennt mit niedrigen Spannungen (da ansonsten Gear 2 womöglich nicht stabil sein wird)

Hier hat man 3+ Variablen und ich selber könnte nichtmal herausfinden was man überhaupt vergleicht
~ Skalliert der Titel mit MCLK
~ Skalliert der Titel mit niedriger Zugriffszeit
~ Kümmert es die CPU wie hoch UCLK rennt.

Ich weiß es nicht. Was testet man ?
Allerdings haben solche Ergebnisse zuu viele Variablen und man sollte es besser nochmal versuchen.
Beitrag automatisch zusammengeführt:


COD als sehr unoptimierter Titel könnte sogar skallieren
Valo, nur wenn es mehr als 4 Kerne ladet
CS , eigentlich das selbe.
Apex womöglich das selbe. Recht unoptimiert und eine Große map + kann 24 threads belasten. Sollte rüberleaken

Alles nur wenn die Kerne auch den Max boost halten und der Nutzer nicht dank zuu niedrigem CO throttled.
Dann , könnte man eventuell im Cache limiter landen und erst dann ! , spielt es eine Rolle wie schlecht Optimiert bzw wie Groß der Titel ist den man rennt.

Nach all diesen Variablen
Sollte man 7600MT/s auf 4 dimm-slot Boards einfacher hinbekommen, bzw 7800 auf 2 Dimm-Slot Boards
Als das 6200/6400 Gegenstück. Bei niedrigerer Spannung.

Was 2100 FCLK dann benötigt ist eine weitere Variable
Aber für X3D CPUs ist die Interne Bandwidth nahe zu 500GB/s.
Es ist genug. FCLK ist halb/unwichtig.
Da spielen zwischen 80GB/s mem und 100GB/s mem kaum eine Rolle.
CoreClock aka Cache-Clock spielt eine wichtige Rolle ~ und dann je nach Titel ob Cache rüberleakt (aka zuu voll) oder der Titel ein IndieSpiel ist bzw keinerlei kerne auslastet.

Keine Kernlast = genug cache = mem unwichtig.
Soweit sehe ich keinen Reviewer/Public Media - auch nicht die Mainstream internationalen ~ welche es per SKU korrekt testen.
Damit inkludiere ich 25+ Reviewer und Tester - including Overclocker.
Es ist traurig. Man missversteht was man eigentlich testet.

EDIT:
Von dem kleinen Teil an Overclocker welche es versuchen zu testen kommt dann
"X skalliert nicht, Y ist zuu schwer zu rennen ~ brauchst du nicht. Not worth it"
Leider denke ich dass auch das eine fehlerhafte Zeichnung der Realität ist
Es muss nicht skalieren damit es in der Realität schneller sein kann/bzw schon ist.

Wenn MCLK immer skalieren würde wie bei Zen1/2, dann deutet das auf ein Architektur Problem.
Ja, X3D Leakt noch Cache (leider). Ich habe es selber getestet. Aber es ist soo selten und nur bei sehr unoptimierten Titeln. Bei voller Auslastung !
// NonX3D 1CCD umso mehr ~ aber die haben eher FCLK probleme.
Das macht Gear2 weiterhin nicht irrelevant oder "schlechter". Nur dass es aufgrund vielen anderen vorherigen! Variablen, Memory als solches selten beginnt eine Rolle zu Spielen.
// UCLK ist intern. MemoryClock ist extern , weit weg von der CPU.
Dennoch ist es einfacher 1850-1950MHz Gear 2 zu rennen, anstelle 3200-3300MHz Gear 1 🤭
Wie immer, das ist nur meine Sichtweise und Beobachtung. Man muss nicht unbedingt die selbe hegen~~
Hm, alles ja hochinteressant. In Verbindung mit den Spannungsangaben und Widerständen und low UCLK!

Habe meinen RAM getauscht um im hohen MT save zu sein. BIOS Update meines 4 DIMM Boards.

Habe nun 7400 mit IF 2200 UND LowLewel SOC (ehemals 1,265V bei 6400/2166, nun 1,1V bei 7400/2200) mit dem stabilstem RAM Setting am laufen. AIDA zeigt IMMER die "gleichen" Werte. Max Abweichung 10 MB / 0,1 ns. VDD 1,4 / VDDQ 1,42. Die niedrige VSOC Spannung bedeutet eine enorme Entlastung der CPU (ca 3-4 Watt weniger PP und 2-3 Grad kühler) und belastet nun eher das Board.

cachemem_28-7400_2200_2_ZenTimings.png
cachemem_28-7400_2200_2.png



Es folgt dann 7600/2200 ohne großartigen Einfluss und geringem Performancegewinn, auch stabil mit gleichen Widerständen und ählichen Spannungen (VDDQ/VDDIO +0,01).

Ein Low-Level-Versuch mit 7800/2000 hat schon einmal gebootet und TM5 einen Durchlauf bestanden. Aber nur mit graziösem Einstellen der Spannungen und Widerständen. Eine echte Totur :(.
Hoffentlich gibt es bald BIOS-Updates, die auf meinem 7-Layerboard mehr möglich machen.

cachemem_30-7800_ZenTimings-RAMok.png


Ergänzung: 7800 mit etwas mehr VMEM läuft nun auch ohne Fehler. Aber nur mit laschen Timings. Denke die Signalwege des Board geben nicht mehr her. :(
 
Zuletzt bearbeitet:
Ich frage mich gerade, wenn die CLDO VDDP-Spannung zu niedrig ist, wie äußert sich das?
Direkter Absturz oder bootet garnicht erst?

Ob das TestMem5 mit Fehler "xy" anzeigt?
 
Ich frage mich gerade, wenn die CLDO VDDP-Spannung zu niedrig ist, wie äußert sich das?
Direkter Absturz oder bootet garnicht erst?

Ob das TestMem5 mit Fehler "xy" anzeigt?
Fehler #5
Can be incorrect RTL training,
or on AMD too high/low cLDO_VDDP & ClkDrvStr causing tPHYRDL missmatch

TM5 1usmus
 
@Veii
@RedF
@LuxSkywalker

Ich hatte ja gesagt ich schreibe Kelutrel an wegen dem core to core Thema in Ropbench.
Anbei die Antwort von ihm.

It is not a bug. That is the core-to-core latency, not the RAM latency or the cache latency. It measures the time for a new byte written by core X to be available for reading by core Y (represented by the X and Y coordinates of that chart).

For example, on a 7950X, if you write a new byte value in a memory location with a CCD1 core, it will take 125-135ns for that new byte value to be "seen" by a CCD2 core. Because that new byte has to go through the three levels of the caches of CCD1 and up to the RAM, and then from the RAM down and through the 3 levels of caches of CCD2, so on average it will be double the ram latency plus some bits for traversing the caches, that is what the tool displays. In that chart, your CCD1 cores are top left, and your CCD2 cores are bottom right.
The values displayed are correct and pretty precise. Afaik there is nothing similar in AIDA64. That latency is also one of the reasons why AMD, on X3D models, limits a videogame on a single CCD even on dual CCD cpus. The latency between CCDs is so high that (depending on how much that game is memory intensive) the performances may suffer even with double the cores. Maybe the color is what made you worry, I should have used a blue tint probably.

If you want to measure the RAM and cache latency instead, in a similar way to AIDA64, you can click on the "RAM & Cache" button
 
@Wolf87
Makes sense if he tests L1D to L3 to Cache to L1D back
While i hoped for L1D or if bigger command ~ L2 to L2 betweeen cores.
// Where there are 1 op (zero delay) transfers and normal (long dly) transfers
L3 is shared, soo tracking is difficult

Most commands get broken down into chunks and allocated ~ without ever leaving cache
To my understanding
That should happen on all games, which is what can expose unstable CO or FCLK Package throttle

But i think if the understanding was to target mem oc effectiveness.
~ the cache to mem to cache approach is something that can visualize when MCLK pushing makes sense or not

Hmm difficult.
Optimally would be if both ways are testet and displayed as different visual examples, as this L$ - MEM - L$ , method already should be similar to Cache & RAM test.
Yet nothing of both should actively show FCLK Throttle ~ given that part is load balanced and may not be easily viewed as unstable (low load?)

EDIT:
If we do aim to show dynamic throttle into access time values
Internal testing should not leak to mem.
Above test is an alternate approach for very likely correct target, yet not what i was personally looing for as SiSandra replacement.
// And it will explain why values are different too. We look at two different questions. :d
 
Zuletzt bearbeitet:
90 Minuten in 99,9% Isopropanol gebadet. Musste noch ein bisschen mit der Rasierklinge nachhelfen. Ich war sehr vorsichtig und hoffe, dass die noch funktionieren :)

IMG_4708.jpg



@Veii Type A A-Die vermute ich? Es sind 7200C34 Corsair Vengeance für 149€ (Aktuell 155€)

IMG_4709.jpg
 
Hast du da den Kühler zerbrochen? Ist das alles verklebtes Plastik, das ohnehin schwer abgeht? Zurückbauen ist nicht mehr möglich?`
 
abbrechen musste ich nichts, ist alles verklebt. Rückbau wäre möglich, dann müsste ich mir Pads besorgen, die sind nicht mehr verwendbar.

Hab mir von Alphacool Heatspreader bestellt. Die sind recht massiv und teste gerade, wie warm die jetzt werden. Ob das überhaupt sinnvoll war, wenn ich die nicht in eine WAKÜ einbinde (werde ich nicht tun) sei mal dahinhgestellt. Der Basteldrang war stärker.

Hab mir noch zwei 40mm Noctua Lüfter bestellt, die kommen nächste Woche. Allein ein CaseFan im Deckel Richtung RAM blasend hat schon mit den Original Heatspreadern ca 7 Grad gebracht. Ich denke mit direktbewindung kann ich dann Richtung 1.6v gehen.


4710.jpeg
 
Die schwarzen Stücke oben links sehen so aus als ob sie abgebrochen sind, daher frage ich.

Die AC-Kühlkörper sehen schonmal klasse aus. (y) Das sowas nichts werksmäßig verbaut wird, immer dieses Plastik.

Die Temperaturen liest du dann auch im Hwinfo aus oder?
 
Also meine Crucial Pro DDR5-5600-CL46 Kits gehen mit 1,11 V auf~34 °C. Welche Temperaturen hast du mit dem Kit vorher gehabt?

1707857464090.png


Vor allem die Gesamtleistung würde mich mal bei den OC-Kits interessieren. ^^ Die muss ja weit über 1 W sein.
 
Zuletzt bearbeitet:
@gimme7

Falls du nicht eh schon nen Lüfter drüber hattest, wird das leider relativ wenig bringen.. Aber Basteldrang verstehe ich! :)

Ohne großartigen Airflow dauert es halt nur ein paar Minuten weniger bis sie warm werden, und irgendwann hast du die selbe Temperatur wie vorher. Hatte schon lange keine Wakü mehr auf meinen RAMs, erst
mit DDR5 jetzt wieder und das Zeugs geht halt einfach nicht höher als 10°K über Wassertemperatur, das ist schon nett. Wieviel es jetzt tatsächlich taktseitig bringt, ist natürlich wieder die andere Frage.

Ich geh da übrigends deutlich "rabiater" vor, aber eventuell auch nur weil ich schon sehr viele HS abgemacht habe.. Einfach 2-3 Minuten mit der kleinen Heißluftpistole drauf und dann mit "Gewalt" abziehen,
klappt i.d.R. ohne Probleme.
 
Ohne großartigen Airflow dauert es halt nur ein paar Minuten weniger bis sie warm werden, und irgendwann hast du die selbe Temperatur wie vorher
ja, das erwarte ich auch. Nach 60min Karhu ist es noch ca. 7 Grad kühler als mit den alten Heatspreadern. Airflow bleibt trotzdem Pfilcht, wenn es >1.4v geht.

Also meine Crucial Pro DDR5-5600-CL46 Kits gehen mit 1,11 V auf~34 °C. Welche Temperaturen hast du mit dem Kit vorher gehabt?
mein Alltagssetting mit 1.4v braucht noch keine aktive Kühlung. Das lief ganz normal. Aber als ich dann die Timings noch angezogen habe wurde es ab ca 48 Grad instabil beim Stresstest. Da hat schon ein bisschen Airflow über den RAM geholfen.

Die muss ja weit über 1 W sein.
ACT.PNG
 
Dann wird der SPD Hub bestimmt nicht die richtige Baustein-Temperatur anzeigen. Eigentlich müssen die DRAM-Bausteine auch so 90 °C bis 110 °C schaffen. Interessant, dass es dann ab 48 °C. Klasse danke. (y)

3,5 W sind auch mal eine Ansage. 3,512 / 0,668, das ist mehr als 5x. Unglaublich.
 
Hab jetzt ma spasseshalber 1.68V Vdd auf die RAMs gejagt, aber bei Wakü passiert da einfach garnix, die ~ 12W Verlustleistung erhöhen nicht mal auf Dauer signifikant die Wassertemperatur.. :)
Screenshot 2024-02-13 223033.jpg
 
Watt zu Hitze waren schon immer ein schwieriges Problem.
Der PMIC kann zwar aus dem 5V Input, die ungefähre Verbrauchsleistung aus den SWA,SBW,SWC (+SWD) LDO's rauslesen & mathematisch runden (Watt wird /h ausgerechnet)
Jedoch fehlen UDIMM Sticks die Temperatursensoren (TS) zwischen beiden subchannels (links/rechts pro Seite) ~ um die genauen Thermischen Verluste bzw erhöhtem Stromverbrauch auszurechnen.

In der Realität liegen etwa 12-15° zwischen den IC Bausteinen und dem Spannungswandler (PMIC)
Sowie können die ICs weitaus mehr verbrauchen als die 5V Rail es angibt.

Die Spannungen von dem Mainboard (24pin) bis zu dem PMIC (eine kurze Strecke)
Sowie die Spannungen von dem Memory Controller ausgehend, über dem Mainboard, zu den Dimm-Slots
Wird als Bi-Directional Rail (32+7+21 Traces) mit den schon anliegenden Spannungen von dem PMIC innerhalb des RAMs ~ synchronisiert.

Die Daten Kommunikation geschieht somit in den Differentialschienen (differential rail) ~ zwischen einem Signal High (HI) & Signal Low (LO)
Der Rest der Kommunikation erfolgt über dem i²c Bus von dem SPD-Hub. Bzw im Server Segment wären das 12v & i³c.

Aufgrund dessen kann man zwar den Isolierten Input vorhersagen;
Dennoch wird dies niemals den echten Stromverbrauch des gesamten Sticks darstellen.
Abseits davon dass man Watt/sec nicht messen kann. Sondern nur pro Stunde.
Und "12W" sich nicht exakt als Temperatur übersetzen lassen können, Aufgrund der Transistordichte eines einzelnen ICs.
brave_oIT7xwQ8Ny.png
brave_e1ZFkC0dO5.png

Jeder dieser (1 Transistor 1 capacitor) Zellen muss seine Daten zeitlich halten und auf Abfrage abgeben.
Eine Bank ~ hat 65536 solcher Transistor-Zellen.
 
Zuletzt bearbeitet:
The file in attachment contains version 1.71 of the RopBench tool.
The SHA-256 of the original archive is: b824fc9745d5056426b6e3ed99b96c6d262ebc816a6500eeb1f46881d99614b3

This is just a minor update. In this version:

  • Fixed a startup error when cores are not a multiple of 8, like on 7600X or 7900X (Kudos to @Veii for finding it and @RedF for reporting)
 

Anhänge

  • ropbench_v1.71.zip
    3,1 MB · Aufrufe: 73
1.55v VDD, Temps sehen noch ganz gut aus.


780034.PNG
 
das setting über diesem Beitrag hat in 25 cycles 5 Fehler geworfen. Hab festgestellt, dass Linpack 8GB Stresstest nach 2 Minuten fehlerhaft war. Erhöhung der VSoc hat Abhilfe geschaffen.
VDD aktuell auf 1.57, VDDQ 1.55, VDIO 1.45v

Ne Idee, was ich noch probieren kann?

7800error.PNG
 
das setting über diesem Beitrag hat in 25 cycles 5 Fehler geworfen. Hab festgestellt, dass Linpack 8GB Stresstest nach 2 Minuten fehlerhaft war. Erhöhung der VSoc hat Abhilfe geschaffen.
VDD aktuell auf 1.57, VDDQ 1.55, VDIO 1.45v

Ne Idee, was ich noch probieren kann?

Anhang anzeigen 971011
Suspect tWR being too slow (lower value required)
mostly affects the first 5 main timings
- noticed it can be tRCDWR to RD, can be tRP too,
but it also can be the last two tRDWR & tWRRD
which don't play well with your main tRCDWR/RD

#10 at the very start = increase RTT_NOM to something stronger

Versuch mal RTT Nom
 
ok, die sind beide OFF, also mal mit dem niedrigsten Zahlenwert probieren (habs nicht so mit elektrik)?
Die Fehlerbeschreibungen kommen ja noch aus DDR4 Zeiten. Ist das auf DDR5 anwendbar?

Jetzt läufts gerade mit 0,02v mehr VSoc nochmal und ist im 6ten Cycle. Fingers Crossed.
 
Sollte DDR5 sein, genau fang mit dem niedrigsten Widerstand in OHM an : )
 
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