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.
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)
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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.
Easy aufschrauben und wieder dran wäre schön, ist aber etwas aufwändiger.
Man muss die Riegel in Isoprop einlegen um die Verklebung aufzuweichen.
Damit ist die Garantie flöten.
Leider wurde RAMMon upgedated und es wurde somit unerkenntlich gemacht.
Dann ebenso leider, werden aktuelle 3xx batches auf JEDEC 4800 gebinnt, somit ist das aktuelle SPD-Hub update anders
~ ah einfach "der standard" wurde abgeändert und man einigt sich ein low tier batch zu kaufen und diese local zu binnen.
Manche, geben noch silk drüber um es umso eher unerkenntlich zu machen , andere kaufen diese ohne Beschriftung.
Man könnte eventuell es low voltage low frequency testen ~ da meistens RP & RC schwächer sind
Aber , nun ja. Es ist schwer. Besonders da RTT eine große Variable spielt;
Sie physikalisch auszulesen , wäre am einfachsten.
EDIT:
Eine konkrete (community) Methode den SPD dump auszulesen,
Gibt es soweit nicht.
Es ist weniger Arbeit sie einfach zu öffnen.
Leider wurde RAMMon upgedated und es wurde somit unerkenntlich gemacht.
Dann ebenso leider, werden aktuelle 3xx batches auf JEDEC 4800 gebinnt, somit ist das aktuelle SPD-Hub update anders
~ ah einfach "der standard" wurde abgeändert und man einigt sich ein low tier batch zu kaufen und diese local zu binnen.
Manche, geben noch silk drüber um es umso eher unerkenntlich zu machen , andere kaufen diese ohne Beschriftung.
Man könnte eventuell es low voltage low frequency testen ~ da meistens RP & RC schwächer sind
Aber , nun ja. Es ist schwer. Besonders da RTT eine große Variable spielt;
Sie physikalisch auszulesen , wäre am einfachsten.
EDIT:
Eine konkrete (community) Methode den SPD dump auszulesen,
Gibt es soweit nicht.
Es ist weniger Arbeit sie einfach zu öffnen.
Alles super !
Ja die chance wäre die höchste hier Class A zu erwischen, da der andere ab 8000MT/s geht und 7200 alle "failed bin's" wären.
Generell kann jeder A-die die 8000MT/s, aber ab 7800MT/s beginnen die Class V's zu failen . Bzw sie brauchen mehr Spannung
Dafür sind diese weitaus billiger herzustellen, was beidseitig einen Nutzen darstellt.
Dass diese gen.2 ICs natürlich nicht auf JEDEC 5600 gebinnt werden wie es sich ja eigentlich gehört, und man aus heiterem Himmel entscheidet die Specs zu ändern
Ich weiß nicht~~
Ich mags nicht, aber wenn die Konkurrenz einfach fehlt ~ naja. Business halt;
Klevv (SK Hynix Western) ansich verbaut gute thermal pads.
Es ist sehr warscheinlich ebenso auf einem HJ 10? Layer black-pcb.
Dass bei 8000MT/s kits Class-V verbaut sind würde ich komplett ausschließen und vlt nicht den Heatsink angreifen.
Der 7200er downbin , schwierig.
Eigentlich hätten sie die CrasV als "gute TypeV" und Bolt V als "schlechte TypeV" ~ SKU, um den übrig gebliebenen Yield loszuwerden.
Alles super !
Ja die chance wäre die höchste hier Class A zu erwischen, da der andere ab 8000MT/s geht und 7200 alle "failed bin's" wären.
Generell kann jeder A-die die 8000MT/s, aber ab 7800MT/s beginnen die Class V's zu failen . Bzw sie brauchen mehr Spannung
Dafür sind diese weitaus billiger herzustellen, was beidseitig einen Nutzen darstellt.
Dass diese gen.2 ICs natürlich nicht auf JEDEC 5600 gebinnt werden wie es sich ja eigentlich gehört, und man aus heiterem Himmel entscheidet die Specs zu ändern
Ich weiß nicht~~
Ich mags nicht, aber wenn die Konkurrenz einfach fehlt ~ naja. Business halt;
Klevv (SK Hynix Western) ansich verbaut gute thermal pads.
Es ist sehr warscheinlich ebenso auf einem HJ 10? Layer black-pcb.
Dass bei 8000MT/s kits Class-V verbaut sind würde ich komplett ausschließen und vlt nicht den Heatsink angreifen.
Der 7200er downbin , schwierig.
Eigentlich hätten sie die CrasV als "gute TypeV" und Bolt V als "schlechte TypeV" ~ SKU, um den übrig gebliebenen Yield loszuwerden.
Ich kann über beide Firmen nichts konkretes sagen, besonders wenn mir die Anzahl an Samples fehlt;
Aber beide DIMM-Vendors haben low tier und high tier SKUs.
Teamgroup war ehemalig über deren Flashy T-Force DELTA's bekannt, welche bei 7200T/s recht gut abschnitten und recht berühmt waren.
Preis/Leistung Verhältnis stimmte, da es nur Class-A A-Dies gab und diese begonnen hatten OCing-PMICs zu verwenden.
Und die entry lineup für 1/3 des Preises mit unterschiedlichen PMICs.
"Muss nicht gut sein, muss funktionieren." Quasi~
Wenige mochten das Design, die Kühlleistung,
aber kaamen mit diesen als OCIng kits zurecht
Dann erst vor wenigen Wochen kamen die XTREEMs kits auf dem Markt,
Welche auf beiden Punkten sich stark fokussierten.
Overclocking, und ein guten Heatsink. Zum hohen Preis, jedoch mit hoch-gesetzten Qualitätsanspruch.
Patriot startete den Markt mit einem Produkt
Den AMD focused Viper VENOMs auf streng gebinnten 1.25v XMP,
Worin andere Dimm-Partner 1.35-1.4v brauchten, auf den selben Timigns // Hynix-M
Später erst kaam die entry lineup:
Patriot Signature
Patriot TW ist eher eine Wildcard auf dem Markt.
Sie sind sehr gut im PCB design,
jedoch laufen deren Kits (soweit) nahezu niemals auf Nutzersystemen, ohne einen eigenen Handgriff in den RTTs oder ODTs.
// EDIT: Not even my good SI friend who is in the OC scene since +12? years, could deal with them by default. Its funny, but now they run great~~
Das war auch nicht besonders anders bei DDR4.
Deren custom PCBs sind zwar gut, und sie setzen hohe Maßstäbe für die XMPs
Aber diese sind meistens nicht Plug'n'Play. Besonders dann nicht, wenn an sich auf G.Skills PCBs konzentriert.
Momentan haben sie die Elite-5 Series welches sich weiterhin dem "Flashy Gamer" style orientiert
// Hoffentlich nun auf Hynix-A fokussiert, aber sehr warscheinlich low-tier ICs auf gutem PCB??, unsicher;
Und deren Art der Viper Xtreem's
Welche, leider wie man es auch erwarten konnte ~ sehr problematisch für die IntelOCer war
Und diese dann billig verkauft werden mussten, bzw damit wieder etwas schlechte Repo bekaamen.
Ich persöhnlich, mag Patriot's ViperTW Team.
Sie sind recht talentierte Engineers, welche auch gerne mal was neues versuchen
Und trotzig auf ihr eigenes Design treu bleiben.
Dass dieses nun mal, nicht Plug and Play bleibt,
Es ist schade ~ aber wenn sie laufen, laufen sie sehr gut
Letztendlich ist und bleibt es eine IC lottery.
Je neuer der Batch ist, desto besser und sollte es kein ClassV sein
(welcher sich leider überall unter 7800MT/s befinden kann und es auch ist)
Ist es nicht soo wichtig wer der DIMM-Hersteller nun mal ist.
// besonders da bei "normal tier" oft ICs & PMIICs hin und her getauscht werden, um den Verkaufspreis einhalten zu können
Wichtig ist, ob das Board dafür von Grund auf klarkommt (wir hier haben es einfach dank AMD)
Oder du selber Hand anlegen musst, damit das Powering stimmt.
Somit gibt es dafür keinen DIMM-Vendor Favoriten.
Sprich wenn du es direkt aus der Fab willst, importierst du sie dir bestenfalle aus dem Hause
Oder versuchst dein Glück bei deren Globalen PartnerIPs:
SK Hynix Korea = Klevv
Samsung Korea = Samsung (noch WIP)
Micron USA = Crucial
usw~
Da DDR5 weitaus schwerer zu designen ist, JSDN Committee jedoch sehr genau angibt wie ein PCB designed werden muss
Sind die meisten "normalen" Kits identisch und vorhersehbar.
Nur die High-End lineup >8000MT/s , beginnt dann deren eigenes Ding mit den PCBs zu machen.
Als Beispiel teilen sich
GALAX, OloY, TeamGroup ~ ein bestimmtes design
// jedoch nur die high-end SKU
G.Skill hat deren eigenes
Patriot macht deren eigenes Ding
Corsair springt hin und her, aber setzte sich nun auch auf dem typischen global Hsien Jinn Black (8/10 Layer)
Kingston ist auf dem HJ
V-Color ebenso
Aber so konkret kann man es nicht immer sagen,
Da es SKU abhängig ist, was den nun verbaut wird und ob es preislich überhaupt Sinn macht.
Hat eher nichts mit tFAW im Zusammenhang mit RRD's (_L doch, siehe unten) zu tun. MMn kann man da einen Schmarrn eintragen und die Autokorrektur greift ein. Ob tFAW 16/4/4 oder 32/8/8 macht keinen Unterschied. -> Die OCN Konfiguration läuft mit 32/8/8 gleich gut.
Ich denke das trifft häufiger zu als vielleicht vermutet.
CCD_L (=>tRRDL oder tRRDS) ist die Ursache und damit tWRWRSC_L in der Folge WTR_L. Setze das in der Excel die 8 und die Copy-Bandbreite steigt. Interessant ist, dass WTR_L dann ein Delay Braucht (2*9+2=18).
Warum WTRS niedriger als 4 läuft, bringt minimale Verbesserung, kann aber auch Autokorrektur sein?
RCD=RP könnte bleiben aber RP<RCD bringt in der Kombination auch eine kleine Verbesserung. Da weiss ich aber nicht warum.
Bei RAS und RC bin ich überfragt. Habe ich aber auch noch nicht weiter getestet.
Und klar, große Sprünge kann man in dem Bereich nicht mehr erwarten. Karhu 272 und auch 275 MB/s habe ich schon gesehen 282 - 285 mit vorhandenem RAM halte ich für nicht möglich. Bei einem Platin 7800X3D mit >IF2233 und sehr viel Magie mag mehr als 275 MB/s möglich sein, hat aber mit dem RAM eher sehr viel weniger zu tun.
Nebenbei: RAM Temperatur unter Höchstlast bitte unter 45°, Ideal nicht über 43 ist Pflicht sollte aber eh klar sein. Beim Gamen etc läuft der RAM mit Luftkühlung bei lockeren 37°.
------
Im Grundegenommen,
Wenn ich jemanden "vertrauen würde" dass sie deren Arbeit machen und gescheit binnen
Dann wäre es der IC-Vendor höchstpersönlich & nicht die 3rd-party Partner.
Die Klevv Blacks benehmen sich minimal anders * als die OEM Green's welche eigentlich unter einem China Export BAN stehen
Aber dass hat dann wieder mit globaler Politik zu tun und ist für uns Endkunden einfach nur ein lästiges Thema.
// * nur da sie den specifications folgen, und der Restliche Markt ebenso zu HJ Black PCBs überwechselt.
Somit wenn der IC-Vendor höchstpersönlich sagt "8000MT/s Kits existieren nun" innerhalb der specifications
Dann erwarte ich gutes @pocketorc
Obwohl mir der Preis doch ein wenig hoch erscheint für das Heatsink design
Hat eher nichts mit tFAW im Zusammenhang mit RRD's (_L doch, siehe unten) zu tun. MMn kann man da einen Schmarrn eintragen und die Autokorrektur greift ein. Ob tFAW 16/4/4 oder 32/8/8 macht keinen Unterschied. -> Die OCN Konfiguration läuft mit 32/8/8 gleich gut.
tFAW 32 ~ 1024bytes IC Pagesize (8x1R layout)
tFAW 40 ~ 2048bytes IC Pagesize (4x1R/2x*4x1R layout)
Ein "density" Thema und ein Layout Thema.
Kommt sehr auf REFsb an.
DDR5 hat es von RRD_ getrennt.
Auch weil es doppelt so viele Banks sind vs DDR4
Die RRD Regelt gilt nicht mehr. Es kommt nur noch auf die Package-Transfersize an & wie breit eine ROW ist innerhalb des IC Chips.
Den Rest übernimmt der SPD Hub selber.
ran into a problem cold boot, passed tm5, after reboot get errors 6, 0. this does not always happen, it is difficult to detect
maybe it’s due to an incorrectly selected vddq, I don’t like that at the load shows 1.215v
vddq
1.22 (hwinfo 1.215-1.245)
1.23 (hwinfo 1.215-1.245)
1.24 (hwinfo 1.23-1.245)
1.25 (hwinfo 1.245)
need more tests
Vdd
1.4v (hwinfo 1.38)
1.41v (hwinfo 1.395)
If i select
Vdd 1.41 (hwinfo 1.395), vddq 1.34 (hwinfo 1.335v), delta 60mv, i get many errors 0,6 and sometimes bsod system service exception
. 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.
