CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

sp00n.82 schrieb:
Bei den jetzt standardmäßig auf "Huge" eingestellten FFT-Größen dauert das mit seinen 30 Einträgen im SSE-Modus (bei AVX sind es 29, bei AVX2 35) dann also rund 30 Minuten, bis ein kompletter Durchlauf geschafft wurde. Ist jetzt aber restartPrimeForEachCore auf 1 gesetzt und die runtimePerCore bleibt auf den standardmäßigen 6 Minuten, dann werden nicht alle FFTs getestet, sondern nur das, was innerhalb der 6 Minuten reinpasst.

Also muss bei einer Laufzeit von 6 Minuten jeder Kern mindestens 5 Wiederholungen durchmachen, damit alle Tests durch sind, verstehe ich das richtig? Wäre es dann icht einfacher, die Test dauer pro Kern auf 30 Minuten zu stellen?
 
Theoretisch ja. Die 6 Minuten hatte ich mir als Default-Wert ausgesucht für die Small FFT, die bei mir ungefähr 5,x Minuten gebraucht haben für einen kompletten Durchlauf.
Bei 30 Minuten stellt sich dann natürlich wieder die Frage, ob der Wert nicht zu groß ist, um alle Kerne wenigstens ein Mal durchgecheckt zu haben (bei 12 Kernen wären das immerhin 6 Stunden).
Wie immer ist das alles ein Kompromiss. Meine Runs mache ich meistens mit 10-20 Minuten pro Kern über Nacht.
 
  • Gefällt mir
Reaktionen: robinps215@gmai
sp00n.82 schrieb:
Theoretisch ja. Die 6 Minuten hatte ich mir als Default-Wert ausgesucht für die Small FFT, die bei mir ungefähr 5,x Minuten gebraucht haben für einen kompletten Durchlauf.
Bei 30 Minuten stellt sich dann natürlich wieder die Frage, ob der Wert nicht zu groß ist, um alle Kerne wenigstens ein Mal durchgecheckt zu haben (bei 12 Kernen wären das immerhin 6 Stunden).
Wie immer ist das alles ein Kompromiss. Meine Runs mache ich meistens mit 10-20 Minuten pro Kern über Nacht.

Ich denke ich werde jetzt "restartPrimeForEachCore" aktivieren, die "runtimePerCore" auf ~30 Minuten stellen und über Nacht laufen lassen, somit müsste jeder Kern meines 5950X einen kompletten "huge" Prime run innerhalb von 8 Stunden durchlaufen.

Edit: Gesagt, getan. Hier mal meine derzeitigen Ergebnisse, Kern 6 noch auf -25 und ich sollte mit dem groben Tuning vorerst fertig sein. Leider lässt das Bios meines Dark Hero nur ein maximales offset von -30 zu, wenn ich mir CCD2 ansehe, würde da eventuell noch mehr gehen. Vielen dank für das geniale Tool!
 

Anhänge

  • curve ergebniss.png
    curve ergebniss.png
    228 KB · Aufrufe: 486
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sp00n.82
robinps215@gmai schrieb:
Leider lässt das Bios meines Dark Hero nur ein maximales offset von -30 zu, wenn ich mir CCD2 ansehe, würde da eventuell noch mehr gehen. Vielen dank für das geniale Tool!
Gibt es denn irgendein Board, das mehr als -30 zulässt?
Alternativ könntest du auch den Additional Boost Override noch erhöhen. Mit +200 MHz hatte ich da massiv schlechtere Werte beim Curve Optimizer als mit +0.

// Edit
Mit den 30 Minuten pro Core hast du allerdings auch erst ein 24igstel eines "12h prime stable"-Setup erreicht. 😀
 
Gibt ältere AGESA-Versionen die mehr als -30 zulassen.
 
Ich hatte davor ein Aorus Master Board und da ging definitiv mehr als -30, aber ja, war auch eine ältere AGESA-Version.

Mein Plan ist jetzt erstmal bei jedem Kern exakt den Wert herauszufiltern, bei dem bei einem 30 Minuten run ein Error auftritt, dann einen Punkt zurück und sollte ich mal reboots bekommen einfach überall noch einen Punkt zurück. Jeden Kern 12h zu testen ist mir dann doch zu viel Aufwand. 😅

Edit: Additional Boost Override ist bereits auf +200Mhz.
 
Zuletzt bearbeitet:
robinps215@gmai schrieb:
Edit: Additional Boost Override ist bereits auf +200Mhz.
😱
Mit +0 sieht das bei mir so aus:
1615738648623.png


Klar, der 5950x hat in der Regel nochmal eine höhere Qualität, aber das ist schon heftig, -30 bei +200 Mhz auf so vielen Kernen.
 
sp00n.82 schrieb:
Klar, der 5950x hat in der Regel nochmal eine höhere Qualität, aber das ist schon heftig, -30 bei +200 Mhz auf so vielen Kernen.

Ja, aber dafür haben diese Kerne ohne offset nur auf etwa 4800-4850Mhz geboostet, jetzt bis 5000-5050Mhz. Diesen boost Takt haben manche schon standardmäßig.
 
Zuletzt bearbeitet:
Man kann auch den Vcore Offset reduzieren, wenn so viele Kerne die -30 schaffen.

Hatte ich auch anfänglich, jedoch muss ich dann meinen Core 0 auf +3 stellen. Bringt dadurch bei Multicorelast nicht mehr wirklich was, weil Core 0 begrenzt.
 
wegdra schrieb:
Man kann auch den Vcore Offset reduzieren, wenn so viele Kerne die -30 schaffen.

Hatte ich auch anfänglich, jedoch muss ich dann meinen Core 0 auf +3 stellen. Bringt dadurch bei Multicorelast nicht mehr wirklich was, weil Core 0 begrenzt.
Bei meinem MSI Tomahawk X570 geht das nicht zusammen, stellt man was am Vcore um, wird der automatische Boost und damit auch PBO deaktiviert. Zumindest mit dem letzten offiziellen BIOS, Betas hab ich seitdem nicht ausprobiert.
 
Möchte jemand Betatester für die nächste Version mit Unterstützung von Aida64 und Y-Cruncher spielen? ➡️ PM an mich.

Aida64 ist allerdings etwas sketchy, es mag nicht auf Core 0 CPU 0 laufen (also Thread 1 auf dem ersten Kern), auf Core 0 CPU 1 (Thread 2) läuft es dagegen. Deswegen habe ich da eine Erkennung eingebaut, die beim ersten Kern auf den zweiten Thread wechselt. Ich vermute, das ist so hardcoded, damit zumindest ein Kern weiterhin ansprechbar bleibt.
Außerdem läuft bei Aida der Stresstest über eine .dll und nicht über die .exe direkt, was die Erkennung etwas schwerer macht, und man benötigt die Portable Engineer Version, da man die normale Extreme-Edition nicht über die Kommandozeile direkt in den Stresstest starten kann. Uuund aufgrund der Lizenz muss Aida auch eigenhändig heruntergeladen und in den entsprechenden Ordner entpackt werden (/test_programs/aida64)

Y-Cruncher läuft dagegen relativ problemlos, nur habe ich bisher keine Möglichkeit gefunden, eine Logdatei von dessen Output anzulegen. Eine Option für ein Logfile habe ich nicht gefunden und es ist zwar auch ein Kommandozeilenprogramm, aber > logfile.txt 2>&1 mag es trotzdem nicht. 🤷‍♂️
 
Zuletzt bearbeitet:
@sp00n.82 Sehr cool. Sieht so aus, dass mein 5950x komplett mit stock bios settings (ohne XMP etc) ohne chipset treiber nicht prime-stable ist. Wenn ich die ich die global c-states deaktiviere, dann schon.

Zum Thema Y-Cruncher: Ich habe damit viel manuell getestet. Besonders die Tests 15 und 16 (N32,N64) haben am schnellsten Fehler gezeigt. Eine andere richtig gute Methode warm einfach PI single threaded zu berechnen. Zu niedrige CO werte haben hier auch schnell zu Fehlern gefuehrt (sequenz 0-0-5 zum Beispiel, oder kommandozeile y-cruncher skip-warnings bench 500m).

Ich glaube als logfiles kann man die validation files verwenden, die angelegt werden, allerdings nur wenn es keine Fehler gab und nicht im stress-test modus. Keine Ahnung wie man den kompletten Output loggen kann.
 
  • Gefällt mir
Reaktionen: SuperSabo
Erstmal danke für das Supertool,dass einem erheblich Arbeit abnimmt und die Problemsuche eingrenzt.

Habe einen Core der einen positiven Offset braucht bei einem sehr moderatem OC (+25MHz),den ich vorher gar nicht so arg auf dem Schirm hatte und der bei 0 stand.Bisher ging ich eigentlich davon aus ,dass 0 praktisch save ist wenn man es mit dem PBO nicht übertreibt.Werde das mal jetzt bei PBO an aber ohne Override gegenprüfen,das sollte zumindest keinen positiven Offset brauchen.Der eine Kern limitiert natürlich erheblich die Möglichkeiten wenn es schon so früh dazwischenfunkt.

Sonst noch wer?
 
Meine Curve sieht bei +50MHz aktuell so aus. Leider müssen da 3 Kerne ins + damit es 100% Prime stabil wird.
Screenshot 2021-03-21 112905.png

muss mal testen ob sie bei +0Mhz auch noch ins + müssen.
 
Interessant,dass bei dir auch eher die "besseren" Kerne mehr Saft brauchen.Bezüglich Hitze/Performance habe ich jetzt keinen Nachteil feststellen können wegen dem +Offset.Im Gegenteil,die bessere mögliche Optimierung der Kerne (zumindest primestable) spiegelt sich positiv in den Benchmarkwerten.
 
Bei meinem 5950x sind es die zwei besten Cores des CCX 0, die ein positives Offset benötigen (momentan +5 und +8). Weiteres Testen steht noch aus. Habe alle BIOS Versionen für mein Board getestet und das macht keinen Unterschied. Erst mit einem positiven V-Core Offset von 0.0250 V läuft P95 mit stock BIOS Einstellungen fehlerfrei. Mein Sample hat diese Produktionsdaten: 2046SUS (woche 46, 2020). Bin jetzt hart am überlegen ob ich reklamiere, da ich keine andere AM4 CPU habe..
 
Hmm meinst du das liegt an der CPU?Bzw. hast du welche Nachteile feststellen können wegen dem +Offset?Bei mir ist es auch einer der besten Kerne der +4 braucht bei PBO+25MHz.
 
Ja, der RAM wird hier nicht gestresst (und läuft auch nur mit 2133 Mhz @ stock).
Wenn ich das richtig verstehe, dann fuehrt ein negatives offset zu geringerer Wärmeentwicklung und Leistungsaufnahme und damit zu höheren boost clocks, oder dazu dass ein hoher boost länger gehalten wird.

Es gibt ein kleines Tool: "Boost-Tester", das eine minimale Belastung abwechselnd auf einen Kern anlegt. Damit kann man den maximalen Boost pro Kern recht gut auslesen. Ich habe kein AutoOC / Boost-Override eingestellt. Core 1 mit +8 im CO boostet nicht mehr auf 5Ghz. Ich denke, das kann man nur in synthetischen Benchmarks messen und ist eigentlich total egal.

Finde es dennoch unakzeptabel, dass die CPU mit stock settings nicht 100% stabil läuft.
 

Anhänge

  • Capture.PNG
    Capture.PNG
    61,7 KB · Aufrufe: 326
aanti schrieb:
Finde es dennoch unakzeptabel, dass die CPU mit stock settings nicht 100% stabil läuft.
Stimmt,das sollte wirklich nicht sein.Leider kann man da nicht 100% sicher sein ob es an der CPU liegt oder dem MB.

PS:Mein 5800x schafft auch auf allen Kernen 5GHz+ und man kann damit zocken oder benchmarken aber stabil ist das leider nicht.
 
Zurück
Oben