Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
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
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!
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 ; )
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.
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
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
Jau,
nichts besonderes auf dem Markt momentan.
Beitrag automatisch zusammengeführt:
Wenn du Glück hast, @cloudconnected
Dann rennt das ~ sehr altes Ergebniss
auf 1.38v VDD_MEM & VDDQ_MEM ~ bis 1.42v realistisch für 6200MT/s C28.
Discover the magic of the internet at Imgur, a community powered entertainment destination. Lift your spirits with funny jokes, trending memes, entertaining gifs, inspiring stories, viral videos, and so much more from users.
imgur.com
Das ~ auf 1.3v
Die Mem RTT & Processor ODT kannst du ignorieren.
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?
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)
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.
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.
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
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 )
Nach OCN: (AIDA Photoworxx 59500, Micobench 16K:2573,273 3145728K: 93,552)
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.
"The percentage difference between 270410 and 271080 is 0.24562%."
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.
Hier sind es 2%
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
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)
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
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.
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
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
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
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
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🤭)
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.
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
// 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
Er hat nicht unrecht, aber womöglich ist das nicht die gesamte Antwort
Die Werte müsste ich jedoch gegenprüfen;
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.
-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
Hex-Input vs actual-supply 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 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
^ PARK 60-60 = Gigabyte 2DPC
Es ist ... d*mlich gelöst 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~~
~20% schneller
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
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.
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 🙈
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.
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.
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
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
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.
Discover the magic of the internet at Imgur, a community powered entertainment destination. Lift your spirits with funny jokes, trending memes, entertaining gifs, inspiring stories, viral videos, and so much more from users.
imgur.com
Das ~ auf 1.3v
Die Mem RTT & Processor ODT kannst du ignorieren.