[Sammelthread] Ryzen DDR5 RAM OC Thread

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
testing now 6000Mhz 4x32gb with auto timing and get error in y-cruncher N63 after 2 hours with combo tests (FFT,N63,VT3), SOC was 1.24 LLC2, after that i increase SOC to 1.25 and pass separate N63 2-hours (71pass), also passed separate 2 hour tests FFT and VT3 . Issue with SOC or VDDIO/VDDQ or maybe RTT/ODT?. Tried to disable GDM but no POST, but sometimes can with RTT 0-0-4-5-6 or 0-0-5-5-6 but at windows loading get bsod. also tried 3-3-5-5-6 and procdqds 60. It looks like it was a lack of voltage on SOC because I passed 9 hour combo test.

VDDIO 1.37 (hwinfo/bios monitoring shows 1.352v)
VDD 1.4 (hwinfo shows 1.38)
--
VDDQ 1.19 - reboot at windows loading
VDDQ 1.20, 1.21 - errors in TM5 13, 10
VDDQ 1.22 - pass 25 cycles (hwinfo shows 1.23-1.245v at idle and with FFT test 1.215v)

maybe better to use RTT_WR 4?, tried 5 but get many errors

First I want to achieve stability on auto-timings, and then tighten them up

should tPHYRDL match or not necessary?, now 34/36 and tRDWR 19/20
with VDDP auto (0.950v) tPHYRDL match, but the system seems to become unstable after training, more tests are needed

6200 mhz not stable, can't pass y-cruncher VT3, It seems that my cpu does not run FCLK 2000 at this memory frequency. Increasing the VDDG to 980/930 helps a little but still errors VT3
 

Anhänge

  • 6000_test_vddq1.22_soc1.24_llc2_tm5_25pass.png
    6000_test_vddq1.22_soc1.24_llc2_tm5_25pass.png
    39,1 KB · Aufrufe: 99
  • 6000_test_vddq1.22_soc1.25_llc2_N63_71pass.png
    6000_test_vddq1.22_soc1.25_llc2_N63_71pass.png
    55 KB · Aufrufe: 96
  • hwinfo_fft.jpg
    hwinfo_fft.jpg
    673,5 KB · Aufrufe: 100
Zuletzt bearbeitet:
Thanks for the heads-up!

Tried the "minimum calc settings" again while using the adjusted VDDQ + VDDIO (1.37V) - consistency checks look promising, will then lower tWTRS and see what that does!

Then: Round of stress tests again ; )

1713379799269.png
 
Thanks for the heads-up!

Tried the "minimum calc settings" again while using the adjusted VDDQ + VDDIO (1.37V) - consistency checks look promising, will then lower tWTRS and see what that does!
Then: Round of stress tests again ; )

Anhang anzeigen 991287
Good morning,
This one should be your fast check.
Dont worry too much about improving the score. Its one of many fast tests.

It doesnt load full mem (barely means much), only checks consistency between random access's.
There are better ways to check internal improvement with tools like ropbench and SiSoftware Sandra. Geekbench versions and all sorts of other benchmarks.
Y-cruncher raw speed indicators. Many ways on many different workload types

Alright~

EDIT:
You likely know, but voltages changes without stability tests ~ is not a good idea
// because ECC is a thing. It takes a lot of throttle amount, before becoming unstable.
Voltage + Timings change at the same time, neither.
 
Zuletzt bearbeitet:
Welches 2x16GB RAM Kits würdet ihr aktuell empfehlen?
Ich hab aktuell CMH32GX5M2B6000Z30
 
Zuletzt bearbeitet:
Welches 2x16GB RAM Kits würdet ihr aktuell empfehlen?
Ich hab aktuell CMH32GX5M2B6000Z30
Was ist das Ziel
Sind fast alle Hynix Class V , A-Die momentan.
Solange man keine 8200 kits kauft, ist fast alles low tier A-die.

24gb sticks ehrlich gesagt. Und auch diese sind nahezu alle gleich.
Jedoch, was ist das Ziel ?

ASRock Board
Womöglich etwas Corsair, Teamgroup, Kingston, Klevv , V-Color ~ artiges
Sind alle auf dem selben PCB, mit Ausnahme RGB extra's.

Klevv Cras V vlt
die neuen Corsairs
Ah alles das selbe~

G.Skills laufen am besten auf ASUS Boards
ASRock rennt gut die Hsien Jinn PCBs ~ 8 oder 10 layer.
Mit anderen Worten die selben welche Klevv nutzt. Typisch matt schwarzen OEM.

Empfehlung,
Kein Geld für RAM ausgeben, solange die Samsung 4GB (32gb per side) nicht draußen sind.
Alles nahezu das selbe;
Die neuen Crucial Pro's sind spannend für high Clock, aber das war es auch schon
Beitrag automatisch zusammengeführt:

Du kannst dein Glück mit diesen aus Amazon versuchen, und wenn sie dir nicht gefallen wieder zurück
Müssten "failed 8000MT/s ICs sein, vlt vlt erwischt du ja die Class A's anstelle Class V's". Die Cras V sind definitiv fast alle Class V , A-Dies.
XMP runter auf 6000-6200MT/s (MHz) Primäre timings auf 32-39-39 und das passt. Alles andere hat auf Auto einfach zu rennen;
Wenn es gute ICs sind, könnten die womöglich auch die 6200 CL28 bei den standard 1.4v rennen ~ wer weiß.

Oder wir Spielen keine IC lottery und nehmen irgend ein 24gb kit, egal welches
Dann passt es auch
Wie zb
oder
6400MT/s Gear 1 wird schon mal "nicht" rennen, da es ungefähr 2/10 CPUs können, abeer das selbe wie oben ~ AMD EXPO/XMP laden, frequenz auf 6200 runter und es passt

Und solange du kein Micron oder Samsung kit erwischt (auslesbar), kann es nur eines sein :d

Jau,
nichts besonderes auf dem Markt momentan.
Beitrag automatisch zusammengeführt:

Wenn du Glück hast,
@cloudconnected
Dann rennt das ~ sehr altes Ergebniss
brave_kBVjWicLj3.png

auf 1.38v VDD_MEM & VDDQ_MEM ~ bis 1.42v realistisch für 6200MT/s C28.

Und wenn du nicht so viel Glück hast
Das ~ auf 1.3v :)
Die Mem RTT & Processor ODT kannst du ignorieren.
 
Zuletzt bearbeitet:
Hab en Asrock Board und halt die CMH32GX5M2B6000Z30
Da meine CPU nicht mehr als 2000FCKL macht wäre straffe Timing auf 6000 erstmal das Ziel.
Ich weiß aber nicht was auf meinen Corsair für Dies verbaut sind.
SK Hynix ob M oder A keine Ahnung.

Warum gerade die 48er Kits?
Was wird an den Samsung 4GB (32gb per side) interessant?
 
Zuletzt bearbeitet:
after that i increase SOC to 1.25 and pass separate N63 2-hours (71pass), also passed separate 2 hour tests FFT and VT3
So, I tighten up the timings, passed 25 TM5 cycles. Perhaps i can improve some timings. Screen below

by the way I use for all tests
TX DFE Taps = 1 taps
RX2D voltage step size (2^n) = 1
TX2D voltage step size (2^n) = 1
RX DFE Taps = 1 taps

Tried to disable GDM but no POST, but sometimes can with RTT 0-0-4-5-6 or 0-0-5-5-6 but at windows loading get bsod
The POST goes through and loads into Windows with voltages VDDIO=VDD=VDDQ=1.4 and RTT's 4-4-4-5-6 or 0-0-4-5-6 but unfortunately bsod crashes (system service exception) when starting tm5. Increase procdqds to 60,80 not helped. I think need more voltage =( or other RTT/ODT or proc CS/CK. tPHYRDL match with GDM off 35/35

**It seems that some timing is too tight, it gave an error in VT3. it looks like these timings give an error tWTRL/tWRWRSCL increased to 20/13 and VT3 passed 108 cycles without errors.
Passed karhu 2h, using this KGuiX - Advanced GUI for Karhu RAM Test (Today there will be a new version 2.1.4 with a fix for displaying speed on regional Windows)
 

Anhänge

  • 6000_test_vddq1.22_soc1.25_llc2_TT_tm5_25pass.png
    6000_test_vddq1.22_soc1.25_llc2_TT_tm5_25pass.png
    41 KB · Aufrufe: 122
  • cachemem6000_tt_1.png
    cachemem6000_tt_1.png
    87,8 KB · Aufrufe: 135
  • 6000_gdm_off.png
    6000_gdm_off.png
    17,9 KB · Aufrufe: 120
  • pyprime2.2_6000_tt.png
    pyprime2.2_6000_tt.png
    10,3 KB · Aufrufe: 95
  • y-cruncher_bench_25b.png
    y-cruncher_bench_25b.png
    38,4 KB · Aufrufe: 59
  • y-cruncher_bench_10b.png
    y-cruncher_bench_10b.png
    40,2 KB · Aufrufe: 49
  • y-cruncher_bench_5b.png
    y-cruncher_bench_5b.png
    35,8 KB · Aufrufe: 47
  • y-cruncher_bench_2.5b.png
    y-cruncher_bench_2.5b.png
    39,9 KB · Aufrufe: 54
  • 6000_test_vddq1.22_soc1.25_llc2_TT_twtrl_VT3_107pass.png
    6000_test_vddq1.22_soc1.25_llc2_TT_twtrl_VT3_107pass.png
    52,2 KB · Aufrufe: 60
  • 6000_test_vddq1.22_soc1.25_llc2_TT_twtrl_karhu_2h_pass.png
    6000_test_vddq1.22_soc1.25_llc2_TT_twtrl_karhu_2h_pass.png
    137,4 KB · Aufrufe: 83
Zuletzt bearbeitet:
Hab en Asrock Board und halt die CMH32GX5M2B6000Z30
Da meine CPU nicht mehr als 2000FCKL macht wäre straffe Timing auf 6000 erstmal das Ziel.
Ich weiß aber nicht was auf meinen Corsair für Dies verbaut sind.
SK Hynix ob M oder A keine Ahnung.
Neue Speichermodule würde ich mir an deiner Stelle nur kaufen, wenn du mehr Speicher brauchst oder basteln möchtest.

Info aus dem DDR5 Info- & Laberthread 2024

1713529472405.png


Anschließend kannst du dir aus den Ryzen 7000/8000 DDR5 OC Chart im Startpost zu deinen Chips etwas passendes raussuchen.
Wenn du Spaß am Tuning hast kannst du die Timings noch weiter optimieren.
 
Zuletzt bearbeitet:
Good morning,
This one should be your fast check.
Dont worry too much about improving the score. Its one of many fast tests.

It doesnt load full mem (barely means much), only checks consistency between random access's.
There are better ways to check internal improvement with tools like ropbench and SiSoftware Sandra. Geekbench versions and all sorts of other benchmarks.
Y-cruncher raw speed indicators. Many ways on many different workload types

Alright~

EDIT:
You likely know, but voltages changes without stability tests ~ is not a good idea
// because ECC is a thing. It takes a lot of throttle amount, before becoming unstable.
Voltage + Timings change at the same time, neither.
Alright, ran some set of stress tests to verify new voltages with tWR = 66 failsafe (gave more consistent results in Pyprime running several iterations in a row) to have an updated baseline. Will now test tWRTS = 4

Speed of Karhu >50k % was at 283.42 MB/s
 

Anhänge

  • 20240419_Full stress test suite.png
    20240419_Full stress test suite.png
    1,6 MB · Aufrufe: 65
  • 20240419_Consistency check.png
    20240419_Consistency check.png
    1,6 MB · Aufrufe: 57
Zuletzt bearbeitet:
Hi zusammen. Ich habe nun mal verschiedenes ausprobiert und bin einigermaßen überrascht, dass "auf dem Papier" nach dem Excel-Regelwerk unplausible Konfigurationen besser funktionieren als eben nach der Excel eingestellte Konfigs. Warum ist das so?


Nach Excel: (AIDA Photoworxx: 58300, Linpack mit Mühe und Not ca 412,3, Micobench 16K:2540,238 3145728K: 90,16 )

cachemem_39-8000-2200_ZenTimings.png
cachemem_39-8000-2200_CL34_Karhu.png

cachemem_39-8000-2200_PYPrime.png



Nach OCN: (AIDA Photoworxx 59500, Micobench 16K:2573,273 3145728K: 93,552)
cachemem_41-8000-2200_C34-OC2_Zen.png
cachemem_41-8000-2200_C34-OC2_Karhu-271.png

cachemem_41-8000-2200_C34-OC2_Linpack.png


cachemem_41-8000-2200_C34-OC2_PYPrime.png
 
Ja hast du da Formeln für? Wäre schön, die Tabelle zu erweitern.
 
Q5o6WajQSJ.png

"Es ist langsamer"
Ich frag mich wieso (y)

Warum ist das so?
Weswegen rennst du _L roundtrip timings welche für 48-64gb dimms sind ?
Langsamer = langsamer, aber irgendwo ist der Unterschied zu minimal wenn ich mir Microbenchmark und Karhu Testing Speed anschaue
Ich hätte einen weitaus größeren Unterschied erwartet.
Micobench 16K:2540,238 3145728K: 90,16
Micobench 16K:2573,273 3145728K: 93,552
hm1Hl4VFjX.png

"The percentage difference between 270410 and 271080 is 0.24562%."
HqCZ6IupYN.png

Avg 7659.571s vs 7639.286s // "The difference between 7659.6 and 7639.3 is 0.26518%"

Es ist nicht einmal 1% mehr, für etwas das "half duration" lang sein sollte.
1713593224143.png

Hier sind es 2% :d
Eine große Ziffer sieht nur Groß aus;
Hätte da aber wenn schon ~282-285MB/s erwartet (Sind 4-5%) , wobei Karhu nicht wirklich ein Indikator dafür ist.

Moin~

EDIT:
Zugriff auf nur 2 anstelle IC's pro Seite zu erlauben (FAW 16)
Ist halt auch nicht so das wahre :d
Wenn diese RRD_ auf 4 passen sollten, was physikalisch nicht funktionieren kann jedoch spielen wir mal mit der Theorie
Dann hat tFAW 32 weiterhin stabil zu bleiben. :-) , Versuchs RRD_ 4.

EDIT2:
Der weitere Grund nennt sich Stabilität 🙈
Etwas das potential hat repliziert zu werden.
12 & 24 _L sind recht gute Werte für das was auf dem Markt ist (3GB ICs).
Doch natürlich geht das auch tiefer für 16gb Dimms (2GB ICs)
 
Zuletzt bearbeitet:
Weswegen rennst du _L roundtrip timings welche für 48-64gb dimms sind ?
Langsamer = langsamer, aber irgendwo ist der Unterschied zu minimal wenn ich mir Microbenchmark und Karhu Testing Speed anschaue
Ich hätte einen weitaus größeren Unterschied erwartet.
Weil ich kann ;). Ich habe überhaupt nicht erwartet, dass die Timings (vom OCN, gleicher RAM aber 7950X3D statt mein 7800X3D) fehlerfrei laufen und dann -auch wenn minimal- besser performen als nach der Excel. Und warum das so ist, weiss ich immer noch nicht.
Karhu 285MB/s? Wahrscheinlich mit DDR6 aber nicht mit dem 7800X3D ohne flüssiges Gold ;)
 
Alright, ran some set of stress tests to verify new voltages with tWR = 66 failsafe (gave more consistent results in Pyprime running several iterations in a row) to have an updated baseline. Will now test tWRTS = 4

Speed of Karhu >50k % was at 283.42 MB/s
1713595888514.png

What happened here :d
So, I tighten up the timings, passed 25 TM5 cycles. Perhaps i can improve some timings. Screen below

by the way I use for all tests
TX DFE Taps = 1 taps
RX2D voltage step size (2^n) = 1
TX2D voltage step size (2^n) = 1
RX DFE Taps = 1 taps
Ouw another 128gb
How long does this train ?

Can you try to auto the step sizes
It seems counter productive to influence the way DFE taps are build and behave
Yet its common to use the Taps ~ just not mess with the idea the designers came up with please.

Changing their step size , changes their behavior, but does not do anything with time.
Karhu 285MB/s? Wahrscheinlich mit DDR6 aber nicht mit dem 7800X3D ohne flüssiges Gold ;)
Ich denke es ist nicht unmöglich.
Aber kann es nur auf 3 Arten anschauen:
~ Karhu Bandwidth ist nicht von inter-thread bandwidth abhängig und hängt von den Read und Writes ab (WTR großen Einfluss) und _L delays hätten großen Effizienz Einfluss
~ Karhu Bandwidth hängt nur von der Inter-Bandwidth ab, da es vom effektiven Cache & FCLK abhängt, somit wäre die Einordnung des Wertes irrelevant. UCLK+FCLK scale only ?
~ Karhu Bandwidth hängt eher von der Command Verarbeitung innerhalb des DIMMs ab & der Grund dass es kaum ein Unterschied gab = OD-ECC genau so viel korrigiert hat, wie der Zugewinn an niedrigen Timings war.

Aber alle drei Antworten machen eine Nutzerbase sauer:
~ Diese welche auf Karhu vertrauen,
~ diese welche mit Karhu benchmarken
~ oder diese welche wenig von dem Tool halten und wissen dass MemBW und memOC efficiency nicht einfach trackbar ist
Mit irgendjemanden findet sich ein Grund für eine Uneinigkeit.

Ich weiß es nicht. :-)
Wäre kein Developer von diesem Tool und meine Nutzungszeit darauf , um anzudeuten welche der drei Möglichkeiten nun die richtige ist ~ ist weitaus zu wenig.
Könnte man testen, aber ich hege wenig Wert auf diese Bandwidth Ziffer ~ da memOC Skallierung erstmal von dem X3D internen abhängt.
Writes gehen immerhin nur von der CPU aus ~ sobald ! sie sich mitten bzw zwischen den Reads injizieren können.
// Grund weswegen GDM oder hier FAW 16, solch tiefe WTR & WRWR SC_Long Werte überhaupt erlaubt.
// Die Zeit von unbenutztem RAM ist einfach höher :)
// Aber sobald man zurück auf FAW 32 geht und alle ICs (potentiell) parallel nutzt, bricht die Stabilität da UDIMM einfach nicht unter 8nCK Burst arbeitet.

Siehe die letzten 3-4 Posts im AM4 Thread. Das Thema hat kein Schwarz & Weiß;
Für ein 20% write & 40% read speedup, erwarte ich dann halt doch mehr als 0.2% Bandwidth increase.

Bitte teste mit SiSoftwareSandra, wenn die Tools nichts zufriedenstellendes anzeigen
~20% schneller :d
285MB/s + sehe ich als möglich. Besonders mit den aktuellen AGESA's, wenn ich mir die Nutzerergebnisse anschaue.
Jedoch wäre hier sehr wahrscheinlich nicht MemOC dein Fokus, wenn das Ziel Benchmarks sind.
Dieser bringt auch nur so viel, wie es an der CPU intern ausmacht bzw mitmacht.

140+ Ergebnisse, alle weit entfernt davon~~
Ich warte :geek:
PS:
XOC Ergebnisse werden von dem Team weggefiltert, da sie die Hardware als Irregular und nicht replizierbar darstellen.
Meines wurde zb ausgeschlossen da es ein "Unexpected Result: Outlier of 99.7% Results " ist, und somit nicht statistisch als "Machbar" angesehen wird.
Stabil & Legit war es, ansonsten wäre es nicht auf dieser Liste. Ebenso zeigt es ASUS in einem guten Licht, somit behält man es gerne oben , haha :d
 
Zuletzt bearbeitet:
Ich muss leider noch etwas anhängen @Bam_Bam
Photoworks kenne ich leider nicht

Aber microbenchmark sowie SiSoftware Sandra Inter-Thread
Je nachdem was du getestet hast, Zugriffszeit oder Bandwidth und auf welcher Datengröße
Hat wenig mit dem RAM zu tun, eher intern und eher FCLK zu MCLK bzw auf dem L$ sitzend.
Das ist nicht was das Tool ausmisst und nicht wofür es geschaffen wurde 🙈

Bzw CO als variable.
Eine positive Skalierung durch "correcting" memory timings, erklärt sich nur damit dass der Stress niedriger wurde ~ da die Benutzung & IMC Effizienz niedriger wurde.
Ich weiß es nicht :-) die Antwort liegt wohl irgendwo bei X + extra's
OD-ECC genau so viel korrigiert hat, wie der Zugewinn an niedrigen Timings war.
Klingt mir am plausibelsten, da
Doch ein recht großer Unterschied zu 8-12-32-7-24 bzw 4-24 , sind :-)
// teste es mal , mit stability screenshots bitte
Geschweige den 8-8-32-4-16 (good luck🤭)
 
Zuletzt bearbeitet:
@Veii Was hältst du davon?

ZhenyaUsenko

To calculate real Voltage you can use the next formula

Real_V = (Reported_V - 0.8) * 2 + 0.8

The minimum voltage for DDR5 is 0.8V and there are 127 steps with the increment of 0.005V to increase it.
It results in the max voltage

0.8V + 127 * 0.005V = 1.435V

High voltage mode is just a true/false flag and all it does is changes the increment from 0.005V to 0.01V
Resulting in the max voltage

0.8V + 127 * 0.01V = 2.07V

So, for example for 70 steps the voltage without HV mode would be

0.8V + 70 * 0.005V = 1.15V

For HV mode

0.8V + 70 * 0.01V = 1.5V

As ZenTimings is not aware if HV flag is set or not it always assumes the increment is 0.005V. Therefore you got that discrepancy between the reported and real voltage when you set HV mode to ON in the BIOS

Wenn das richtig ist müsste ich die tabelle anpassen.
 
Wenn das richtig ist müsste ich die tabelle anpassen.
Ahh er meint für das Sheet
Es ist nicht so einfach.

Die Logik ist , hmm müsste ich gegenprüfen
Nahezu ok

Aber die realität ist leider etwas anders.
Es gibt 3-4 Arten für den OC mode

Normal 5 & 10mV
5,10mV and then offset based

Different scale + offset based

Das letzte ist für den Renesas PMIC, das erste ist für die ersten Generationen des Richtek PMICs
Es ist nicht so einfach :d
// du siehst das gut wenn du dir meine GENE OC Ergebnisse anschaust für die Greens auf 1.65v (ZT 1.05 vs 1.2)
Wir haben Anpec and MPS auch noch :)

Ich würde nichts machen.
Von ZTs Seite, kann 1rusanov es auslesen und rausfinden.
Natürlich muss HWInfo aus , aber es ist möglich von 2 Seiten.
Er weiß das selber und muss sich nur die Arbeit machen es zu integrieren.

Aber diese "Information" ist sicherlich schon 8-10? Monate alt.
Ich weiß nicht wie die aktuelle Lage ist, da ich in dem Discord seit längerer Zeit nicht drinnen bin.

Oh Zhenya hat ein account hier ? nvm
ich kann nur sagen dass es nicht so einfach ist~

JESD301-2 & JESD300-5B
Von welchem er diese Daten rausnimmt, ist leider entfernt von den PMIC Vendors "method of behavior"
Manche wurden mit einem der vielen Arten für den OC mode designed.
Für viele andere ist es eher ein Exploit welches zu einer halb-unterstützenden feature wurde.
Beitrag automatisch zusammengeführt:

Ah,
Ich möchte nicht das Thema noch schwerer machen als es schon ist

Aber AMD arbeitet mit deren EC Requests etwas anders als man es auf Intel kennt bzw es JEDEC formuliert.
// einen der vielen Gründe weswegen es immer noch kein Renesas OC mode gibt ... außer dass ASUS deren eigenes Ding macht und nur das GENE dank "mutual" Bestätigung solch etwas erlaubt.

Und dann gibt es noch eine Variable, dass der OC mode zwischen SWA/SWB/SWC (und auch SWA+SWB Schaltung) minimal anders implementiert ist.
Ansonsten wäre zb OC mode nicht möglich für SWA aber keinen für SWB. // Die Funktion gehe, aber mit der genannten Art nun mal eben nicht.
Alle 4 (SWD) Werte sind LDO's sowie Loadbalanced, und ein "flag für den OC mode" wäre hier nicht möglich ~ da es beide SWA & SWB auf 1.435+ erzwingen würde.

Leider leider ist das nicht so einfach in der Realität,
Aber ich weiß woher er das ausließt und wieso er das so denkt :giggle:
Er hat nicht unrecht, aber womöglich ist das nicht die gesamte Antwort
Die Werte müsste ich jedoch gegenprüfen;
 
Zuletzt bearbeitet:
Ich spiele damit gerade im EXCEL, mal sehen : )

Er schreibt im OCN
 
@RedF
odUVe30L1G.png


Ich kann die Vendor-PMIC Sachen jedoch nicht posten.
Das ist nur JEDEC, nur wir haben 4-5 PMIC Vendors.
Es benimmt sich anders und JEDEC unterstützt keinen OC mode, weswegen er wahrscheinlich es als "guess" schreibt.

Die Range für die Binary Commands wird abgeändert,
Dass es nun 10mV sind, ist es Bonus.

Aber das wissen wir schon
+/- 15mV jumps im normal mode
+/- 15mV aber minimum delta 30mV im OC mode.

Haben wir schon implementiert~~
 
Also es bringt mich nicht zu seinen "VDD muss durch 0,015 teilbar sein."
 
Also es bringt mich nicht zu seinen "VDD muss durch 0,015 teilbar sein."
PMIC correction feature.

5mV steps, aber
-5mV, zero , +5mV
= 15mV variance

-10mV, zero, +10mV
= still 15mV fine granular, but in minimum delta 30mV :)

Die +/- 15mV vom Userinput, regelt der PMIC selber.
Zb ist die OC mode scale 1430+30+30+30
Aber da es der PMIC gegenregelt, rechne ich mit 1435+30+30+30 "als input".
// Ah und da 1435mV nicht immer ! der exakte OC Mode Punkt ist :d

Hex-Input vs actual-supply :d sind LDOs immerhin.
RAM rennt diese nicht auf konstanter Spannung
Auch nicht auf der CPU Seite mit VDDIO & (VDD[2]_IMC)
Sie bewegen sich rauf und runter um daten zu transferieren ~ differentialle Spannungen

Der gesendete Input hat zwar seine HEX-Scale, aber diese Scale ist per PMIC-Vendor anders;
Zumindest benehmen sich alle gleich bis 1425mV - danach wird es schwierig.
Auch einer der Gründe weswegen XMP presets bis 1.4v erstellt werden und dann erst ab 1.45v ~ und nichts 1.42v

... es ist kompliziert 🤭


Wenn man es dann wieder mit 1.4v cap +30+30 ausrechnet kommt man auf die 1430+30+30 (Richtek ausgelesen) scale
Aber das passt dann wiederum nicht mit "OC mode beginnt ab 1435mV"
Es ist sehr kompliziert :d unnötig eigentlich;
Naja, ich weiß nicht ob wir irgend etwas falsch machen.

Wenn man es "richtig" machen möchte,
Müsste man es per-PMIC Vendor und Version einstellen
Aber dafür gibt Renesas deren Daten nicht frei, und nur Richtek für einen der 3 PMIC Revisions.
Öffentlich meine ich~

Womöglich ist es schon ok so wie es ist :-)
AMD wird auch deren Art wie sie das übersetzen bzw EC requests raussenden, mit der Zeit abändern.
Es macht wenig Sinn sich auf dem Thema zu fokussieren~

Ich kann dir nur aus Erfahrung von dem HW PMIC-Swap Thema sagen
1713606740842.png

^ PARK 60-60 = Gigabyte 2DPC

Es ist ... d*mlich gelöst :d und der Renesas OC unlock auf AMD kommt wahrscheinlich nie, weil es eben so problematisch gelöst ist.
Bzw es weiterhin deswegen +2.1v voltage bugs geben wird, welche die Dimms charren. Naja :-)
Arme Board & Dimm Partner~~
 
Zuletzt bearbeitet:
Bitte teste mit SiSoftwareSandra, wenn die Tools nichts zufriedenstellendes anzeigen
~20% schneller :d
285MB/s + sehe ich als möglich. Besonders mit den aktuellen AGESA's, wenn ich mir die Nutzerergebnisse anschaue.
Jedoch wäre hier sehr wahrscheinlich nicht MemOC dein Fokus, wenn das Ziel Benchmarks sind.
Dieser bringt auch nur so viel, wie es an der CPU intern ausmacht bzw mitmacht.

140+ Ergebnisse, alle weit entfernt davon~~
Ich warte :geek:
Mit den OCN Timings zumindest TOP 5:

Beitrag automatisch zusammengeführt:

Mit der Excel CL34 Konfiguration ein bischen entfernter:



Und noch ein Interessantes Ergebnis meiner bisherigien 36-47 Excel Konfiguration:
 
Zuletzt bearbeitet:
ich muss mir das auch noch mal genauer anschauen mit den Spannungen. Verstehe abger zugegebnermaßen hauptsächlich nur Bahnof ;)
Was mich aber wundert sind die unterschiedlichen Readouts in HWInfo der einzelnen Dimms von VDD/VDDQ
 
ich muss mir das auch noch mal genauer anschauen mit den Spannungen. Verstehe abger zugegebnermaßen hauptsächlich nur Bahnof ;)
Was mich aber wundert sind die unterschiedlichen Readouts in HWInfo der einzelnen Dimms von VDD/VDDQ
Ich versuche die Spannungen mit Karhu (Alternativ eine modifizierte TM5 Konfig) und HWInfo so einzustellen, dass möglichst wenige Korrekturen (+- 15 mV) in HWInfo zu sehen sind und VDD / VDDQ 60 mV Abstand haben. Ist vermutlich mit das stabilste was man einstellen kann. Von der VDDIO mal abgesehen.
 
werde bei Gelegenheit mal einen Screenshot reinstellen. Im Moment läuft ja alles stabil mit VDD=1.52 und VDDQ=1.46
 
Aber microbenchmark sowie SiSoftware Sandra Inter-Thread
Je nachdem was du getestet hast, Zugriffszeit oder Bandwidth und auf welcher Datengröße
Hat wenig mit dem RAM zu tun, eher intern und eher FCLK zu MCLK bzw auf dem L$ sitzend.
Das ist nicht was das Tool ausmisst und nicht wofür es geschaffen wurde 🙈
CPU Memory Bandwith: Data Read-Modify-Write (Add) - AVX 512
 
Ouw another 128gb
How long does this train ?
2 minutes. With values 1-0-0-1 training time 3:30 minutes
Can you try to auto the step sizes
It seems counter productive to influence the way DFE taps are build and behave
Yet its common to use the Taps ~ just not mess with the idea the designers came up with please.
Yes, i can. Training time with auto ~9 minutes

What the motherboard offers by default does not suit me, I mean:
TX DFE Taps = 2 taps
RX2D voltage step size (2^n) = 2
TX2D voltage step size (2^n) = 2
RX DFE Taps = 2 taps
I never go through a POST with these values. I need to at least change RX DFE Taps to 1 to start training successfully, but not at all frequencies.
I didn’t notice any difference in terms of stability between 1 and auto i.e. what is unstable on values 1 will also be unstable on auto. I read your message that there should be a full training, but I just don’t see the point in it, and most likely I will regret it, but waiting 9 minutes every time kills.
Now I'm testing 6000 again and it seems my memory doesn't like tWTRL/tWRWRSCL below auto values i.e. 30/23. On values 28/21 I get 1 error 6 on the second pass of tm5, with 26/19 24/17 from 2 or more errors 6 in tm5. So I left the values that the motherboard suggested. So what I posted above is not stable. sd/dd timings 6-8-6-8 get error 13 in tm5. Now I’m testing with these timings, screenshot below
**Trfc 450 - error 6 tm5 1usmus, sd/dd 7/9 - error 9,14 tm5 extreme.
 

Anhänge

  • 6000_ZenTimings_Screenshot_testing.png
    6000_ZenTimings_Screenshot_testing.png
    17,6 KB · Aufrufe: 99
  • 6000_testing_tm5ex_5p.png
    6000_testing_tm5ex_5p.png
    144,1 KB · Aufrufe: 67
Zuletzt bearbeitet:
Was ist das Ziel
Sind fast alle Hynix Class V , A-Die momentan.
Solange man keine 8200 kits kauft, ist fast alles low tier A-die.

24gb sticks ehrlich gesagt. Und auch diese sind nahezu alle gleich.
Jedoch, was ist das Ziel ?

ASRock Board
Womöglich etwas Corsair, Teamgroup, Kingston, Klevv , V-Color ~ artiges
Sind alle auf dem selben PCB, mit Ausnahme RGB extra's.

Klevv Cras V vlt
die neuen Corsairs
Ah alles das selbe~

G.Skills laufen am besten auf ASUS Boards
ASRock rennt gut die Hsien Jinn PCBs ~ 8 oder 10 layer.
Mit anderen Worten die selben welche Klevv nutzt. Typisch matt schwarzen OEM.

Empfehlung,
Kein Geld für RAM ausgeben, solange die Samsung 4GB (32gb per side) nicht draußen sind.
Alles nahezu das selbe;
Die neuen Crucial Pro's sind spannend für high Clock, aber das war es auch schon
Beitrag automatisch zusammengeführt:

Du kannst dein Glück mit diesen aus Amazon versuchen, und wenn sie dir nicht gefallen wieder zurück
Müssten "failed 8000MT/s ICs sein, vlt vlt erwischt du ja die Class A's anstelle Class V's". Die Cras V sind definitiv fast alle Class V , A-Dies.
XMP runter auf 6000-6200MT/s (MHz) Primäre timings auf 32-39-39 und das passt. Alles andere hat auf Auto einfach zu rennen;
Wenn es gute ICs sind, könnten die womöglich auch die 6200 CL28 bei den standard 1.4v rennen ~ wer weiß.

Oder wir Spielen keine IC lottery und nehmen irgend ein 24gb kit, egal welches
Dann passt es auch
Wie zb
oder
6400MT/s Gear 1 wird schon mal "nicht" rennen, da es ungefähr 2/10 CPUs können, abeer das selbe wie oben ~ AMD EXPO/XMP laden, frequenz auf 6200 runter und es passt

Und solange du kein Micron oder Samsung kit erwischt (auslesbar), kann es nur eines sein :d

Jau,
nichts besonderes auf dem Markt momentan.
Beitrag automatisch zusammengeführt:

Wenn du Glück hast,
@cloudconnected
Dann rennt das ~ sehr altes Ergebniss
Anhang anzeigen 991587
auf 1.38v VDD_MEM & VDDQ_MEM ~ bis 1.42v realistisch für 6200MT/s C28.

Und wenn du nicht so viel Glück hast
Das ~ auf 1.3v :)
Die Mem RTT & Processor ODT kannst du ignorieren.

wie erkennt man eigentlich class a, wenn ich fragen darf?

Mit freundlichen Grüßen

peter
 
wie erkennt man eigentlich class a, wenn ich fragen darf?

Mit freundlichen Grüßen

peter
Class V
img_3020-jpeg.965200


Claas A
rn_image_picker_lib_temp_6181d5bb-6ef5-47e7-9daf-805187cc592b-1.jpg

Beitrag automatisch zusammengeführt:

Ich meine mit RAMMon kann man es auslesen und an einer stelle einen unterschied sehen.

Aber da musst @Veii fragen.

: )
 
Zuletzt bearbeitet:
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