7800x3d undervolting Asrock 670e Steel Legend

[Tornavida]

Welchen Y Cruncher hast du den laufen lassen und mit welchen settings? (über core cycler oder y cruncher selbst?)

Y-Cruncher selbst alle Tests ,Version 0.7.10.9513.

3x1Std max um die 52° (laufen auf 1,25V)

kk, 1,25V sind auch unkritischer als z.B. 1,35V wie bei mir bei sehr langen Testsessions. Scheint ja zu passen.

Mal sehen wo ich mit den Cores lande, hab beim Home Office nebenbei schön Zeit

Ja geht schon wenns nicht zu sehr lahmt , viel Spass und Erfolg.

 

[iceman1792]

Vorweg, nochmals ein Dankeschön nochmals an @dernettehans für die Hilfe und Infos wie diesen Link:
https://www.reddit.com/r/Amd/comments/16s1e7h/my_experienceguide_to_undervolting_the_7800x3d/

Nach einigen Stunden des testens ist meine Kiste für Mich "Stable"
Werte von Core 0 aufwärts: -35, -30, -30, -15, -25, -25, -25, -35
Hab eigentlich einen sehr guten Prozi bekommen, yeah

Vielleicht kann ich euch hier noch einen etwas schnelleren Weg mitgeben über die WHEA Warnungen
Zuerst unter CPU-Z - About - save report as txt. - hier werden einen die ID Nummern der Threads angezeigt
Beim 7800X3D recht simpel core0 (0/1), core1 (2/3)....
Ich bin hier leider bei Prime95 etwas gestolpert,
mir ist immer der Worker 3 (laut Hwinfo Core2) ausgefallen (manchmal auch andere dazu), das CO nachstellen brachte aber nur eine hinauszögerung des Errors, W3 crahste tdm irgendwann
Im Logger wurde mir ID:7 angezeigt =(Core3-6/7)
So, also den Core2 einfach wieder zurück auf -30 gestellt und core3 von -25 auf -20, weg waren die Errors - das bedeutet also, nur weil Worker3/core2 ausfällt (core2 war dann im idle) bei prime95 ist dieser nicht automatisch/sicher schuld dafür, die hängen anscheinend iwie zusammen
Erkenntnis hat mich einiges an Zeit und Nerven gekostet

Workflow von mir (reddit Anleitung als Basis und einiges vom Thread hier):

1. In der Ereignisanzeige einen WHEA Logger erstellen - ganz wichtig - Im BIOS kontrollieren ob PCIE Advanced Error Reporting aktiviert ist (danke für die Info)
Bei meinem MSI B650 Tomahawk hab ichs im BIOS nicht gefunden aber es war default aktiviert

2. PBO CO-40 All Core einstellen (kann sein das der PC nicht mehr bootet oder schon Abstürzt wie bei mir)

3. CoreCycler - Kizuna(AVX512) - All Tests (+C17) - runtime per Core = 10min - 2 Threads
Solange mit diesen Settings testen bis Kizuna min. 5 Durchläufe(~6,5Std.) ohne Error schafft
Ich habe jedes mal die Core Reihenfolge in der config geändert so das beim erneuten starten immer der betroffene/geänderte als erster kommt und dann welche die noch nie getestet wurden, so geht das ziemlich zügig
hab mich generell für CO 5er Schritte entschieden - auch kein Feintuning mehr

Wer möchte kann hier den Punkt 4 mitnehmen, hat bei mir mit 5 Durchläufen bei core6 -5 weniger beim CO gebracht als Kizuna, beim nächsten mal würde ich aber ab hier sofort kurz zu OCCT gehen als Schritt 4
(4. CoreCycler - Kagari(AVX2) - All Tests (+C17) - runtime per Core = 10min - 2 Threads, 5 Durchläufe -6,5Std.)

4/5. OCCT - Large - Extreme - variable - AUTO (AVX2)
OCCT zeigt sofort an wenn ein WHEA Error ansteht, dann geht man zur Ereignisanzeige/WHEA Logger und schaut bei der Warnung welche Prozessor APIC ID angezeigt wird
Bei diesem Core dann um 5 weniger im CO einstellen und das Spiel von vorne
Solange mit diesen Settings testen bis über 1 Run (1h) kein Error mehr kommt

6. Y-Cruncher (neueste Version, hat neue/andere Tests statt N64 und C17 und stresst alle Cores zugleich) Settings: Stress Test - All Tests - runtime 120s - als Abschluss Overnight
bei mir nach der Vorarbeit sofort ~8,5Std. 36 Durchläufe ohne Fehler

Und weil ich mir dachte ich teste für euch noch ein bisschen habe ich heute von 10:00 bis jetzt 22:00 Prime95 Blend laufen lassen - auch ohne Fehler - also meiner Meinung nach kann man sich das sparen

OCCT hat mich auf voller Linie überzeugt und Fehler angezeigt wo Y-Cruncher, Prime95, CoreCycler Kizuna und Kagari nichts mehr angezeigt haben
Ich würde das nächste mal zum starten aber tdm mit Kizuna oder Kagari beginnen um mal grob die Kerne zu testen/auszuloten, bei OCCT kann es leicht passieren das der PC komplett abstürzt anfangs
Genere
Ob die Tests auf jeden Prozessor gleich anspringen kann ich nicht sagen, hab schon andere Erfahrungen gesehen wo sich mit Kizuna ausgelotete Werte bei Kagari dann fast halbiert haben
Anscheinend ist AVX2 anfälliger als AVX512, da Kagari und OCCT mit AVX2 testen und nach Kizuna noch immer ein ERROR kam
sp00n.82 hat ja im CoreCycler thread mal geschrieben das AVX512 bei games usw. fast noch nirgens verwendet wird und AVX2 sehr oft dieser Tage

Meine Meinung (safe way Kizuna und Kagari):
1. Kizuna (Gesamt ~10 Std. mit ausloten) oder eben direkt Kagari (hat noch etwas sensibler reagiert und was gefunden nach Kizuna, kann sein das dies noch besser/schneller funktioniert, schwer zu sagen, hab eben selbst mit Kizuna begonnen und weis nicht wie Kagari bei den anderen Core reagiert hätte)
(2. Kizuna/Kagari gleiche Settings wie 1. overnight wenns einem nicht stört)
2. OCCT (geht recht zügig, habs 3x laufen lassen)
3. Y-Cruncher (neue Version, 120s, All Core) overnight als Abschluss (hat bei mir halt nichts gefunden, ka wie gut/sinnvoll dies wirklich ist)

Abschlussworte:
wer nicht gerade interessiert an der Materie ist oder nicht in die "rabbit hole" fallen will fängt besser erst garnicht an oder probiert -10/-15 Allcore, ich hatte zb. Abstürze beim Anmeldebilschirm/Desktop und einmal nachdem ich ein Spiel geschlossen habe - dies hat mich zu dieser Prozedur bewegt
Wer zu viel Zeit/Home Office/Krankenstand/Langeweile..... hat und interessiert ist - Perfect Run

 

[dernettehans]

Werte von Core 0 aufwärts: -35, -30, -30, -15, -25, -25, -25, -35
Hab eigentlich einen sehr guten Prozi bekommen, yeah

Es ist eigentlich oft so, dass man nur 1-2 "faule" Kerne hat, und die andern recht hoch gehn bis zu minus 30-35. Das ist leider ein hoher Aufwand das durchzutesten um dann für jeden einzelnen Kern die Kurve anzupassen. Mir war das selber bisher zu aufwendig daher läuft bei mir bisher noch Faulheitsbedingt -20 all core. -30 all core geht bei mir zb nicht das weiss ich schon. Ich hab zzt einfach zu wenig Zeit und auch Energie das durchzuesten aber werde es vermutlich irgendwann mal machen.

Bei mir ist in Prime95 einmal die letzten Tage auch auf Worker3 ein Rundungsfehler (6000000 Lucas-Lehmer in-place iterations of M102991 using AVX-512 FFT length 5K, FATAL ERROR: Rounding was 0.4999846117, expected less than 0.4) gemeldet worden ohne WHEA, komischerweise aber genau in dem Moment, als ich den Test beendet habe. Bisher keine Fehler in anderen Situationen. Frage mich ob das vieleicht ein Fehler in Prime95 ist.

Ich kann bestätigen dass bei mir OCCT auch am schnellsten Fehler identifiziert hatte.

 

[iceman1792]

bei mir meistens sofort beim ersten mit Prime95 Blend Setting, startet mit 2100K lengh und da kam dann in den ersten ~5-10 Minuten (ERROR Rounding was 0.5 expected less than 0.4.....wie bei dir)
Bei Prime kommt nicht immer ein WHEA, das ist mir auch aufgefallen
bei mir gabs sogar mal einen ERROR aber der Worker hat den kompletten test der lengh noch fertig gemacht und dann erst gemeldet, sah man im verlauf und den Error Ton habe ich zwischendurch gehört
mit 5 weniger am core kam nie mehr was
schon brutal wie schnell die dinger anspringen bzw. der pc versagt

OCCT- Ja, schade das die jetzt monatlich was verlangen, die WHEA Funktion ist schon geil, das könnte per core und vieles mehr auch noch...
wäre eine richtig saubere Lösung, sozusagen All in One Programm

 

[dernettehans]

@iceman1792 Ja mich nervt an Prime95 dass man gar nicht mitbekommt ob es einen Fehler gab, sehr schlecht umgesetzt. Er läuft einfach weiter obwohl es einen Rundungsfehler zwischenzeitig gab und man sieht das nicht. Vermutlich bricht der Worker nur ab wenn ein WHEA error auch kommt sonst läuft der weiter.

Naja du musst halt einmal $4 zahlen für 1 Monat das reicht ja eigentlich zum testen. Dann kannst du OCCT auch mal über Nacht laufen lassen. Gibt dort ja auch core cycler ich weiss nur nicht ob das mehr bringt als auto zb.

 

[Mettmelone]

Danke für die ausführliche Beschreibung deiner Vorgehensweise, das wird bestimmt einigen helfen.

Ich hab hab einen Ausreisser, der prdoduziert ab -11 Fehler. Kein Beinbruch.

HWInfo64 schaut auch permanent auf WHEA-Fehler. So kann man zumindest beim erscheinen kurz ins Log gucken und den verursachenden Kern festmachen. Was man nicht braucht, kann man ja deaktivieren... Meine Einstellungen passen auf eine bildschirmhohe Spalte mit über 300 ausgeblendeten / deaktivierten Werten.

Beim finden der passenden CO-Werte war ich als Project Hydra-Nutzer faul und habs die Software erledigen lassen. Eigentlich nutze ich das Tool schon seit einer Weile nicht mehr, aber die paar Kröten im Monat kann ich ruhig noch dem Ersteller schenken in der Ukraine.

Und weil im Threadtitel das X670E Steel Legend steht: Das aktuelle BIOS 2.0 bootet deutlich schneller nach Änderungen im BIOS (dauerte ja sonst mal ne Minute) und auch ohne Änderungen gefühlt etwas zügiger. RAM und Curve Optimizer laufen mit dem neuen BIOS mit unveränderten Einstellungen bei mir (EXPO zum übernehmen der Werte, Timings "Agressive", SoC manuell auf 1.1V, 32 GB G.Skill F5-6000J3038F16GX2-FX5) . Ist in dem Punkt zumindest nicht schlechter geworden.

 

[Tornavida]

Finde ich auch schön kompakt beschrieben 👍 . Hab mein System zwar nur mit Y cruncher und Testmem Absolut/Anta ausgelotet aber der Text hat mich motiviert noch mal an die -20er Kerne mit OCC in kleineren Schritten Hand anzulegen. War bisher faul über 5 er Schritte hinauszugehen.

 

[iceman1792]

was halt noch etwas blöd ist das CoreCycler auch fast nie oder nie WHEA Fehler produziert
meistens kommt dann einfach bei
Checking CPU usage: 0%
dann probiert er noch 3mal und sagt
There has been an error while running the stress test programm
leider hab ich den corecycler dann schon geschlossen
Man muss sich hier darauf verlassen das dies wirklich vom Core der Fehler war und nicht vom Programm
Leider hab ich zu den Alarmen nichts genaueres gefunden wie Meldungen usw....

zu OCCT noch - hab kurz einen Core von-35 auf -40 gestellt und mit kagari nur diesen getestet, sofort ERROR mit absturz,
dannach mit OCCT All Core 10min kein ERROR
dann OCCT corecycler nur diesen angewählt, sofort nach sekunden ERROR - funktioniert also TOP und min gleich gut wie Kagari (bei beiden Kagari und OCCT kein WHEA Error angezeigt oder im Logger)

@Mettmelone
Hab das gesehen, hätte mir auch besser gefallen wenns funktioniert und wäre sicher um einiges bequemer
Aber ich hab da fast nichts drüber gefunden bzw. war für den corecycler alles viel einfacher zum finden/nachlesen
vl hast du einen guten Link für mich
HWinfo - Für WHEA meinst du den Punkt ganz unten im Monitoring?

@Tornavida
ich bin da auch zu faul, denke aber nicht das es den Mehraufwand lohnt, 5er reichen meiner Meinung nach wenn man manuell testet

So das wars für mich jetzt mit testen, wünsche ein schönes Wochenende

 

[Mettmelone]

CoreCyler selbst produziert in der Tat wenig Fehlermeldungen, ja. In der Ereignisanzeige von Windows tauchen die aber sofort auf.

Und ja, den Punkt meine ich in HWInfo. Sobald in der Ereignisanzeige ein WHEA-Fehler auftaucht, springt HWInfo darauf an und meldet dir das. Nachgucken welcher Kern es ist und CO anpassen ist dann ja nur noch Formsache.

Project Hydra findet man drüben bei Igors Lab bzw bei Patreon / 1Usmus, das ist der Typ, der auch den Ryzen Clock Tuner und den Ryzen DRAM Calculator zusammengebastelt hat. Da der aber in der Ukraine wohnt, ist die Entwicklung zur Zeit logischerweise etwas stockend.

Für X3D - CPUs lohnt das Tool aber eher nicht, da man an den CPUs deutlich weniger Hebel für Spannung und Takt ansetzen kann als bei nicht-3D-Modellen. Aber es ist eben praktisch, wenn es selbst die einzelnen Stufen vom CO auf Stabilität durchtestet ohne das man ins BIOS bzw überhaupt was tun muss. Das Ergebnis ist nicht 100% , bei meinen gebauten Systemen mit 5600X, 5900X, 7700X und 7800X3D musste ich aber nie mehr als 1-2 Kerne um max eine Stufe beim CO ändern.

Für "starten, zur Arbeit fahren und zum Feierabend ne Liste mit Einstellungen für den CO haben" ist das meiner Meinung aber ziemlich gut. Spart halt einfach ganz viel Zeit.

 

[Tornavida]

Habe mal heute morgen gestartet und 5 Kerne gleichzeitig von -20 auf - 22 getestet ausgehend von einem Setup wo ich weiss, dass es stabil ist und nebenher laufen lassen . Mehr habe ich nicht gewagt, da ich noch am Arbeiten bin nebenher . Naja, Kleinvieh macht ja bekanntlich auch Mist. 1 St. OCC und dann mal den neusten Y-cruncher hinten dran. Bissl zocken und dann gibt es nochmal -2 oben drauf demnächst. Aber so langsam dürfte dann auch Clockstretching Thema werden. Bisher passt es aber z.B. bei CB mit den Werten.

 

[dernettehans]

Hab gestern auch noch mal probiert diesmal nur mit OCCT und large, extreme, auto sowohl auch core cycler. Leider ist die Sache bei mir etwas "komplizierter".

all 35
occt, reboot
all 30
WHEA apic id 9 (core 4) => 30 auf 25
occt, freeze, (core 4) => 25 auf 20
WHEA apic id 8 (core 4) => 20 auf 15
bsod

core cycle 27s, bsod
core 7 30 auf 20
core cycle 27s, bsod
core 6 30 auf 20
core cycle 27s, bsod
core 0 30 auf 20
core cycle 8s, bsod
core 1 30 auf 20
bsod

Danach hatte ich erst mal keine Lust mehr und bin ins Bett.

Um das obige etwas zu beschreiben:

All core -35, hat schon mal gar nicht funktioniert, reboot sobald OCCT. All core -30 nach einigen Sekunden WHEA error stop (kann man in OCCT einstellen, dass er sobald der erste WHEA geworfen wird stoppt), Windows logs zeigte apic id 9 an also nach Tabelle core 4 auf 25 gestellt, erneut laufen lassen. Total freeze. Core 4 auf 20 runter, neuer Run. Diesmal WHEA auf apic id 8 also immer noch core 4. Core 4 auf 15 runter, neuer run. BSOD. Neuer run diesmal core cycle. Nach ca 27s BSOD. Das deutete für mich darauf hin, dass es einer der letzten Kerne sein müsste, problem ist hier dass die Reihenfolge nicht stimmt denke ich. Hab dann Core7 runter auf 20. Wieder BSOD bei 27s. Core6 auf 20, wieder BSOD bei 27s. Core0 diesmal auf 20, BSOD nach 8s. Core1 auf 20, BSOD direkt beim booten in Windows.

Danach hatte ich erst mal keine Lust mehr und hab noch mal alle auf 20 gesetzt außer core4 auf 15. Noch mal extreme large auto laufen lassen diesmal lief alles durch 30 min. Also vermutlich einer der anderen Kerne der alles mitreißt der nur ca 15-20 verträgt und auch kein WHEA wirft sondern direkt zu BSOD oder freeze führt.

Ich könnte das noch mal umgekehrt testen von unten jeden Kern einzeln langsam um 5 hoch aber irgendwie hab ich da keine Lust zu. Denke werde es bei -20 -20 -20 -20 -15 -20 -20 -20 lassen. Denke auch dass core4 vermutlich für den Rundengsfehler verantwortlich war vorgestern mit worker3.

Jedenfalls ist OCCT sehr gut daran die Fehler sehr schnell aufzuzeigen, was mit prime95 und ycruncher nicht so geht oder sehr lange dauert. Bei mir leider so gut, dass der PC direkt freezt oder bluescreent und ich nicht zu der WHEA info komme welcher Kern es war.

Hatte vorhin noch mal -35 -30 -20 -20 -15 -20 -20 -20 getestet und es lief auch durch, also vermutlich einer der anderen hinteren Kerne der das Kartenhaus einreißt mit dem Arsch. Aber werde es wohl bei -20 -20 -20 -20 -15 -20 -20 -20 lassen. Zwei mal SB23 gemacht und identische Werte um 18350 bekommen selbst mit beiden ersten kernen auf -35 -30 zu -20 -20. Ich frag mich auch wie optimal es ist wenn die Kerne alle stark unterschiedliche Spannungen nutzen ob das zu Problemen fühen kann, oder ob ein billigeres Board da vieleicht Probleme hat für jeden Kern einzeln die Spannung genau einzeln anzupassen.

 

[dernettehans]

Ich bin jetzt grad bei -30 -30 -15 -15 -5 -15 -25 -15. Core#4 musste ich bis -5 absenken er hat noch bei -10 Fehler geworfen abundzu in OCCT aber ohne WHEA, genauso core#2 core#3 und core#7 jeweils alle ohne WHEA Fehler nur error in OCCT. OCCT läuft grad noch mal sehn welche ich noch absenken muss. Dafür scheint core#0 und core#1 bei -30 zu laufen.

Update: Ich musste Core#4 auf 0 setzen, hat immer noch Fehler geworfen bei -5. Das hab ich jetzt nicht erwartet. Bin jetzt bei -30 -30 -15 -15 0 -15 -25 -15 Test läuft weiter. Frag mich grad ob das wirklich realistisch ist oder ob es am IF liegen könnte den ich auf 2133 habe. Oder ich doch SOC von 1.15 auf 1.2 erhöhen müsste, mal sehn wie es jetzt weiter läuft. Auffällig jedoch es ist weiterhin immer wieder core#4 gewesen bei Fehlern. Hoffe mal nicht auf einen Hw Schaden in dem Kern.

 

[iceman1792]

IF hab ich nur 2033 und 1,2v soc und 1v vddp
Reboots hatte ich nur anfangs und bluescreens gar nie
Die cores schießen sich manchmal gegenseitig ab wenn man weit weg ist bi all core tests kommt vor

ABER:
Ich muss die aussage zu Prime zurück ziehen
Der PC hatte zeit und ich nur hab doch noch was getestet in der Zeit wo ich nicht Zuhause war
Anscheinend gibt es einen neuen Endgegner für meinen PC
Werte wo keine Fehler kamen und für mich stable waren.
wenn einer einen fehler gab hab ich diesen wert übernommen und nicht wieder höher gestellt für den nächsten Test
Dies sind alle tests der letzten woche in dieser Reihenfolge:
Kizano 8h: -35,-30,-30,-25,-25,-25,-30,-35
Kagari 2 run 2,5h: -35,-30,-30,-25,-25,-25,-25,-35
YCruncher All Core 9h: -35,-30,-30,-20,-25,-25,-25,-35
OCCT(all core): -35,-30,-30,-17,-25,-25,-25,-35
Kagari 13h: -35,-30,-30,-17,-25,-25,-25,-35
P95 All Core Blend 11h: -35,-30,-30,-17,-25,-25,-25,-35
ENDGEGNER:
Corecycler P95 AVX512 time auto smallest: -32,-30,-26,-17,-19,-23,-25,-31
Fehler wurden immer sofort im log und corecycler angezeigt
Im großen und ganzen war das der sensibelste test

Also einfach als erstes mit smallest per core cycler ausloten dann sollte alles durchlaufen
Bin selbst etwas verwundert wie schnell die cores hier aussteigen, meist um die 4-8k tests von prime

 

[dernettehans]

IF hab ich nur 2033 und 1,2v soc und 1v vddp

Ruder zurück! Hab einfach mal IF bei mir von 2133 auf 2000 gesetzt weil ich das verdächtig fand, dass bei mir Core#4 immer noch bei -5 Fehler geworfen hatte. Es schien in diesem Falle in der Tat am IF gelegen zu haben.

Bin jetzt wieder bei -30 -30 -20 -20 -15 -20 -20 -20 mit IF 2000 und immer noch soc 1.15 vddp 0.95. Die vorherigen Fehler scheinen weg zu sein. Einige male gestern noch mal OCCT CPU large/ultra/auto laufen lassen.

Ich hab aber festgestellt, dass es noch sinn macht wenn man OCCT laufen lässt zusätzlich noch einige Chrome zu öffnen wo zb ein Video auf twitch.tv abgespielt wird und sich nicht auf einen 30m Test ran zu verlassen. Ich hatte jetzt ein zwei mal einen Fall, wo Fehler gemeldet wurden erst nach ca 2 Stunden in OCCT das ist in diesem Falle wieder Core#4 gewesen daher hier nun auf -15. Ich hab in Ryzenmaster auch gesehn, dass Core#4 in Ryzenmaster Core5 als zweitschnellster Kern markiert ist, heißt Windows nutzt diesen zusammen mit dem erst schnellsten Kern zuerst für alles mögliche, daher sind diese beiden Kerne auch kritischer.

Werde noch mal IF 2033 testen später oder die Tage. RAM Temperatur hab ich natürlich immer im Auge, da ist mir auch aufgefallen was ich bereits vorher sagte, dass dieser Fehler wirft mit den BZ Timings wenn er ca bei 53-55°C anlangt nach längeren Stresstests, das passiert bei OCCT bereits nach ca 15-20 Minuten. Mein Front Lüfter läuft auf Silent, wenn ich diesen auf Standard setze macht das ca 1-2°C aus beim RAM und er geht auf ca 51°C im OCCT Test. Gaming wird der RAM aber niemals wärmer als 35-40°C.

 

[Tornavida]

Ram sollte 100% mit den eingestellten Timings laufen bevor man sich die Feinabstimmung mit dem CO gibt. Hat einen grossen Einfluss; notfalls hilft auch entschärfen um mit dem IF hochzukommen und mehr negatives Offset einstellen zu können. Muss man mal selbst schauen was mehr bringt.

 

[dernettehans]

Ram sollte 100% mit den eingestellten Timings laufen bevor man sich die Feinabstimmung mit dem CO gibt.

Das wurde alles bereits gemacht, RAM läuft stabil wenn er unter 53-55°c bleibt wie oben auch steht. Ich hatte den IF erst vor einigen Wochen hochgestellt von 2033 auf 2133 und erst jetzt noch mal getestet.

 

[iceman1792]

RAM, SOC.... muss natürlich stabil sein

Für mich bleib ich dabei

Resümee:
Neue Erkenntniss - Schnellster weg - tiefste CO werte aller Tests:
Corecycler P95 AVX512 time auto smallest
4608 bis 21k, von 4-7k ist bei mir fast alles sofort ausgestiegen im 1 run, CO um 2er schritte verstellt und test, sonst wieder 2 und test

Dannach kann man overnight noch verschiedene tests laufen lassen, sollte aber kein error mehr kommen

Zumindest bei mir ergibt dieser test die konservativsten/tiefsten settings in der kürzesten Testzeit wo alles andere nicht aussteigt
Reagiert auch sofort drauf wenn man mit den nächsten 2 CO schritten noch immer zu tief ist oder genug ins + gegangen ist
Vielleicht ist es hier generell besser einfach mit all core -20 anfangen und tiefer zu gehen, dann hat man auch keinen core der völlig daneben ist und Fehler produzieren kann

Beschreibung oben werde ich noch abändern 👍
Vl könnte das ja noch jemand testen/bestätigen

 

[Bam_Bam_GER]

Ram sollte 100% mit den eingestellten Timings laufen bevor man sich die Feinabstimmung mit dem CO gibt. Hat einen grossen Einfluss; notfalls hilft auch entschärfen um mit dem IF hochzukommen und mehr negatives Offset einstellen zu können. Muss man mal selbst schauen was mehr bringt.

Habe auch gerade diese Vermutung.
Bin mit meinem 7800X3d bei 6400/2100 stable bei CO -10 allcore. Gehe ich auf -15 allcore Crasht mir Testmem5 mit diversen Fehlermeldungen und anschließendem BS.
Bei 6000/2000 war schon CO20 allcore stabil.
Denke mal das es vom Game anhängt was mehr bringt. Ich denke höhere RAM / IF ist oft eher von Vorteil als 50 - 100 Mhz allcore Mehrtaktboost.

 

[4BitDitherBayer]

Bei einer X3D CPU spielt der RAM keine so große Rolle die Wünschenswerte Reihenfolge sollte daher sein.

1.CPU
a.) Wenn im Bios möglich sollte man erst einmal die LLC so weit wie möglich absenken damit die CPU im Multi Core Volllast nicht so durstig bzw. warm ist. Sollte das 100% sauber laufen kann man zu b.) über gehen.
b.) CO einstellen das ist der Punkt der am meisten Leistungszuwachs verspricht u. auch Temperaturen verbessern kann. Es ist aber nicht ganz einfach die Korrekten Werte für seine CPU zu ermittelt.

Erst wenn die obigen Punkte zu 100% erfüllt sind würde ich zum RAM über gehen.
Der sollte ja bisher mit seinem Standard Profil zwar recht langsam aber auch 1000% sauber gelaufen sein.

2.RAM
a.) Da könnte man jetzt erst mal das XMP austesten ob das wirklich sauber funktioniert. Wenn da alles gut ist kann man versuchen die Geschwindigkeit zu erhöhen.
B.) Oftmals ist eine höhere RAM Geschwindigkeit besser als niedrige Timings.
Am besten die Geschwindigkeit in kleinen Schritten erhöhen bis die Ersten Fehler auftreten. Dan kann man versuchen mit Spannungen, widerständen u. höheren Timings gegen zu steuern.

Das alles ist recht Test/Zeit Aufwändig weshalb man eine gewisse Reihenfolge einhalten sollte um sich nicht selbst immer wieder ein Bein zu stellen.
Ich bin mit dieser Reihenfolge immer recht gut gefahren wobei ich bei meinem Aktuellen RAM wenig Glück hatte. 4 günstige RAM Riegel in einem günstigen Einsteiger Board war vielleicht nicht die Beste Idee

Generell würde ich beim RAM sogar dazu raten nur das XMP zu laden u. fertig.
Gerade die X3D´s profitieren eben nicht so viel wie andere CPU´s vom schnellen RAM. Meiner Meinung nach ist es daher den Zeitaufwand nicht mehr wert da rein zu stecken.

Sollte einem der X3D in Spielen zu langsam sein werden einem die 2% Leistungszuwachs durch RAM OC auch nicht weiter bringen. Da ist man mit einer Stärkeren Graka besser bedient in so einem Fall.

 

[Verangry]

Bei einer X3D CPU spielt der RAM keine so große Rolle...

So nicht ganz richtig, kommt es doch sehr auf das Spiel an, oder die Anwendung.

Sollte einem der X3D in Spielen zu langsam sein werden einem die 2% Leistungszuwachs durch RAM OC auch nicht weiter bringen. Da ist man mit einer Stärkeren Graka besser bedient in so einem Fall.

2% sind es leider nicht.

Nehmen wir mal das wohl beste Beispiel für RAM OC (Cyberpunk) dann sind es von "Expo" laden bis maximal ausgelotet und feingetuned über 20% mehr Leistung durchschnittlich, nur durch RAM OC und die lows (das was die Ruckler ausmacht) sind sogar 26% besser.

Also eigentlich braucht man nur RAM OC machen, den CO hab ich bei mir aktuell sogar aus..