News AMD Ryzen 5000: CoreCycler aus der Community optimiert den Curve Optimizer

[xxlhellknight]

Bei mir kommt nen rundungsfehler bereits mit default settings bei core 3.
Würdet ihr da die cpu bereits zurückgeben, oder behalten. Die cores im 2. Cluster gehen dafür alle bis auf 3 bis -30.

 

[SuperSabo]

Ist halt die Frage ob tatsächlich ein Defekt (siehe oben) oder nicht und ob ein Austausch „besser“ wäre

 

[sp00n.82]

Mit CO wirft er bei mir bei den Kernen die zu niedrig angesetzt sind immer nur Fehler bei FFT length 40K , nie bei den anderen Größen.

In vorherigen Versionen gab einen Bug bei der Erkennung der fehlgeschlagenen FFT-Größe, da wurde teilweise immer nur die erste innherhalb der Testreihe angezeigt. Das sollte mittlerweile mit 0.7.8.9 gefixt sein.

In der results.txt wird leider nicht der FFT-Wert angegeben, bei dem der Fehler aufgetreten ist, nur diejenigen, die erfolgreich durchgelaufen sind. Deswegen muss ich das anhand einer festen Reihenfolge abschätzen, wo der Fehler aufgetreten sein könnte.
Und zusätzlich verwendet Prime95 bei FFT Größen oberhalb der "Small FFT" anscheinend einen Zufallsmechanismus, d.h. da kann ich jetzt gar nichts mehr abschätzen, wo der Fehler aufgetreten ist, bis ich den verwendeten Algorithmus durchschaut habe.

PS: Wenn du gerade zufällig mit Aida64 am Testen bist: wie ist denn die Prozessorauslastung, wenn du manuell die aida_bench64.dll nur auf CPU 0 setzt (also Core 0 Thread 1)? Bei mir weigert sich dann Aida, den Prozessor voll auszulasten, evtl. ist das fest eingebaut, dass auf dem ersten (virtuellen) Kern nie 100% Auslastung sein soll. Auf CPU 1 (Core 0 Thread 2) funktioniert das hingegen korrekt, auf allen anderen Kernen auch.


Und bezüglich der Fehler selbst bei Stock-Settings von PBO: da würde ich mal alle anderen Overclocks, die eventuell vorhanden sind (IF/RAM) zurücksetzen und nochmal testen. Wenn die instabil sind, kann das natürlich auch bei dem Test hier Fehler werfen.
Und ich bin mir nicht mal sicher, ob man seine CPU wegen fehlerhaftem PBO umtauschen könnte. Mit dem Einsatz von PBO verliert man ja offiziell seine Garantie, keine Ahnung, ob das als Umtauschgrund akzeptiert werden würde. 🤔

 

[SuperSabo]

Wenn ich Stock sage, meine ich Stock. Also auch kein PBO…

 

[therealcola]

@

xxlhellknight​

​

würde hier auch die Ram Einstellungen überprüfen. evt ist da doch etwas nicht stabil. Der Takt zu hoch, die Latzen zu niedrig, die Spannung zu niedrig eingestellt etc.​

​

​

 

[xxlhellknight]

@

xxlhellknight​

​

würde hier auch die Ram Einstellungen überprüfen. evt ist da doch etwas nicht stabil. Der Takt zu hoch, die Latzen zu niedrig, die Spannung zu niedrig eingestellt etc.​

​

​

Hab schon mit und ohne xmp Profil getestet und mit neusten bios(agesa1.2.0.0) und beta bios (agesa 1.2.0.1).

Ergänzung (12. März 2021)

Lief vorher zwischen 2-30(negative). Mit prime95 single core small fft jeden kern 3 Stunden durchgetestet. Und mit dem Tool, wahrscheinlich wegen sse, stürzt prime95 auf core 3 selbst mit plus 1 ab.

 

[Merden]

Hallo Zusammen,

Ich habe bei mir hier folgenden Effekt mit dem CO beobachtet (AGESA 1.1.0.0 und 1.2.0.0 und unterschiedliche RAM-Settings):

• Mit Karhu Ram-Settings bis min 20.000 + 5.000 geprüft
• OCCT mit SSE und smallFFT jeden Kern ausgelotet
• mit diesem Tool hier über viele Nächte und Iterationen ohne Fehler getestet (danke nochmal dafür)
• AIDA Stabilitätstest
• diverse Games + Grafikprogramme
• Idle-Stable (auch mehrere Tage am Stück)
• keine WHEAs unter Agesa 1.1.0.0 - 1.2.0.0 scheint bei mir auch unabhäng von CO buggy zu sein

ABER: Ich bekomme in folgendem Szenario mit 10-25% Wahrscheinlichkeit einen unvermittelten Reoboot :

Cinebench R20 Multi durchlaufen lassen -> 10-30s warten -> Cinebench R20 single

Der Reboot passiert dabei interessanterweise bereits in der "preparing project" -Phase, also noch bevor die eigentliche Last auf einem Core anliegt. Sobald der Test einmal erfolgreich angelaufen ist, läuft er auch durch. Wenn man sich den Task-Manager anschaut, wird in der preparing-phase des Single-Core Benches auf allen Kernen ein sehr kurzer Doppel-Peak auf ca 40% Last erkennbar, bevor der eigentliche Bench auf einem Core mit 100% anläuft und die anderen Kerne in den Idle-Betrieb gehen. Vielleicht ein Hinweis auf die gefürchtete Teil-Last Instabilität?

Dabei habe ich bereits alle Cores auf -5 und z.T. -10 zu den mit o.g. Tools auf Stabilität ermittelten Setting getestet. Der Cinebench Multi+Single Test erzeugt dennoch ab und an einen Reboot. Ohne CO oder bei ganz geringen Werten (max. -5) passiert das nicht.

Mich würde interessieren, ob bei Euch ein solches Verhalten nachvollzogen werden kann.

 

[scuba2k3]

Im readme steht das default nur der physische core ohne SMT getestet wird. Aber wenn ich nun meine CPU mit SMT verwende(was ja auch eine höhere Last erzeugt) ist es dann nicht auch logisch im tool auch 2 Threads einzustellen?

was genau verstehe ich hier nicht?^^

 

[Xechon]

was ja auch eine höhere Last erzeugt)

Das Problem im Moment ist wohl, dass die Stresstests unter voller Last meist problemlos durchlaufen. Es geht um die Wenig-Last-Szenarien. Da hast auf einmal random reboots.

 

[SuperSabo]

Für die, die auch mit Stock Settings Kerne haben, die aussteigen: Ich habe bei mir die Global C-States deaktiviert, da ich auch einer von denen bin, die USB-Probleme haben und dies ja der Workaround hierfür ist, und siehe da: Prime Stand Alone lief die Nacht über ohne Fehler durch.

Give it a try!

 

[sp00n.82]

Im readme steht das default nur der physische core ohne SMT getestet wird. Aber wenn ich nun meine CPU mit SMT verwende(was ja auch eine höhere Last erzeugt) ist es dann nicht auch logisch im tool auch 2 Threads einzustellen?

Andersrum. Standardmäßig wird auch bei aktiviertem Hyperthreading / SMT nur ein Thread pro Kern belastet, was für eine etwas höhere MHz-Zahl auf dem Kern sorgt, verglichen zu wie wenn man beide Threads des gleichen Kerns belasten würde. Du erreichst mit Belastung auf nur einem Thread also eher den Grenzbereich der Stabilität als mit zwei Threads.

(Und bei zwei Threads auf jeweils unterschiedlichen Kernen wird übrigens anscheinend immer der Takt des schlechteren Kerns auch auf den besseren gelegt.)

 

[Wan900]

Mich würde interessieren, ob bei Euch ein solches Verhalten nachvollzogen werden kann.

Ja hatte ich früher ebenfalls, beim Durchwechseln der einzelnen Benchmarks im Cinebench.

Bei mir war es aber kein kompletter Reboot, jedoch brach der Benchmark kurz vor Testbeginn mit einer Fehlermeldung (bugreport.txt) ab.
Müsste mal direkt nachgucken, was da drin stand.

Die Lösung hast du dir aber selbst schon geliefert. Deine CO Einstellungen sind nicht stabil.

 

[xxlhellknight]

Für die, die auch mit Stock Settings Kerne haben, die aussteigen: Ich habe bei mir die Global C-States deaktiviert, da ich auch einer von denen bin, die USB-Probleme haben und dies ja der Workaround hierfür ist, und siehe da: Prime Stand Alone lief die Nacht über ohne Fehler durch.

Give it a try!

Jup dann läufts durch, aber es liegen auch 100-150mhz weniger takt an.

 

[SuperSabo]

I know. Wobei es bei mir eher 25-50 weniger sind. Gibt doch aber Hoffnung auf den von AMD angekündigten Fix für die USB-Probleme, oder? RMA kann man ja dann immer noch machen wenn man möchte.

Edit: Hast du eigentlich auch USB-Probleme in Form von Disconnects?

 

[xxlhellknight]

I know. Wobei es bei mir eher 25-50 weniger sind. Gibt doch aber Hoffnung auf den von AMD angekündigten Fix für die USB-Probleme, oder? RMA kann man ja dann immer noch machen wenn man möchte.

Edit: Hast du eigentlich auch USB-Probleme in Form von Disconnects?

Hab über USB Maus, Tastatur(via Wireless Stick) und gamepad(via kabel) und intern 2x ne mp600 und 1x mp510 via m.2. Hab bis jetzt keine Probleme gehabt, egal an welchem Anschluss. Hab unter lasst und im idle auch sonst keine Probleme. Nur den rounding error wenn ich das Tool benutze.

 

[xxlhellknight]

Wie kann ich die provozieren bzw triggern.

 

[sp00n.82]

Lief vorher zwischen 2-30(negative). Mit prime95 single core small fft jeden kern 3 Stunden durchgetestet. Und mit dem Tool, wahrscheinlich wegen sse, stürzt prime95 auf core 3 selbst mit plus 1 ab.

Du kannst bei Prime95 auch manuell den SSE-Modus aktivieren, indem du die beiden AVX-Checkboxen deaktivierst.

 

[SeniorY]

ich kann den Testalgorhythmus von P95 nicht ganz nachvollziehen und frage mich, welche Testdauer pro Core bei Large FFTs Sinn machen würde.

 

[sp00n.82]

ich kann den Testalgorhythmus von P95 nicht ganz nachvollziehen und frage mich, welche Testdauer pro Core bei Large FFTs Sinn machen würde.

Ab einer bestimmten FFT-Größe scheint Prime95 da einen Zufallsgenerator für die Reihenfolge der getesteten FFT-Größe zu benutzen.
Ich hab mir jetzt ein weiteres Script geschrieben, mit dem ich jetzt nach und nach die einzelnen Logfiles analysieren kann.
Bei meinem 5900X und SSE/Large hab ich bisher das hier:

Also zwischen ~18 Minuten und ~22 Minuten für einen Durchlauf aller FFT-Größen bei SSE/Large.

Das kommt dann in die config.ini als Beispielwerte. Bisher hab ich folgendes:

Smallest FFT: [SSE] ~3-4 Minutes
Small FFT:    [SSE] ~4-6 Minutes
Large FFT:    [SSE] ~18-22 Minutes
Huge FFT:     [SSE] ~13-19 Minutes
All FFT:      [SSE] ~40-65 Minutes

 

[SeniorY]

das Tool hat mir gezeigt, dass mein ursprüngliches CO setting nicht Prime stabil war. Hatte zwar nie im Alltag/Gaming crashes, aber ich musste vor allem den besten Core ganz ordentlich nach unten anpassen.

Praktisch ist halt, dass das Tool die restlichen Cores weiter testet, wenn einer einen Fehler wirft.
Nach ca. 60h Prime95 hab ich meine CO vorerst gefunden. Gott sei Dank hab ich nur einen 8 Kerner

Interessant finde ich, dass die CO Werte nicht mit der Corereihenfolge von HWiNFO übereinstimmen.
Der beste Core verträgt am wenigsten Offset aber alle anderen halten sich nicht an diese "Regel".