CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

Habe den CC auf dem 10700kf@5GHz über Nacht mal laufen lassen.Kein einziger Fehler :daumen:.

Dank dem CC und etlichen Biosupdates konnte ich den 5800x jetzt nach 4 Monaten wohl stabil (nach Primestandards) bekommen wie es aussieht.Das Gemeine ist,dass selbst eine Veränderung des Skalar bei sonst identischem Bios einen CO Wert der vorher stabil war wieder instabil werden lassen kann.Dito natürlich auch LLC,EDC,TDC &PPT.Somit ergibt das mit den vielen Stellschrauben des Ryzen eine schier unendliche Arbeit um das "optimale" stabile Setup zu finden wenn eng mit den CO Werten gearbeitet wird.Eine schöne Beschäftigung für Leute die nichts Besseres mit der Zeit anzufangen wissen:D,zumal "optimal" in zweierlei Hinsicht ausgelegt werden kann,beste Effizienz,also nah an Werksvorgaben und deren Optimierung oder mit Ziel für max. Leistung und somit Auslotung der Kerne sowohl in Takt als auch Dauer des Taktes.
 
Den Effekt des PBO scalar bei Zen 3 habe ich bis heute nicht merken oder verstehen künnen. LLC hat bestimmt einen Einfluss, aber ich denke im single core eher negativ. Ob sich PPT,TDC,EDC auf die Stabilität auswirken, wage ich zu bezweifeln, da man hier so weit von den Limits entfernt ist? Aber klar sind das generell extrem wichtige Stellschrauben.
 
Die Cores die abstürzen entsprechen der Nummerierung im Asus Bios oder? Also wenn Fehler Core 9 ist das im Bios Core 9?
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Frohe Ostern!

Version 0.8.0.0 ist jetzt verfügbar.
Aida64 und Y-Cruncher werden nun unterstützt!


Download:
https://github.com/sp00n/corecycler/releases


Changelog:
  • Prime95 auf Version 30.5 Build 2 upgedatet
  • Aida64 und Y-Cruncher werden jetzt unterstützt! Man kann jetzt festlegen, welches Stresstest-Programm verwendet werden soll (Achtung: lest den entsprechenden Abschnitt zu Aida64 in der readme.txt)
  • Die config.ini wurde restrukturiert, um Aida64 und Y-Cruncher zu unterstützen. Alte Config-Dateien funktionieren nun nicht mehr!
  • Eine Einstellung "suspendPeriodically" hinzugefügt, die standardmäßig aktiv ist. Mit dieser Einstellung wird das Stresstest-Programm in regelmäßigen Abständen pausiert und wieder fortgesetzt, um Lastwechsel zu simulieren
  • Eine Einstellung "coreTestOrder" hinzugefügt, die standardmäßig "Alternate" (für CPUs mit mehr als 8 Kernen/2 CCDs) bzw. "Random" (für max. 8 Kerne/1 CCD) gesetzt ist. Man kann aber auch eine komplett benutzerdefinierte Reihenfolge eingeben, in der die Kerne getestet werden sollen (z.B. "5, 7, 5, 1, 0, 7, 4")
  • Mehrere neue Presets für Prime95 hinzugefügt: "Moderate", "Heavy" & "HeavyShort". In der Config-Datei stehen mehr Infos zu diesen Presets
  • Die Priorität des Stresstest-Programms wird jetzt auf "Hoch" gesetzt, damit ihm andere Prozesse nicht Prozessorzeit "klauen" können, was anderenfalls zu Fehlalarmen bei der Erkennung der Prozessorauslastung führen könnte
  • Der Start eines Stresstest-Programms stiehlt nun nicht mehr den Fokus des gerade offenen Fensters (bzw. gibt ihn sofort wieder zurück)
  • Beim Drücken von STRG+C versucht das Script nun, das laufende Stresstest-Programm ebenfalls zu beenden (sofern es noch CPU-Auslastung verursacht)
  • Der Titel des Fenster wird nun auf "CoreCycler" gesetzt
  • Die ungefähre Prozessorgeschwindigkeit wird nun in den Verbose-Logs ausgegeben (leider ist der Wert nicht so genau wie z.B. HWInfo64 oder Ryzen Master, weswegen er auch nicht in der normalen Ausgabe erscheint)
  • Alle Logdateien landen nun im /logs Ordner, nicht mehr verteilt über mehrere Ordner
  • Im /tools Ordner gibt es nun eine "analyze_prime95_logfile.ps1"-Datei, mit der man ermitteln kann, wie lange Prime95 für einen kompletten Durchlauf aller FFT-Größen gebraucht hat
  • "CoreTunerX" befindet sich nun im /tools Ordner. Mehr Infos zu CoreTuneX und für was es gut ist finden sich hier: https://github.com/CXWorld/CoreTunerX
 
  • Gefällt mir
Reaktionen: AthlonXP, Asghan, kodix und 7 andere
Hammer! Dir auch frohe Ostern!
 
Danke @sp00n.82 für das Update. Eine entsprechende Meldung wird morgen auf der Startseite zu finden sein, bin schon dran!

Liebe Grüße & frohe Ostern euch allen!

Sven
 
  • Gefällt mir
Reaktionen: bierbuddha und sp00n.82
Geniales Tool.
Bin gerade dabei, alle Cores bei meinem 5900X auszuloten :-)

Frohe Ostern!
 
Bei mir ist das Tool bzw der Rechner abgestürzt und im Log sah ich folgende Meldung.
Ist das richtig ?

13:00:41 - Set to Core 11 (CPU 22)
+ Setting the affinity to 4194304
+ Successfully set the affinity to 4194304
Running for 6 minutes...

dann endet das Log File.

PBO steht auf Advanced und Curve Optimizer steht auf All Cores negativ 15.

ROG Strix X570-F Gaming

AMD Ryzen 9 5900X
 
ATBler schrieb:
Bei mir ist das Tool bzw der Rechner abgestürzt und im Log sah ich folgende Meldung.
Ist das richtig ?

13:00:41 - Set to Core 11 (CPU 22)
+ Setting the affinity to 4194304
+ Successfully set the affinity to 4194304
Running for 6 minutes...

dann endet das Log File.
Wenn der Rechner abstürzt, dürfte der Negativwert einfach zu hoch gesetzt sein. In dem Fall halt bei Core 11.
Bei Komplettabstürzen ist der Wert in der Regel noch um einiges zu weit im Negativen, wenn man näher am stabilen Setting ist kommen dann nur noch "FATAL ERROR"s im Log von Prime95.

Wobei mit y-Cruncher bei mir auch direkt der Computer neu gebootet hat bei meinen Tests mit viel zu instabilen Werten. Entweder das oder es ist durchgelaufen. Prime95 scheint da da eher erst mal einen Fehler zu werfen und nicht direkt den ganzen Rechner mitzureißen. Wobei auch das vorkommt, wenn der Wert sehr instabil ist.
 
heijck schrieb:
Könnte man den CO nicht auch so programmieren, das er bei beiden CCD'S, soweit vorhanden, jeweils einen Kern gleichzeitig getestet?

Zwei Bugs sind mir auch aufgefallen.
Wenn man die Reihenfolge selber festlegt, dann wird der letzte Kern nicht getestet.
Und wenn man die Reihenfolge auf Alternate setzt, dann testet er die Cores der Reihe nach ab, aber wechselt nicht die CCDs zwischen den Tests. Oder ist dieses Verhalten richtig?
Ich hole das mal hier in den Thread, um das gebündelt zu haben.

Das mit zwei Kernen gleichzeitig hatte ich mal ausprobiert, allerdings wird da der Takt des besseren Kerns an den des schlechteren angepasst, es hat sich also leider als relativ sinnfrei herausgestellt.

Die Bugs konnte ich bei mir auch nicht reproduzieren, wenn du die entsprechende Log-Datei noch hast, könnte ich mir die mal ansehen.
Bei "Alternate" wird bei mir am 12-Kerner korrekt Core 0, 6, 1, 7, ... durchgelaufen. Beim 5950x mit 16 Kernen müsste das dann entsprechend 0, 8, 1, 9... sein.
Auch die Custom-Reihenfolge funktioniert bei mir. Zwei Sachen könnte ich mir da evtl. vorstellen:
  • der letzte Kern hat zuvor einen Fehler geworfen, und mit skipCoreOnError, was standardmäßig auf 1 gesetzt ist, wird ein solcher Kern beim nächsten Durchlauf übersprungen
  • evtl. wurde der 16. Kern als "16" eingetragen. Da die Zählung aber mit 0 beginnt, ist der letzte Kern dementsprechend die 15.

Aber wie gesagt, mit der Logdatei könnte ich vermutlich mehr sagen.
 
sp00n.82 schrieb:
Ich hole das mal hier in den Thread, um das gebündelt zu haben.

Das mit zwei Kernen gleichzeitig hatte ich mal ausprobiert, allerdings wird da der Takt des besseren Kerns an den des schlechteren angepasst, es hat sich also leider als relativ sinnfrei herausgestellt.

Die Bugs konnte ich bei mir auch nicht reproduzieren, wenn du die entsprechende Log-Datei noch hast, könnte ich mir die mal ansehen.
Bei "Alternate" wird bei mir am 12-Kerner korrekt Core 0, 6, 1, 7, ... durchgelaufen. Beim 5950x mit 16 Kernen müsste das dann entsprechend 0, 8, 1, 9... sein.
Auch die Custom-Reihenfolge funktioniert bei mir. Zwei Sachen könnte ich mir da evtl. vorstellen:
  • der letzte Kern hat zuvor einen Fehler geworfen, und mit skipCoreOnError, was standardmäßig auf 1 gesetzt ist, wird ein solcher Kern beim nächsten Durchlauf übersprungen
  • evtl. wurde der 16. Kern als "16" eingetragen. Da die Zählung aber mit 0 beginnt, ist der letzte Kern dementsprechend die 15.

Aber wie gesagt, mit der Logdatei könnte ich vermutlich mehr sagen.

Besten Dank für deine Antwort!

Schade das es Sinnfrei ist :/ der Zeitaufwand is ja nicht gering, aber wenn es so ist, dann ist es so.

Die Logs liefer ich dir am Mittwoch nach, bin vorher nicht an meinem PC.
 
So, anbei die Logs.

Edit: Gibt es die Möglichkeit, das wenn ich die 'Run CoreCycler.bat' über die Konsole aufrufe, nicht eine neue geöffnet wird?
 

Anhänge

Zuletzt bearbeitet: (Logs als *.txt hinzu)
heijck schrieb:
So, anbei die Logs.

Edit: Gibt es die Möglichkeit, das wenn ich die 'Run CoreCycler.bat' über die Konsole aufrufe, nicht eine neue geöffnet wird?
Primär wäre ich an den Logs von CoreCycler selbst interessiert, an den Prime-Logs kann ich nur ablesen, dass Prime bei dir Fehler geworfen hat. 😬
Die sollten auch im /logs-Verzeichnis liegen und halt mit CoreCycler beginnen.

Mit mit dem neu öffnendem Fenster bin ich auch nicht ganz glücklich, aber das ist die Kröte, die ich schlucken musste, damit ich die "Terminating Script"-Funktionalität bei CTRL+C korrekt umsetzen konnte. Zumindest habe ich keinen anderen Weg finden können.
 
Nachdem MSI vor ein paar Tagen ein neues Beta-BIOS inkl. USB-Fix für mein X570 Tomahawk gebracht hat wollte ich nach dessen Installation nun auch endlich mal den CoreCycler laufen lassen. Dummerweise bricht der aber leider direkt mit folgender Fehlermeldung ab:
1618757146386.png

Weiß jemand, wie man das behebt?
 
ah sorry, die FAQ am Ende hab ich ganz übersehen ^^ wobei das Problem schlussendlich nicht der deaktivierte Performance Process Counter war, sondern dass ich das .bat-File nicht als Admin ausgeführt habe. Sobald ich das mache bekomme ich aber einen anderen Fehler:
1618769247399.png

Was läuft da wieder falsch?
 
Musste ich jetzt selber ausprobieren. Die Run CoreCycler.bat einfach als nicht-Administrator starten, dann funktioniert es auch. Als Admin kommt ansonsten die obige Fehlermeldung.

Die enable_performance_counter.bat im /tools Ordner muss aber natürlich als Admin ausgeführt werden. Das sollte aber eigentlich auch als Fehler ausgegeben werden, wenn das nicht der Fall ist.
 
In der nächsten Version sollte das dann auch als Admin funktionieren.
Wenn man "Als Admin starten" auswählt, wird anscheinend das aktuelle Arbeitsverzeichnis auf Windows/system32 gesetzt anstatt das Verzeichnis der .bat-Datei. Dann findet er natürlich keine relativen Dateiangaben mehr.
Ergänzung ()

Wer die neue Version mit der Möglichkeit zur automatischen runtimePerCore schon ausprobieren möchte, v0.8.1.0 RC5 gibts hier: https://github.com/sp00n/corecycler/releases/tag/v0.8.1.0-RC5

Wenn nichts mehr dazwischen kommt, sollte das dann auch demnächst die finale 0.8.1.0 werden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: AthlonXP, Baal Netbeck und SuperSabo
Zurück
Oben