[Sammelthread] Ryzen DDR5 RAM OC Thread
- Ersteller Reous
- Erstellt am
Versuche es mit
WR 48
PARK (40ohm)
DQS 48
ProcODT 43?, 40Ohm
RAS+RC (+2)
VDDP 1.12v
Bitte um Rückmeldung
Eventuell noch beide DQ's auf 40ohm
Beitrag automatisch zusammengeführt:
Ah WR failsafe
CWL + WTRL + BC8
60
Zuletzt bearbeitet:
Versuche es mit
WR 48
PARK (40ohm)
DQS 48
ProcODT 43?, 40Ohm
RAS+RC (+2)
VDDP 1.12v
Bitte um Rückmeldung
Eventuell noch beide DQ's auf 40ohm
Beitrag automatisch zusammengeführt:
Ah WR failsafe
CWL + WTRL + BC8
60
Beitrag automatisch zusammengeführt:
Ich versuche jetzt
RAS+RC (+2)
CWL + WTRL + BC8 = 60
Ohne die Wiederstände.
Zuletzt bearbeitet:
Mm, errors wären zuu starke PARK bzw DIMM crash
Wäre dann PARK 48, DQS 60 als Versuch.
#1 ist schwer zu lösen
Es sagt Heat SNR issue, bzw timing missconfiguration
"Small timeout"
Zuletzt bearbeitet:
hab da jetzt auch mal ein bisschen mit rumgespielt. Hatte meinen CO vorher ausgelotet mit CC etc. und würde gerne herausfinden ob ich im Clockstretching bin. Allerdings werde ich da nicht so wirklich schlau draus.
Ein Run mit meinen CO Werten und ein Run ohne CO.
Kann ich da nun was draus ableiten?
Anhänge
Bam_Bam
Experte
- Mitglied seit
- 09.01.2024
- Beiträge
- 509
Falls es mit CB nicht geht, versuche es mit CPUZ (Stress CPU). Hier kannst du auch auf 2 Threads reduzieren. Um jeden Kern einzeln zu testen muss das Programm gestartet sein. Danach im Taskmanager den CPU-Kern zuweisen. 0 und 1 = Core 1
2 und 3 = Core 2 usw. Dann sollten die Unterschiede sichtbar werden. Sollte aber eigentlich auch mit CB funktionieren.
EDIT:
Dann ist da auch kein nennenswertes Stretching vorhanden. Denke bis 50 MHz ist alles im Rahmen.
2 und 3 = Core 2 usw. Dann sollten die Unterschiede sichtbar werden. Sollte aber eigentlich auch mit CB funktionieren.
EDIT:
Dann ist da auch kein nennenswertes Stretching vorhanden. Denke bis 50 MHz ist alles im Rahmen.
Zuletzt bearbeitet:
@RedF Moiin,
Bitte beginne ~attached~ zu nutzen.
Ebenso weise ihm/es Admin-Rechte zu.
Ist das ein fortlaufender Test von ODT/RTT tuning.
Oder fokusieren wir uns auf etwas anderem.
Jedoch wird weiterhin das Boosting System bzw die Algo angepasst.
Dass wir kein throttle mehr im 0 CO Zustand sehen, ist sehr schön.
Endlich.
Das heißt, dass das FIT VID-Spannungslimit , aka das Throttle Limit bei hohen VID requests
Nahezu gelöst is. Bzw "it is weighted on CAC" ~ der Fokus darauf ist auf der Lastart [CAC] (erkannt durch Last & instruction sets)
Traurig oder nicht,
Es ist sehr schön zu sehen.
Natürlich könnte der Ropbench Dev die Instruction-set Art abändern
Damit es nahezu ähnliche AVX2/FMA lasten wiederspiegelt
Doch dann fällt das nicht mehr als "versprochener Game-Boost" clock.
Der Boostclock bei nicht-SSE Lasten, wurde nämlich niemals garantiert.
Was garantiert wurde ist der "Base Clock" . Welcher bei jeglicher Art von Last eigenhalten werden muss.
Generell wurde der Boostclock niemals konkret garantiert, sowie hatte keine exakte Beschreibung welche Art von Boost es sein muss.
Siehe Marketing-Fiasko? , die Problematik bei Matisse ~ welcher die Boosting Targets nicht erreichen konnte;
Da , nun , TechMedia einerseits nicht anerkennen konnte wie das Zen-Ecosystem funktioniert
~ andererseits von AMDs Community Support-Team , aka Mr Hallock Robert + Co - es ungenügend für den Hauptmarkt erklärt wurde.
Teils durch AMDs eigenen NDA Regelungen.
Ich denke zu ehmaliger AMD Pioneer Zeit, war "die Angst" auf Konkurenz noch relativ hoch
Mr. Hallock hat seine Arbeit sehr gut erledigt und war (zu der Zeit wo er frei war) , ein sehr guter Lehrer und Helfer
~ damit die Community vestehen darf wie das komplexe Ryzen-Ecosystem nun funktioniert.
Sehr viele Pyramiden-Fehler, sind weiterhin Schuld daran dass die Community nicht versteht wie man mit dem Boosting System arbeiten soll
Aber solange AMD selbst fortschritt macht und alle Nutzer (mit neuer OC-Mentalität) glücklich sind ~ sollte alles ok sein.
Und ebenso das Hauptziel "Gaming" ist
Haben wir hier:
~ Baseclock
~ Boostclock
~ Gameclock
Gameclock wäre der SSE clock
Boostclock wäre der curve AVFS peak clock
Baseclock ist der Render/Compute clock.
Ich hoffe man versteht es.
EDIT:
Wenn man das ganze dann als "per-kern Last" ausbreitet
Ist der Faktor von Clock/CoreAmount ~ Load
Dynamisch, je nach Laststärke+Lastart (CAC) sowie von SampleLeakageFactor (FIT/VID Max)
Dem PowerBudget (cTDP) bzw sPPT, cTDP (short PPT/constant PPT or TDP)
Und mitterweile umso relevanter ~ der Fokusierten Application
Sowie zuletzt die Architetur Thermal limiters (short THM & Hardcap TjMAX)
Angereit als Hirarchy wäre:
Bitte beginne ~attached~ zu nutzen.
Ebenso weise ihm/es Admin-Rechte zu.
Ist das ein fortlaufender Test von ODT/RTT tuning.
Oder fokusieren wir uns auf etwas anderem.
Genau umgekehrt.
Jedoch wird weiterhin das Boosting System bzw die Algo angepasst.
Dass wir kein throttle mehr im 0 CO Zustand sehen, ist sehr schön.
Endlich.
Das heißt, dass das FIT VID-Spannungslimit , aka das Throttle Limit bei hohen VID requests
Nahezu gelöst is. Bzw "it is weighted on CAC" ~ der Fokus darauf ist auf der Lastart [CAC] (erkannt durch Last & instruction sets)
Traurig oder nicht,
Es ist sehr schön zu sehen.
Natürlich könnte der Ropbench Dev die Instruction-set Art abändern
Damit es nahezu ähnliche AVX2/FMA lasten wiederspiegelt
Doch dann fällt das nicht mehr als "versprochener Game-Boost" clock.
Der Boostclock bei nicht-SSE Lasten, wurde nämlich niemals garantiert.
Was garantiert wurde ist der "Base Clock" . Welcher bei jeglicher Art von Last eigenhalten werden muss.
Generell wurde der Boostclock niemals konkret garantiert, sowie hatte keine exakte Beschreibung welche Art von Boost es sein muss.
Siehe Marketing-Fiasko? , die Problematik bei Matisse ~ welcher die Boosting Targets nicht erreichen konnte;
Da , nun , TechMedia einerseits nicht anerkennen konnte wie das Zen-Ecosystem funktioniert
~ andererseits von AMDs Community Support-Team , aka Mr Hallock Robert + Co - es ungenügend für den Hauptmarkt erklärt wurde.
Teils durch AMDs eigenen NDA Regelungen.
Ich denke zu ehmaliger AMD Pioneer Zeit, war "die Angst" auf Konkurenz noch relativ hoch
Mr. Hallock hat seine Arbeit sehr gut erledigt und war (zu der Zeit wo er frei war) , ein sehr guter Lehrer und Helfer
~ damit die Community vestehen darf wie das komplexe Ryzen-Ecosystem nun funktioniert.
Sehr viele Pyramiden-Fehler, sind weiterhin Schuld daran dass die Community nicht versteht wie man mit dem Boosting System arbeiten soll
Aber solange AMD selbst fortschritt macht und alle Nutzer (mit neuer OC-Mentalität) glücklich sind ~ sollte alles ok sein.
Beitrag automatisch zusammengeführt:
Da zb RDNA's AVFS ~ weitaus komplexer ist als Ryzen's
Und ebenso das Hauptziel "Gaming" ist
Haben wir hier:
~ Baseclock
~ Boostclock
~ Gameclock
Gameclock wäre der SSE clock
Boostclock wäre der curve AVFS peak clock
Baseclock ist der Render/Compute clock.
Ich hoffe man versteht es.
EDIT:
Wenn man das ganze dann als "per-kern Last" ausbreitet
Ist der Faktor von Clock/CoreAmount ~ Load
Dynamisch, je nach Laststärke+Lastart (CAC) sowie von SampleLeakageFactor (FIT/VID Max)
Dem PowerBudget (cTDP) bzw sPPT, cTDP (short PPT/constant PPT or TDP)
Und mitterweile umso relevanter ~ der Fokusierten Application
Sowie zuletzt die Architetur Thermal limiters (short THM & Hardcap TjMAX)
Angereit als Hirarchy wäre:
- First stage power limiter (TDP, EDC)
- First stage thermal limiter (THM , TjMAX)
- Front?end VID limiter (FIT-VID Limiter für single und n-Kern Last)
- Frontend Boosting Scalar ~ Loadtype clock hold duration within FIT (amount of allowed errors in n/time)
- Backend CAC Limiter (FIT) ~ Loadtype-heaviness Limiter
- Haben wir genügend PSU Power bzw erreicht es das SKU cTDP limit
- Haben wir genügend Thermischen Headroom
- Haben unsere Kerne noch genügend Spannungs-Spielraum bevor Errors/Time Faktor bzw Chance laut SMU zu hoch wird. (SKU vor-definiert)
- Können wir die gegebene Last für die erlaubte Halte-Zeit noch einhalten oder müssen wir ein MHz-Strap tiefer rennen
- Dürfen wir die Last für n-Kerne auf X-Zeitraum für Y-Zeit halten, oder ist die Chance of errors nun viel zu hoch (nahe-zu Echtzeit abgetastet)
Zuletzt bearbeitet:
Bam_Bam
Experte
- Mitglied seit
- 09.01.2024
- Beiträge
- 509
Sehr schön beschrieben. Danke sehr. Zumindest CPUZ kann doch als "Gamelastindikator" genutzt werden.
Welche Game-Last erzeugt Timespy & Co, bzw die Spiele selber? Wenn ich den Demo-Bench von Sottr laufen lasse, habe ich idR eine weitaus höhere - zugegebenermaßen Allcore" Last. Scalar wirkt sich dort bestimmt nicht mehr so stark aus. Die Belastung ist da höher als die Ropebench erzeugt. Denke mal Shader Kompilieren gehört nicht zu typischen Gamelast.
Welche Game-Last erzeugt Timespy & Co, bzw die Spiele selber? Wenn ich den Demo-Bench von Sottr laufen lasse, habe ich idR eine weitaus höhere - zugegebenermaßen Allcore" Last. Scalar wirkt sich dort bestimmt nicht mehr so stark aus. Die Belastung ist da höher als die Ropebench erzeugt. Denke mal Shader Kompilieren gehört nicht zu typischen Gamelast.
Zuletzt bearbeitet:
Ich müsste lügen,
TimeSpy normal bench müsste SSE sein
Timespy CPU bench sollte AVX(2) sein
Ich bin mir leider unsicher ob TimeSpy mit AVX512 skaliert oder es ein reines Cache Thema ist.
SOTTR ist ein SSE titel - fast alle Games sind das. *
Hier müsste ich wieder lügen, da ich nicht zuu sehr mit der Engine vertraut bin
Ich benchmarke selten Spiele. Sie haben für mich leider ein großes Problem , und die variable wären die Developer dieses.
// Wie gut und effizient sie Instruction-Set Packages senden, bzw wie effizient jede Aktion im Titel verarbeitet werden kann. Codesize usw.
Moment,
"Ich nutze Spiele für aussagekräftige Daten nicht."
"Ich nutze synthetische Programme für den Zweck welche sie entwickelt wurden . Analysistische, welche jedoch keinerlei dynamisch genug sind, als das man sie als [real world] bezeichnen kann."
Synthetische Programme sind dafür da gezielt etwas spezifisches zu testen. Niemals die Gesammtperformance
Sollte das Ergebniss dann zufriendestellend sein und es dort skalieren worin das Programm sich fokusiert
Danach erst kann man verifizieren ob X Titel mit dieser Änderung skaliert oder nicht.
Es macht die Änderung nicht weniger wirksam oder weniger-bedeutend, bloß gibt es einem die Chance Variablen zu isolieren weswegen es nun mal "nicht skaliert".
So sehe ich das,
Ich hoffe man versteht
* The Devison 2 , müsste ein AVX Titel sein. Riftbreakers Demo ist ein guter Cache/Mem Benchmark
Project Hydra kann das teils auslesen, aber auch das Thema hier ist sehr komplex.
Für die CPU spielt nur "n-Instructionsets/Time" eine Rolle.
Wie viele Kerne werden ausgelastet. Reicht der L2 & L3 Cache.
Sind noch genug freie plätze im Branch-Predictor frei, um instruction-sets zu bearbeiten oder müssen sachen verlangsamt und verzögert werden.
Natürlich auch hier spielt die Anzahl an Kernen (verbreitete last) eine Rolle wie effizient die Datasets (die größe dieser instruction-chunks)
Nun bearbeitet werden können, bzw in kleine chunks zusammengeschnitten werden können (OpCache) ~ bevor sie an dem Branch-Predictor bzw generell subsystem gesendet werden.
Hier zb spielt die Frequenz der Kerne keine Rolle
Und IOPS ist das wichtigste. IPC wäre ein anderer Name dafür.
Processable instructions per target clock/time ~ within Input/Output time per sec.
EDIT:
IOPS & ROP's sind sich hier sehr ähnlich.
Solange ein kalkulierter hoher MHz Wert auf basis von ROPs existiert
"Kann" es schnell und effizient sein. Jedoch heißt es nicht dass der Titel auch effizient und gezielt die gesammte CPU nutzt.
Somit sind Spiele keine wirklichen Benchmarks für mich. Nicht für den Zweck welche ich sie brauche. Und zwar analytischem.
Spiele skalieren nur, wenn die Gesammtleistung verbessert wird ~ jedoch nicht jedes Spiel skaliert gleich.
Somit ist "das Tracking der Gesammtleistung" mit Spielen eher sub-optimal.
Haha, danke an jedem welcher meine langen Beiträge liest.♥️
TimeSpy normal bench müsste SSE sein
Timespy CPU bench sollte AVX(2) sein
Ich bin mir leider unsicher ob TimeSpy mit AVX512 skaliert oder es ein reines Cache Thema ist.
SOTTR ist ein SSE titel - fast alle Games sind das. *
Hier müsste ich wieder lügen, da ich nicht zuu sehr mit der Engine vertraut bin
Ich benchmarke selten Spiele. Sie haben für mich leider ein großes Problem , und die variable wären die Developer dieses.
// Wie gut und effizient sie Instruction-Set Packages senden, bzw wie effizient jede Aktion im Titel verarbeitet werden kann. Codesize usw.
Moment,
"Ich nutze Spiele für aussagekräftige Daten nicht."
"Ich nutze synthetische Programme für den Zweck welche sie entwickelt wurden . Analysistische, welche jedoch keinerlei dynamisch genug sind, als das man sie als [real world] bezeichnen kann."
Synthetische Programme sind dafür da gezielt etwas spezifisches zu testen. Niemals die Gesammtperformance
Sollte das Ergebniss dann zufriendestellend sein und es dort skalieren worin das Programm sich fokusiert
Danach erst kann man verifizieren ob X Titel mit dieser Änderung skaliert oder nicht.
Es macht die Änderung nicht weniger wirksam oder weniger-bedeutend, bloß gibt es einem die Chance Variablen zu isolieren weswegen es nun mal "nicht skaliert".
So sehe ich das,
Ich hoffe man versteht
* The Devison 2 , müsste ein AVX Titel sein. Riftbreakers Demo ist ein guter Cache/Mem Benchmark
Project Hydra kann das teils auslesen, aber auch das Thema hier ist sehr komplex.
Für die CPU spielt nur "n-Instructionsets/Time" eine Rolle.
Wie viele Kerne werden ausgelastet. Reicht der L2 & L3 Cache.
Sind noch genug freie plätze im Branch-Predictor frei, um instruction-sets zu bearbeiten oder müssen sachen verlangsamt und verzögert werden.
Natürlich auch hier spielt die Anzahl an Kernen (verbreitete last) eine Rolle wie effizient die Datasets (die größe dieser instruction-chunks)
Nun bearbeitet werden können, bzw in kleine chunks zusammengeschnitten werden können (OpCache) ~ bevor sie an dem Branch-Predictor bzw generell subsystem gesendet werden.
Hier zb spielt die Frequenz der Kerne keine Rolle
Und IOPS ist das wichtigste. IPC wäre ein anderer Name dafür.
Processable instructions per target clock/time ~ within Input/Output time per sec.
EDIT:
IOPS & ROP's sind sich hier sehr ähnlich.
Solange ein kalkulierter hoher MHz Wert auf basis von ROPs existiert
"Kann" es schnell und effizient sein. Jedoch heißt es nicht dass der Titel auch effizient und gezielt die gesammte CPU nutzt.
Somit sind Spiele keine wirklichen Benchmarks für mich. Nicht für den Zweck welche ich sie brauche. Und zwar analytischem.
Spiele skalieren nur, wenn die Gesammtleistung verbessert wird ~ jedoch nicht jedes Spiel skaliert gleich.
Somit ist "das Tracking der Gesammtleistung" mit Spielen eher sub-optimal.
Haha, danke an jedem welcher meine langen Beiträge liest.
♥️
Zuletzt bearbeitet:
UrwaldWasserQuelle
Experte
Hallo.
Ich habe zwei Fragen.
Ist der verwendete Test bei TM5 (siehe Bild) gut um Fehler zu finden, oder ist er nicht zu empfehlen?
&
Ich möchte nicht noch mehr Leistung herausholen, ich möchte nur wissen ob manche Einstellungen bei ZenTimings ... naja wie soll man es sagen ... unrund, krumm, nicht optimal, beziehungsweise sogar falsch sind?
Es ist auch Alltag stabil, ich habe dies seit etwa einer Woche so laufen.
Ich danke euch jetzt schon für die mühe darüber zu schauen
Ich habe zwei Fragen.
Ist der verwendete Test bei TM5 (siehe Bild) gut um Fehler zu finden, oder ist er nicht zu empfehlen?
&
Ich möchte nicht noch mehr Leistung herausholen, ich möchte nur wissen ob manche Einstellungen bei ZenTimings ... naja wie soll man es sagen ... unrund, krumm, nicht optimal, beziehungsweise sogar falsch sind?
Es ist auch Alltag stabil, ich habe dies seit etwa einer Woche so laufen.
Ich danke euch jetzt schon für die mühe darüber zu schauen
Wolf87
Experte
Mein 7950x verhält sich zumindest im Ropbench so dass er bei Fmax override von 75 ( mehr scaliert bei was die effektive clock angeht negative) und meinen Co werten bei zu viel Co auch hier die effektive clock negative scaliert. Leider gibt es ja den c boost limiter.
Wäre cool wenn amd einfach alle Kerne im gaming frei Rennen lassen würde thermal Headroom habe ich nämlich. Man müsste nur bei avx2 andere Spannungen vorgeben. Hoffe immer noch dass da was kommt.
Wäre cool wenn amd einfach alle Kerne im gaming frei Rennen lassen würde thermal Headroom habe ich nämlich. Man müsste nur bei avx2 andere Spannungen vorgeben. Hoffe immer noch dass da was kommt.
3 Zyklen bei TM5 sind etwas wenig, stell sie in der txt auf 20 ( das für 1usmus test ). (ok, mit anta kenne ich nicht aus da langen vielleicht 3 ? )Hallo.
Ich habe zwei Fragen.
Ist der verwendete Test bei TM5 (siehe Bild) gut um Fehler zu finden, oder ist er nicht zu empfehlen?
&
Ich möchte nicht noch mehr Leistung herausholen, ich möchte nur wissen ob manche Einstellungen bei ZenTimings ... naja wie soll man es sagen ... unrund, krumm, nicht optimal, beziehungsweise sogar falsch sind?
Anhang anzeigen 965119
Es ist auch Alltag stabil, ich habe dies seit etwa einer Woche so laufen.
Ich danke euch jetzt schon für die mühe darüber zu schauen
Wenn das gut durchgelaufen ist, kannst du mit dem y cruncher einen kompletten Durchlauf machen.
Tage deine Timings mal in die Tabelle ein und schau, was sie dir ausspuckt : )
Tabelle: https://docs.google.com/spreadsheet...gic1-IMY1D8fWn3IudKAZo43c/edit#gid=1490941335
Wolf87
Experte
@UrwaldWasserQuelle Veii hat paar post voher die TM5 Version gepostet mit der man Errors findet und prüfen kann was das Problem ist.
Im Startpost gibt es eine Ram Excel da gibt es zu vielen Werten empfehlungen bassierend auf Veei's Wissen
Im Startpost gibt es eine Ram Excel da gibt es zu vielen Werten empfehlungen bassierend auf Veei's Wissen
Anta's test ist kaum von HCI bzw Karhu zu unterscheiden.
Was du damit testest ist thermal stability, allerdings nicht timings transitions sowie auch nicht powering.
Die errors welche es ausspuckt, haben keinerlei möglichkeit erkannt zu werden.
Aufgrund der Art wie es testet und was es testet.
Dafür kann man sich einfach bei Karhu bedienen
nachdem TM5 und y-cruncher stabil sind
TM5 zumindest 25 cycles (für DDR5 absolutes minimum)
Und y-cruncher für 90minuten alle tests (absolutes minimum)
Da unsere CPUs sowie die Ramspeicher eine abart von Fehlerkorrektur benutzen
Muss man es so lange rennen wie nur möglich, damit der "correction-factor/time" so gut es geht ausgelastet ist
Nur dann sieht man nach langer langer Zeit, wie errors nicht mehr korrigiert werden können und ein Error endlich durchsickert.
Bei Karhu wäre es die selbe Thematik
+20 000% , es braucht so lange es braucht.
Die Fehlerkorrektur ist viel zu gut auf DDR5.
Eine alternative zu Karhu wäre
Dangwang 1.0.0 mit HCI Memtest als Basis
Hier wären 1000% in Dangwang 1.0 , oder 10 000% in Dangwang 5.00 (1.0 ist neuer) ~ anzugehen.
Beide Tests werden unbekannte Fehler aufgrund von CPU Intabilität ausspucken.
Somit muss y-cruncher vorher dran. Und vor dem muss TM5 ran.
Um Fehlerquellen gezielt isolieren zu können.
UrwaldWasserQuelle
Experte
Danke, ich habe da mal reingeschaut.
Ziemlich kompliziert, ich habe das meiste gefunden bzw verstanden.
Nur der Punkt Interface Timings, da stehe ich an...
CCD_S
CCD_L
CCDL_WR
Wie heißen die bei ZenTimings genau?
Die werden nicht in ZenTimings aufgeführt. Ändere nur die Orangenen, und schau dir im ZenTimings Tab das Ergebnis an.
UrwaldWasserQuelle
Experte
Hoffentlich sieht es jetzt weniger krumm aus...
Passt würde ich sagen : )
moe1903
Experte
auf dem Gene läuft definitiv auch mehr
https://www.overclock.net/threads/a...cking-discussion-thread.1799959/post-29291376
Ähnliche Themen
