[Sammelthread] Ryzen DDR5 RAM OC Thread
- Ersteller Reous
- Erstellt am
@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.
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?
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.
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:
@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.
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:
Hab meinen 78X3D mit RAM OC mal getestet, sieht dann im Ergebnis so aus:
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.
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:
Hab meinen 78X3D mit RAM OC mal getestet, sieht dann im Ergebnis so aus:
Zuletzt bearbeitet:
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
)
Anzeige mit "Homogenität"
Anzeige mit "Heterogenität"
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.
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.
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
)Anzeige mit "Homogenität"
Anzeige mit "Heterogenität"
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:
Schwierig.
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.
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
~ 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
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.
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.
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
= 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
Etwas ungenauer und man könnte X3D nicht gescheit tracken.
Denke nicht dass AMD kein SiSoftware Sandra verwendet.ich benche Games (eben das, wofür der 78X3D gemacht wurde) und vergleiche dann die Ergebnisse mit und ohne RAM OC
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:
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.
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:
DDR5 Timing Calculator for AMD
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:
Mus ich drüber nachdenken : )Fixed critical thinking mistake - REFi.DDR5 Timing Calculator for AMD
docs.google.com
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 🤭🤭
Beitrag automatisch zusammengeführt:
🕊️Ob wir auf @Kelutrel warten müssen (@RedF magst du für mich auf OCN Taubenpost spielen
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
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.
Hier zum Vergleich tCL = 30
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:
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
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:
HübschMeiner auf einem Sauberen Win.
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.
Hübsch
Denkst du du kannst die range für die 31er ins rötliche erhöhen ?
Minimal blutorange.
Ja ist aber ein ziemliches Gefummel das richtig hinzubekommen ( oder ich weiß noch nicht wie ).Etwas zu viel
Danke dir
Findest du es selber zuu viel ?
Nein nein, lasse es so wie es dir gefällt
Sieht definitiv gut aus
Ich frage mich ob man es Layout technisch irgendwie anders hinbekommt
Aber würde man es
0 / 1 // 8 / 9
2 / 3 // 10 / 11
4 / 5 // 12 / 13
6 / 7 // 14 / 15
Formatieren
Dann würde das test layout wiederum nicht passen
Per Hand kann man es zuweisen, wie man es gerne hätte.Nein nein, lasse es so wie es dir gefällt
Sieht definitiv gut aus
Ich frage mich ob man es Layout technisch irgendwie anders hinbekommt
Aber würde man es
0 / 1 // 8 / 9
2 / 3 // 10 / 11
4 / 5 // 12 / 13
6 / 7 // 14 / 15
Formatieren
Dann würde das test layout wiederum nicht passen
Ist halt viel Arbeit, müsste es aber nur einmal machen ( kommt aber darauf an ).
Ja ne
Ne idee wie man es besser gestallten kann ohne dass es gespiegelt wird ?
Ich frage mich ob man alle Transition-States , bzw Ring-States visuel hinbekommt
Fraglich wäre, weswegen es solch eine starke delta zwischen Cores und Threads gibt, Innerhalb des selben Kern's
Ob man damit wohl die CO korrektur ausmessen könnte 🤔
SiSandra wäre der eigentlich korrekte Weg
Aber es würde dir layout probleme bereiten 🤔
Zuletzt bearbeitet:
How ??
Du kannst versuchen bei dem output (nach dem refresh run) einfach nur den text zu kopieren
Das ist mal ein Test, um sie für jeden Online nutzbar zu machen.
docs.google.com
Es sind nur die gelben Zellen freigegeben.
Oder spricht etwas dagegen?
DDR5 Timing Calculator for AMD V0009
Oder spricht etwas dagegen?
Katakuri1991
Experte
- Mitglied seit
- 30.01.2021
- Beiträge
- 398
Hey Veii,
bin mit deinem vorgeschlagenen settings zufrieden.
Komme wenn ich paar Programme schließe auf 62,5-62,8ns je nachdem. Danke vielmals
Die Kiste läuft auch nun stabil nachdem ich den curve optimizer abgesenkt habe.
Aktuell bin ich am ausprobieren auf wie viel ich die VSOC reduzieren kann. Ich teste gerade 1.2V Soc.
Senkt schön die cpu Temperatur vom 7800x3d.
Das falsche TM5Ergebnis von TestMem5:
Und nicht mit admin-rechte gerannt.
Nur 25gb getestet.
Ich vertraue nur Bilder. Screenshots mit einer Bestätigung.
TM5 1usmus_v3 ist nicht das einzige was du rennen musst um es "stabil" zu nennen.
Nur das absolute minimum.
Ähnliche Themen
