[Sammelthread] Ryzen DDR5 RAM OC Thread

Gilt 65536 (minus 8092 steps) = resultat -1.
auch für trefi 65528
Ok also im Bios 65528 eintragen? und dann solange runter bis es stabil läuft?

Mal aus neugier EXPO geladen...dann kommt das Ergebnis. Habe noch einen zweiten Durchlauf gestartet, kam wieder etwas ganz anderes?

Kann es an PBO LVL 1 liegen? Oder Curve Opimizer ?

EDIT: Mal alles auf Standart im Bios gemacht und nun funktionierts.....Bin mal auf Fehlersuche, welche Einstellung das verursacht....
 

Anhänge

  • EXPO.png
    EXPO.png
    126 KB · Aufrufe: 73
  • 2.Durchlauf.png
    2.Durchlauf.png
    105,8 KB · Aufrufe: 77
  • Bios alles auf Standart.png
    Bios alles auf Standart.png
    134,2 KB · Aufrufe: 70
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Modular Redundancy Check Failed:

When you see this, it usually means one of three things:

  1. Memory instability.
  2. CPU instability.
  3. An undetected buffer-overrun. (bug in y-cruncher)
Memory instability is by far the most common cause of this.

Das habe ich gefunden

@Katakuri1991 die Frage galt Veii

Er empfahl bei Temperaturproblemen trefi in den genannten steps zu senken. So wie ich das verstehe gibt es unterschiedliche trefi max Empfehlungen die auf einem Rundungsfehler beruhen
 
Modular Redundancy Check Failed:

When you see this, it usually means one of three things:

  1. Memory instability.
  2. CPU instability.
  3. An undetected buffer-overrun. (bug in y-cruncher)
Memory instability is by far the most common cause of this.

Das habe ich gefunden
OK dann kann es sehr wohl am co und pbo liegen.

Alles auf Standard mit Expo läufts nun, es sieht so aus das es am CO liegt.... wahrscheinlich zu niedrig

Ich teste gerade alles aus
 
@Veii kannst du mir eine output.csv von dir schicken?
.txt entfernen :)
1701624069448.png
Jupyter NoteBlock file für das Bildlayout - aber irgendwas machte der Dev falsch.
Wäre etwas alt, das Tutorial.
6200C30-37-37 auf 1.32-1.34v , mit 1.35v ist es genug.
// EDIT: ~ ich denke 6200C30-36 müsste mit ungefähr 1.4 VDDQ, 1.42 VDD_MEM noch durchgehen. 6000 C30-36 wäre dann auf 1.3v.
512 RFC passt.
Du hast tWR vergessen.

Worauf ist VDDIO/MC ?
TM5 1usmus_v3 , 25 cycle stability reports bitte.

EDIT:
VDDP auf 1.1v max ~ (solltest du ODT und RTT übernehmen wollen)
1.15v brauchst du nicht mit GDM und brauchst du nicht auf 6200MT/s.
Schadet nur Signal Quality.
Ist es ein Fehler vom RAM? Was bedeutet das?
Habe ansonsten keine Problem mit dem PC.....also keine Abstürze oder sonstiges
Ja, instabil.
Autokorrektur ist sehr vorbildlich diese Generation.

Um den 4? Stunden TM5 bei 64Gb kommst du nicht herum.
Als absolutes minimum.
// Ich möchte ein Screenshot sehen. Stabil oder instabil.
Autocorrection würde sowohl die Bandbreite als auch die Latenz verfälschen~.

xiALbGZ8h3.png

Fortschritt, jedoch ~ dennoch.
@Veii Gilt 65536 (minus 8092 steps) = resultat -1.
auch für trefi 65528?
Hmmm
Ich denke ist schon mit einbegriffen, wie bei 65535 schon mit einbegriffen.
Ich denke auch dass es wegen den reserve'd tPPR bits ist - weswegen es stabiler rauskommt 🤔 unsicher, es fehlt die Logik.
Würde vorerst aber immer auf 65535 bleiben, bzw runterskalliert.

Sollte AMD endlich FineGranularityMode einschalten, dann würde ich die Formel leicht abändern.
Lade dir auf ASUS das ECO 170W profil - FakeECO
Fals die Boardpartner es auf Mid-Range Boards noch integriert haben.
Exclusive ASUS PBO feature.

CO möchtest du (blind) nicht unter -8 bzw -10 haben
VID Autokorrektur existierst auf der CPU.
Loadbalance Frequency Autokorrektur existiert auf der CPU
Cache PPR (PostPackageRepair) existiert auf der CPU & auf den RAM-Sticks
Clock Gating für FCLK und SystemClock existiert auf der CPU gegen Instabilität.

Jedes dieser Features wird dir bei dem Tracking von Spannung/Frequenz/Stabilität Probleme bereiten.
Jedes dieser Features kann schneller als 6ms ausgeführt werden.
Keines der Consumer-Tools kann unter 5ms sich updaten und Autokorrektur (visuel) feststellen.
@Katakuri1991

deine Northbridge Clock läuft auch nur mit halber Geschwindigkeit - das erhöht natürlich auch die Latenz ^^
Danke :d
Komplett übersehen.
Er/Sie rennt wohl UCLK=MCLK/2
Vorerst in Ordnung :) sowieso instabil
~
Ne , bin dämlich.
Alles ok , ZT zeigt UCLK = MCLK.
Liegt an der Autokorrektur bzw zu hohem FCLK.
Abseits das Northbridge sich in Integers synchronisiert (unwichtig)
Beitrag automatisch zusammengeführt:

Teste mal core cycler damit kannste dein co ganz gut testen in der readme des programms gibts auch sehr viel Empfehlungen
Leider schafft es das nicht corecycler zu bemerken.
Autocorrection is too good.

Ich hatte 1usmus eine systematische Methode durchgegeben,
Aber du kannst die Stabilität davon nicht erkennen.
Den wenn es wirklich crasht, ist es vieel zu spät. Wäre ~+50mV zu spät.
Man kann es mit RopBench bemerken, ab wann die Kerne in 1ms pooling beginnen sich instabil zu verhalten.

Jedoch Teilen alle Kerne pro Seite (L of L3$ , R of L3$) die Spannungen untereinander
Und bekommen sie alle gleichzeitig von einer Rail, geteilt als LDO.
Da sie die Spannung zwischen den Kernen seit Matisse? auch teilen können ~ wird gegenkorrigiert und ein Kern kann den anderen hinunterziehen.
// Die X core crashed reports wären somit zwecklos bzw ohne einen Verwendungsgrund. Im schlechtesten Fall, sogar irreführend.

Es gibt dann noch ein Per CCD 2 CCD Delta , abseits des Inter-CCD Deltas.
Für Freq (straps) & VID. :)
 

Anhänge

  • AMD Ryzen 5 5600X.csv.txt
    2,3 KB · Aufrufe: 54
  • 8core.ipynb.txt
    315 Bytes · Aufrufe: 129
  • TestMem5 v0.12 ADV_1usmus25.zip
    29,1 KB · Aufrufe: 56
Zuletzt bearbeitet:
Danke Veii. Ropbench habe ich auch schon getestet. Find ich sehr praktisch. Vor allem weil man die max clock und co ganz gut damit ausloten kann
 
Die Spiegelung hat mir einiges an Kopfzerbrechen bereitet.
Heatmap7800X3D.png


Heatmap5600X.png
 
Jetzt muss ich nur noch heraus finden wie man den Pfad für das abrufen der output.csv setzt, damit man das auch auf anderen Systemen nutzen kann.
Beitrag automatisch zusammengeführt:

Ein Test mit 32 Kernen währe noch schön.
Beitrag automatisch zusammengeführt:

Well done !
Eventuell die unter 8ns Kerne leicht grüner. Same-core 2 same-core roundtrip delay.
Kannst du mir ganz kurz ein Zentimings screenshot von deinem 7800X3D durchgeben ? :)
Das muss leider warten, bin jetzt am Handy.
 
Jetzt muss ich nur noch heraus finden wie man den Pfad für das abrufen der output.csv setzt, damit man das auch auf anderen Systemen nutzen kann.
Beitrag automatisch zusammengeführt:

Ein Test mit 32 Kernen währe noch schön.
Beitrag automatisch zusammengeführt:


Das muss leider warten, bin jetzt am Handy.
Ah ok :)
Dann schaue ich unterwegs drüber. (wäre erst gegen Mitternacht wieder zu Hause)

Ich hätte eine Idee was genau AMD versucht hinzubekommen . . . Sollte Ryzen Master wirklich MemoryPresets haben und nicht zb ASUS.
Aber es ist dennoch unlogisch dass RAS startet bevor RCD endet. Selbst wenn RAS aus welchem absurden Grund auch immer nicht auf dem DIMM stattfindet.
Wenn du etwas Freizeit hättest könntest du dann beide Optionen gegenvergleichen. (SiSoftware Sandra InterThread, benchmate usw)
Nun mit einem sauberen OS.
Ich hab leider kein DDR5 System mehr~
 
@RedF hab nen 7950x schreib mir gerne was ich machen soll.
Beitrag automatisch zusammengeführt:

Anbei core to core vom 7950x + Zen Timings
 

Anhänge

  • Zentimings.jpg
    Zentimings.jpg
    41,4 KB · Aufrufe: 102
  • output.zip
    602 Bytes · Aufrufe: 47
Zuletzt bearbeitet:
@Veii
Ich haben mich an deinen Rat gehalten und step für step die Timings weiter angepasst.
Leider bin ich aus Zeitgründen noch nicht so weit wie ich sein wollte, aber ich finde die Resultate sprechen schon für sich.

XMP6400_7_GDMOFF_MCROFF_PDWOFF.png
Zen_XMP6400_7_GDMOFF_MCROFF_PDWOFF.png



Zusätzlich 2h memtest86 ohne Fehler.

tCL = 28 hatte ich kurzzeitig aktiv, bekam dann nach einiger Zeit allerdings boot errors.

tRFC bekomme ich aktuell auch nicht wirklich unterhalb von 448, obwohl es A-Dies sein sollten

BIOS Setting:
VSOC = 1,3
MEM VDD = 1,45
MEM VDDQ = 1,35
MEM VPP = 1,8
GDM = Off
MCR = Off
Power Down Mode = Off

An die Widerstände ProcDqDA sowie DramDqDs habe ich mich noch nicht getraut, da ich deren Einfluss nicht kenne.

Jemand eine Idee, was ich anpassen sollte, um tCL = 28 zum laufen zu bekommen?
 
Zuletzt bearbeitet:
Ich gebe es auf für heute, die Tabelle ist irgendwie kaputtgegangen :cry:
 
@RedF

Der gute @ZeroStrat hatte sowas mit den C2C Latency auch schon mal programmiert (2021) ->

Zip Laden, CMD Öffnen, MicroBenchX.C2CLatency.exe rüber ziehen ins offene CMD Fenster.
1701634869603.png


Die Daten dann online auf der verlinkten Webseite einfügen (angefangen am X und am Ende das X auch mitnehmen) dann bekommt man am Ende die farbliche Auflistung in der Tabelle ausgegeben (auf generate grid klicken), wie hier im Bild zu sehen:

1701635062852.png


Hab meinen 78X3D mit RAM OC mal getestet, sieht dann im Ergebnis so aus:

1701634648240.png
 
Zuletzt bearbeitet:
Anleitung hat funktioniert. (y)
Ist hier Homogenität das Stichwort?

1.jpg

muss ich glaub ich nochmal ohne die ganzen Prozesse im Hintergrund machen.
 
Homogenität oder Heterogenität ist nur die Auflistung wie die Daten angezeigt werden sollen.

Bei Heterogenität werden die nicht Gleichen hervorgehoben, bei Homogenität die Gleichen.
Also damit man besser unterscheiden kann wo es "hakt" (nehme ich nun einfach mal an, mich kümmert es nicht :d )

Anzeige mit "Homogenität"
1701640084361.png


Anzeige mit "Heterogenität"
1701640121726.png


Also als Ganzes gesehen ist es recht "gut"
Die Betrachtung der Kerne einzeln ist dann eher "schlecht" wenn die Abweichung zu hoch ist im Vergleich zu den anderen Kernen.
Beitrag automatisch zusammengeführt:

Ergänzend zum Post oben:

Die intercore Latenzen sind auch abhängig von den sleep States, wenn erst ein Kern geweckt werden muss, braucht dieser länger zum reagieren als ein aktiver Kern (logisch irgendwie).
Soll heißen, wenn ein Powerplan z.B. ein Kern inaktiv setzt ist die Zeit entsprechend höher (cppc / cppc preferred cores * "ETC").

Mit * "ETC" meine ich in diesem Fall, dass die Kerne mit höheren Latenzen wohl vom System / Powermanagement schlafen gelegt werden und dann erst aufgeweckt, wenn Last anliegt.
 
Zuletzt bearbeitet:
@RedF

Der gute @ZeroStrat hatte sowas mit den C2C Latency auch schon mal programmiert (2021) ->
Schwierig.
nko5qcTIGM.png

Ungenau, und verbuggt.

Das Problem der Genauigkeit, liegt nicht in dem Programmierer bzw die Art zu tracken (hoffentlich)
Es liegt an der Idee des Programmierers.

Die sample Zeit ist kurz
Es rundet
Generell funktionieren user inputs nicht
Einfach alt und ein fork Projekt.

Ich würde hier ein converter bevorzugen bzw überlegen wie weit SiSandra von dem user-projekt liegt.
Den das originale Userprojekt benützt womöglich nicht die korrekten AMD ROP Command's (bitte um Korrektur sollte ich falsch liegen)
Jedoch rechnet es die deviations mit ein.
Dem CapFrame Tool , fehlt die Genauigkeit und habe programier bugs, worin es run-2-run andere Werte anzeigt. Bzw diese samples nicht zusammenzählen kann.
Ich weiß es nicht ansonsten würde ich es selber richten ~ jedoch leider nicht funktional bzw auf Auto nicht gut-genug.
WindowsTerminal_8Gqz6RvspO.png
Ergänzend zum Post oben:

Die intercore Latenzen sind auch abhängig von den sleep States, wenn erst ein Kern geweckt werden muss, braucht dieser länger zum reagieren als ein aktiver Kern (logisch irgendwie).
Soll heißen, wenn ein Powerplan z.B. ein Kern inaktiv setzt ist die Zeit entsprechend höher (cppc / cppc preferred cores * "ETC").

Mit * "ETC" meine ich in diesem Fall, dass die Kerne mit höheren Latenzen wohl vom System / Powermanagement schlafen gelegt werden und dann erst aufgeweckt, wenn Last anliegt.
Es tut mir leid,
Aber genau das ist nicht korrekt.
Aus 3 Gründen:

~ Powerplan und fixed clock / sleep states hinweiß von dem Dev liegt dem IPC tester bei. Welches ein langes/komplexes Thema wäre, aber wir dafür RopBench haben
~ Ein inter-core bzw interthread latency test läuft im besten Fall auf die Architektur's vorgelegte Instructions. Sollte es das nicht, hast du vor-konvertier steps von dem Branch Predictor, welches nicht nur die Latenz verfläschen, sondern auch die Geschwindigkeit bzw die Instruction als solches in kleine Teile zerstückeln ~ um sie effektiever zu Bearbeiten. OpCache & BranchPrediction Thema;
~ Kein core 2 core latency test sollte als "single Iteration" laufen. Die CPU in einem abseits normalen zustand zu versetzen (inkludiert safe-mode) wäre unüberlegt und stört das eigentliche Ziel weswegen du diesen Test rennst. Und bei 50000 core-blocks (samples) ist es semi Irrelevant ob nun 5 oder 10 davon aka 0.001% zu langsam sind da die Kerne aufwachen müssen.

Desweiteren braucht Zen seit dem CPPC existiert * (intern), kein OS zugriff und keine speziellen Powerpläne oder Treiber um zu funktionieren.
Niemand wartet auf das langsame OS um "load" zu verteilen. :)
* Es ist eher anders rum. CPPC ist eine funktion welches dem OS erlaubt die FIT ratings auszulesen und dem Scheduler erlaubt schneller fokussiert daten zu verteilen ~ anstelle dass man auf dem BranchPredictor (your turn) warten muss. Und dann unnötigerweise den Platz und die Zeit für solch rudamentale Arbeit wie load-scheduling verschwendet.
Das selbe gilt für Intel und AMD.
BufferQueue ist nur so groß, und was die BufferQueue füttert, hat ebenso einen Delay :)


Jedenfalls, wenn man korrekte Instructionsets absendet ~ bekommt man korrekte wiederholbare Ergebnisse
Ob wir auf @Kelutrel warten müssen (@RedF magst du für mich auf OCN Taubenpost spielen :d ~ er sollte mit dem MemTest bzw Interthread code schon lange fertig sein)
Werden wir noch sehen müssen.
Ansonnsten müsste man aus dem SiSoftware Sandra output etwas visuelles & vergleichbares basteln.
 
Zuletzt bearbeitet:
Hey, sag das nicht mir, sondern stell die Frage @ZeroStrat was er damals programmiert hat ;)

Ich persönlich gebe abslout garnichts auf die Ergebnisse, ich benche Games (eben das, wofür der 78X3D gemacht wurde) und vergleiche dann die Ergebnisse mit und ohne RAM OC ;)
 
Halbwegs ok ~ gut genug vorerst. So so , den es rundet auch.
Etwas ungenauer und man könnte X3D nicht gescheit tracken.
1701648456815.png

ich benche Games (eben das, wofür der 78X3D gemacht wurde) und vergleiche dann die Ergebnisse mit und ohne RAM OC ;)
Denke nicht dass AMD kein SiSoftware Sandra verwendet.
Jedoch sind leider Spiele kein Benchmark.

Das selbe Thema mit den synthetischen welche im genauen gegenteil kaum größer als 500-600mb sind.
Zuu optimiert, füllen kaum die BufferQueue.
Spiele hingegen sind nicht optimiert in den meisten fällen und in manchen wären die Datengrößen auf bestimmten Platformen optimiert.
Aka das selbe Ergebnis was wir letzten Post sehen. Instruction sets favoritisieren X Platform.

Für's hobby OCing womöglich gut genug.
Für neutrale Forschung mir leider zuu Fehlerhaft mit zu vielen Variablen.
RamOC & IPC tracking ist ein komplexes Thema. Um so mehr wenn es jeden Command korrigieren kann.
Beitrag automatisch zusammengeführt:

Haue ReBAR und HSA noch oben drauf welches Loadscheduling und Powergating betreiben
Oben drauf noch die Dynamik welche in den heutigen GPUs existiert. Ebenso dynamische hin und her Verteilung zwischen L$ & VRAM;

Alles vieel zu viele Variablen für mich.
Ich benchmarke somit nicht mit Spielen. Aus spaß womöglich, aber nicht um Daten zu sammeln.
Meine Art ist nicht besonders anders zu AMD's HQ. Wir? verwenden gerne mehrere analytische tools für analytische Arbeit.
Ob man dann versteht was man überhaupt testet, ist ein anderes Thema leider.
Man lernt nie aus :)
Beitrag automatisch zusammengeführt:

Spiele hingegen sind nicht optimiert in den meisten fällen und in manchen wären die Datengrößen auf bestimmten Platformen optimiert.
Keine Skalierung in X Titel
= passt noch im L3$

Große Skalierung in X Titeln
= sehr schlecht gecodetes Projekt oder Riesen groß.
L$ leakt zu mem und bevorzugt je nach SKU die MemLatenz anstelle die InterCCD Latenz.

Ein langes Thema.
Jedoch "keine skallierung" bedeutet fast nie "ein sinnloses Timing"
Jedes Timing welches niedriger gehe , bringt irgendwo bei irgend einem Szenario schon irgendwas
Ob es von Grundauf korrigiert wurde, merkst du allerdings nur wenn du positive Skallierung mit höheren Timings hast.
Nun ja, komplexes Thema ~ den kein Timing geht ebenso alleine.

Somit nütze ich Games nicht für analystische Zwecke.
Für Stabilitätszwecke, gerne ~ als Langzeit Projekt.
Einfach aufgrund der dynamischen last des Titels.
Um daten zu sammeln, wäre mir solch etwas deutlich zu inkonsistent.
Als nicht Dev, traue ich dem Tool nicht woraus/womit ich meine Daten dann sammeln sollte :)
 
Zuletzt bearbeitet:
Mir brauchst du das nicht zu erzählen, ich mache das seit zwanzig Jahren mit

Aber wenn wir ins Detail gehen wollen und jedes Quantum herausarbeiten wollen ist das hier eventuell das falsche Forum dafür. ;)


Wie dem auch sei, für absolutes Optimum fehlt es den meisten an Verständnis, deswegen halte ich es bei Erklärungen so einfach wie möglich.

Keiner versteht das "Fach-Chinesisch" und oftmals verschlimmert es noch.

What ever, ich halte den persönlichen Workflow am besten (für den einzelnen User) deswegen gehe ich nicht zu sehr ins Detail.

Was AMD (und deren devs) dann sagen ist eh was anderes als das was wir als AMD Nutzer einstellen können.

Um auf den Grund zu kommen warum ich das sage, es wird viel versucht, oft scheitert es aber alleindaran was für Treiber man installiert, AMD ist genauso wie Intel nicht unfehlbar.

Deswegen gibt es uns Tweaker ja, ob das nun zum Erfolg führt oder nicht, ist mit unter auch Sillicon lottery.
 
Zuletzt bearbeitet:
Fixed critical thinking mistake - REFi.
Now flawless. WIP FGR for both platforms

Added Changelogs. ~ visible ?
Will be filled out for missing timestamps.

Consideration to publish it globally ? @RedF
Consideration to multi-make it for global DDR5 ? *
* dann würde ich mir überlegen die Timings genauer zu kallulieren und Specifications einzufügen. // nCK + rounding calculations
Oft bekommen es Boardpartner ebenso falsch. Meistens absichtlich "da es ja läuft"
Sprich Intel und AMD.

Wenn es zu viel Arbeit für dich ist, lass mich bitte wissen.
Momentan etwas "faul", und ändere nur Kleinigkeiten welche mich stören.
Kaum Fokus auf dem Sheet. Wäre aber schade daraus nicht etwas großes zu machen.
Als sheet maker wirst du Wöchentlich Beschwerden und kommentar-emails bekommen. 🤭
Bzw erneuerte Edit-Anfragen durch random E-Mails.

Wenn es OK für dich ist, dann könnte man sich die Zeit nehmen und es "korrekter" hinbekommen.
Mir zwar alles als offline Helper-App deutlich lieber, aber so geht es auch~
Besonders da die meisten Calculator Projekte unseriös sind. Tauchen auf und werden vergessen 🤭🤭
 
Zuletzt bearbeitet:
Fixed critical thinking mistake - REFi.
Now flawless. WIP FGR for both platforms

Added Changelogs. ~ visible ?
Will be filled out for missing timestamps.

Consideration to publish it globally ? @RedF
Consideration to multi-make it for global DDR5 ? *
* dann würde ich mir überlegen die Timings genauer zu kallulieren und Specifications einzufügen. // nCK + rounding calculations
Oft bekommen es Boardpartner ebenso falsch. Meistens absichtlich "da es ja läuft"
Sprich Intel und AMD.

Wenn es zu viel Arbeit für dich ist, lass mich bitte wissen.
Momentan etwas "faul", und ändere nur Kleinigkeiten welche mich stören.
Kaum Fokus auf dem Sheet. Wäre aber schade daraus nicht etwas großes zu machen.
Als sheet maker wirst du Wöchentlich Beschwerden und kommentar-emails bekommen. 🤭
Bzw erneuerte Edit-Anfragen durch random E-Mails.

Wenn es OK für dich ist, dann könnte man sich die Zeit nehmen und es "korrekter" hinbekommen.
Mir zwar alles als offline Helper-App deutlich lieber, aber so geht es auch~
Besonders da die meisten Calculator Projekte unseriös sind. Tauchen auf und werden vergessen 🤭🤭
Mus ich drüber nachdenken : )
Beitrag automatisch zusammengeführt:

Ob wir auf @Kelutrel warten müssen (@RedF magst du für mich auf OCN Taubenpost spielen :d ~ er sollte mit dem MemTest bzw Interthread code schon lange fertig sein)
🕊️(y)
 
Zuletzt bearbeitet:
Ohne andere Timings nochmal anzupassen bin ich wieder auf tCL = 28, allerdings bin ich mit den Resultaten mehr als unzufrieden.

Hier zum Vergleich tCL = 30
XMP6400_7_GDMOFF_MCROFF_PDWOFF.png
Zen_XMP6400_7_GDMOFF_MCROFF_PDWOFF.png


XMP6400_8_CL28_GDMOFF_MCROFF_PDWOFF.png
cl28.png


Seit der Umstellung auf CL28 hat Zen Probleme meine Spannungen auszulesen.
Könnte es daher ein Spannungsproblem sein, welches auch greift, wenn ich tRFC auf 130 ns reduzieren will?

Update: tCL 28 bootet wieder nicht mehr.
 
Zuletzt bearbeitet:
Zusätzlich 2h memtest86 ohne Fehler.
TestMem5 möchtest du rennen. Memtest bringt nur was über 6+ stunden.

Ich sehe leider auch kein Screenshot von dem stability test & ram als einzellvariable genügt nicht
Besonders nicht wenn man auch FCLK so hoch rennt~

Benchmarks ohne stresstests,~
Ich weiß nicht :)

RAS +1 :)
RC zu tief
1701700453166.png
Beitrag automatisch zusammengeführt:

Wäre stillgelegt, jedoch wollte das Moderationsteam unschuldige nicht bannen.
Schade, aber es ist ok :)

Müsste dich daher um den 🕊️ Gefallen bitten :)
Ob er ein Update für uns rausbringen kann.
 
Zuletzt bearbeitet:
Habs jetzt nochmal mit dem 16/32 Kerner gebaut, sollte eigentlich funktionieren.
Heatmap7950.png

Beitrag automatisch zusammengeführt:

Meiner auf einem Sauberen Win.
Heatmap7800X3DClean.png
 
Meiner auf einem Sauberen Win.
Heatmap7800X3DClean.png
Hübsch :)
Denkst du du kannst die range für die 31er ins rötliche erhöhen ?
Minimal blutorange.

Damit der Unterschied zwischen 26 & 21 größer wird
Wobei 20ns recht gut sind für die CPU.
Auf Intel wären wir nahe 30ns.
Minimal anders, Ryzen wäre auf einem MultiRing design.
Intel auf einem simpleren.

Sobald du fertig bist, kann man es im Intel Thread mit den E-cores gegentesten.
 
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