CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

@sp00n.82 Schön das du das erläutert hast ich wusste nicht das es da so viele verschiedene Versionen gibt.
Ich kannte bisher nur diese Version
Unbenannt.png

Die wurde mir von @MehlstaubtheCat vor einiger Zeit einmal vorgestellt.
Ich habe damit RAM Benchmarks gemacht um verschiedene Timings zu testen das dauerte immer nur wenige Minuten.
Dieser Benchmark ist wirklich EXTREM Fordernd!
Er ist auch der Einzige Benchmark der meine CPU 5800x3D wirklich an die 140W marke heran gebracht hat. Dabei waren die Temperaturen sofort Anschlag 90°C wie gesagt der Test selbst läuft nur wenige Minuten.
Ich kann mir beim besten willen aber nicht vorstellen das es gut für eine CPU sein kann diesen Benchmark über viele Stunden via CoreCycler zu betreiben (ausgenommen man nutzt dabei nur wenige Kerne) Vielleicht.

Es ist schon so wie @MehlstaubtheCat es oben erwähnt hat.
MehlstaubtheCat schrieb:
Linpack Xtreme > Intel Linpack

Hab es schon mehrfach getestet, das "Extreme" haut mehr rein.
Es spielt in einer ganz anderen Liga als Prime95 oder y-Cruncher!
Wie es sich auf Intel CPUs verhält kann ich nicht sagen aber für AMD ist es in meinen Augen Overkill.
Darum würde ich es nicht Empfehlen es über längere Zeit einzusetzen.

Wenn es davon mittlerweile abgeschwächte Versionen gibt solls recht sein :)


 
@BreadPit
Hast du gerade ein Beispiel parat für so einen Error, der von CoreCycler nicht erkannt wurde?
Generell wird ja mittlerweile die Ausgabe von y-Cruncher abgefangen, ausgewertet und als Log-Datei gespeichert, da sollte eigentlich nichts mehr durchrutschen.
Die coreTestOrder explizit zu setzen hat den Nachteil, dass CPUs mit mehr oder weniger Kernen dann nicht korrekt getestet werden. Das ist bei einer Config nur für einen CPU-Typ (wie den 5800X3D) nicht von Belang, für eine eher allgemein gehaltene aber schon.

@4BitDitherBayer
Ja, genau das Tool. Das ist im Prinzip nur ein Wrapper für eine .bat Datei, die man während der Ausführung im Temp-Verzeichnis finden kann, und die dann die entsprechenden Umgebungsvariablen und Einstellungen für die Linpack exe bereit stellt. In dem bereits erwähnten Thread bei Techpowerup hatte ich auch den Inhalt der Batch-Datei gepostet (und an neuere Versionen von Win11 angepasst, auf denen Linpack Xtreme nicht mehr läuft, weil Microsoft ein dort verwendetes Kommandozeilentool rausgeschmissen hat (wmic)).

Linpack (Xtreme) ist natürlich fordernd, aber ich fand jetzt auch nicht unbedingt mehr als z.B. Prime95 AVX2 mit Smallest FFT. Das heizt die CPU auch bis ans Temp-Limit.
Und bei nur 1-2 Threads geht es natürlich auch nicht so hoch wie bei einer Auslastung von allen Kernen.
 
  • Gefällt mir
Reaktionen: BreadPit, Fas7play, AthlonXP und eine weitere Person
sp00n.82 schrieb:
Hab jetzt ein Bugfix-Release rausgebracht, um das Problem mit den nicht erkannten Tests bei YCRUNCHER_OLD zu beheben:
Funktioniert nun :)
Danke für die kontinuierliche Weiterentwicklung!
 
  • Gefällt mir
Reaktionen: BreadPit und sp00n.82
sp00n.82 schrieb:
@BreadPit
Hast du gerade ein Beispiel parat für so einen Error, der von CoreCycler nicht erkannt wurde?
Nein war ja unter 0.9.4.2 oder früher
sp00n.82 schrieb:
Generell wird ja mittlerweile die Ausgabe von y-Cruncher abgefangen, ausgewertet und als Log-Datei gespeichert, da sollte eigentlich nichts mehr durchrutschen.
Perfekt, das bestätigt was ich verstanden habe - das einer der zentralen Mehrwerte von CC 0.9.5.x, dass jetzt eben Y-cruncher Outputs ausgelesen werden und das nicht mehr passieren kann. Perfekt, danke!
sp00n.82 schrieb:
Die coreTestOrder explizit zu setzen hat den Nachteil, dass CPUs mit mehr oder weniger Kernen dann nicht korrekt getestet werden. Das ist bei einer Config nur für einen CPU-Typ (wie den 5800X3D) nicht von Belang, für eine eher allgemein gehaltene aber schon.
Guter Punkt, könnte ein unbedarfte neuer User übersehen, va wenn man die Konfigs als Vorlage zur Auswahl anbietet.

Super Weiterentwicklungen jedenfalls!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sp00n.82
Kein wirklicher Bug, aber als info sinnvoll.
Wenn man beim testen über Prime, die Windows 11 Skalierung ändert, ja beim testen sollte man den pc am besten alleine lassen :D. Dann erhält man den Fehler "- The Prime95 process doesn't use enough CPU power anymore (only 0ms instead of the expected 2000ms)"
Indemfall ist es keine instabilität und der Kern wird halt nicht weiter getestet. Man muss also den Test neustarten.

1721287529947.png
 
  • Gefällt mir
Reaktionen: sp00n.82 und AthlonXP
Die Skalierung ändert. Das muss ich mal nachstellen 😁

So etwas hatte ich, wenn ich per Remote Desktop Connection auf einen Computer verbinde, auf dem gerade ein Test läuft. Allerdings wird da nur der gerade getestete Kern beeinflusst, die anderen laufen dann wieder normal.
Und laut Task Manager wird da auch tatsächlich der Stress Test gestoppt (bzw. eben die Auslastung). Warum, weiß wohl nur Microsoft. Mal sehen, wie das bei der Skalierung ist.


// Edit
Also ich habe das jetzt mal ausprobiert und von 100% auf 125% auf 150% und wieder zurück gewechselt, aber ohne Probleme. Was genau hattest du denn gemacht @Ragnador? 🤔
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sp00n.82
Solange sich an den Binaries und an den Tests nichts ändert, kann man das selbst updaten.
Die Tests habe sich allerdings (nochmals) geändert seit dem letzten Release von CoreCycler, diese würden also nicht erkannt.
Aber da die neue Version jetzt anscheinend die Zen5-Optimierungen beinhaltet, kann ich die auch ins nächste Update mit aufnehmen.
 
  • Gefällt mir
Reaktionen: BreadPit und AthlonXP
Hab nen Release Candidat für 0.9.6.0, könnte durchaus Tester gebrauchen, da ein paar Sachen neu sind. Darunter
  • y-cruncher in der neuesten Version (und mit den neuen Tests FFTv4 und SFTv4)
  • Linpack in verschiedenen Versionen (2018, 2019, 2021 und 2024)
  • config-Dateien können jetzt geladen werden
  • die config-Dateien sind im /configs/ Verzeichnis (die default.config.ini ist jetzt auch dort)
  • ein Update-Check, der über neue Versionen informiert (in der RC-Version wird der absichtlich immer angezeigt)

https://github.com/sp00n/corecycler/archive/refs/heads/development.zip
 
  • Gefällt mir
Reaktionen: Tanzmusikus, BreadPit und AthlonXP
Funktioniert so weit sehr gut bei mir, und hat mich schon erkennen lassen dass ich 4 Cores nachjustieren musste ;)

Auch die Windows Eventlog Integration find ich super, funktioniert aber nur bei "soft errors". Bei mir gibts meistens durch yCruncher HNT ausgelöste Resets, da ist im Corecycler Eventlog nichts, da muss man dann einfach auf WHEA 18 filtern, dann sieht mans sofort. Oder halt im CoreCycler & yCruncher Log, die auch sehr ausführlich sind ung gut zeigen, welcher Core & Test vor dem Reboot dran waren.
 
Version 0.9.6.0 0.9.6.1 ist jetzt draußen, @BreadPit und @LuxSkywalker haben dankenswerterweise als Versuchskaninchen gedient. 😋

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

  • Added a new useConfigFile setting, which allows you to quickly change between various config files
    • Some predefined config files are available in the /configs/ directory
    • This also inlcudes the default.config.ini file, which has been moved there from the main directory
  • Updated y-cruncher to v0.8.5.9543, which includes the new Zen 5 (Ryzen 9000) optimizations
    • It also introduces two new tests (SFTv4 and FFTv4)
  • Included Linpack as a new stress test program. Use LINPACK in the stressTestProgram setting to activate it
    • Settings for it can be found in the [Linpack] section
    • Linpack includes four different versions (2018, 2019, 2021, 2024) and five different test modes (SLOWEST, SLOW, MEDIUM, FAST, FASTEST)
    • SLOW to MEDIUM modes are some variation of SSE and FMA instructions (unclear which exactly), while FAST uses AVX, and FASTEST AVX2 instructions
    • Only for version 2018 and 2019 you can set the mode, anything newer (2021 and 2024) automatically defaults to FASTEST without any way to change it
    • Version 2018 is the Linpack binary that is also used in Linpack Xtreme 1.1.5
  • There's now an update check, which will inform you if there's a new version available
    • It can be configured with the enableUpdateCheck and updateCheckFrequency settings in the [Update] section
  • Some additional debug output and new fancy boxes
  • General bug fixes
  • 0.9.6.0 included a debug exit for Linpack, which I forgot to remove
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SyntaX, nap, Flash_Muc und 7 andere
Tolles Update. Danke. Funktioniert bislang super. Das Laden der Config Dateien ist gut gelöst. Das Bearbeiten der Config Dateien ist viel übersichtlicher als die gesamte Config jedes Mal zu öffnen und zu bearbeiten für die Auswahl der Tests. Weiter so :)
 
  • Gefällt mir
Reaktionen: BreadPit und sp00n.82
-edit-
oh sry mit whea 19 verwechselt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BreadPit
Nein, was Du meinst ist WHEA 19, das sind die typischen IF Fehler durch RAM-OC. WHEA 18 ist Cores / vCore / CO.
 
  • Gefällt mir
Reaktionen: 4BitDitherBayer und Ragnador
BreadPit schrieb:
@sp00n.82 finde ich eine super Idee, wenn da gleich solide Stresstest-Empfehlungen inkl König mitkommen. Man kann sich dann immer noch selber einlesen, muss aber nicht, denn man kann auf empirisch gesammelte Community-Erfahrung setzen.

Hier meine "5800X3D-Community-proven" Empfehlungen 😉, kannst Du gerne übernehmen.

Bei mir war ja ausgerechnet HNT der Test, der idR den Rechner in die Knie bzw zum Reset gezwungen hat, bei @MehlstaubtheCat @Creekgroundund @fas7play waren es N64 oder VST / C17. Deshalb hab ich jetzt 2 Varianten
  • die alte Konfig übertragen auf die neue CoreCycler Version mittels YCRUNCHER_OLD, mit HNT, N64, VST, C17
  • die neue Konfig mit N63 und VT3, was den Prozess vereinfacht / verkürzt, wo mir aber Erfahrungswerte fehlen.
Hier mein Konfigs:

[General]
# General settings
stressTestProgram = YCRUNCHER
stopOnError = 0
skipCoreOnError = 1
numberOfThreads = 2

coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
runtimePerCore = 128s
# runtimePerCore = 32s --> Quick check N63
# runtimePerCore = 128s --> Medium check N63 + VT3
# runtimePerCore = 256s --> Full Final Check overnight N63 + VT3
restartTestProgramForEachCore = 0
# restartTestProgramForEachCore = 0 is default, and leaves the Y-Cruncher window open so you can scroll thru to check for errors; 1=enabled leads to not seeing errors in the Y-Cruncher test window as it restarts with each core
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
beepOnError = 1
flashOnError = 1
lookForWheaErrors = 1

[yCruncher]
# y-Cruncher specific settings
mode = 19-ZN2 ~ Kagari
tests = N63, VT3
# tests = N63 --> Quick check N63
# tests = N63, VT3 --> Medium check N63 + VT3
# tests = N63, VT3 --> Full Final Check overnight N63 + VT3
# tests = BKT, BBP, SFT, SNT, SVT, FFT, N63, VT3 --> all tests

[Logging]
name = CoreCycler
logLevel = 2
useWindowsEventLog = 1

[Debug]
delayFirstErrorCheck = 5
# With this setting you can define a wait time before the first error check happens for each core
stressTestProgramWindowToForeground = 0
# 1 throws an error "window cannot be found" in 0.9.4.2

[General]
# General settings
stressTestProgram = YCRUNCHER_OLD
stopOnError = 0
skipCoreOnError = 1
numberOfThreads = 2

coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
runtimePerCore = 192s
# runtimePerCore = 32s --> Quick check HNT
# runtimePerCore = 128s --> Medium check HNT + C17
# runtimePerCore = 192s --> Medium check HNT + VST + C17
# runtimePerCore = 256s --> Full Final Check overnight N64, HNT, VST, C17
restartTestProgramForEachCore = 0
# restartTestProgramForEachCore = 0 is default, and leaves the Y-Cruncher window open so you can scroll thru to check for errors; 1=enabled leads to not seeing errors in the Y-Cruncher test window as it restarts with each core
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
beepOnError = 1
flashOnError = 1
lookForWheaErrors = 1

[yCruncher]
# y-Cruncher specific settings
mode = 19-ZN2 ~ Kagari
tests = HNT, VST, C17
# tests = HNT --> Quick check HNT
# tests = HNT, C17 --> Medium check HNT + C17
# tests = HNT, VST, C17 --> Medium check HNT + VST + C17
# tests = N64, HNT, VST, C17 --> Full Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17 --> all tests

[Logging]
name = CoreCycler
logLevel = 2
useWindowsEventLog = 1

[Debug]
delayFirstErrorCheck = 5
# With this setting you can define a wait time before the first error check happens for each core
stressTestProgramWindowToForeground = 0
# 1 throws an error "window cannot be found" in 0.9.4.2
Ich kann auch empfehlen, mal mit der "Old" Konfiguration gegen zu testen. Mein Setting für den 5800X war Prime95, ycruncher sowie Alltagsstabil für zwei Wochen, aber beim HNT Test sind Kerne ausgestiegen. Inwiefern das jetzt Aussagekräftig ist kann ich nicht sagen aber instabil bei einem der vielen Tests ist halt nicht 100% stabil.
Bei den Tests BKT, BBP, SFT, SNT, SVT, FFT, N63, VT3 gab es zuvor gar keine Fehler.
 
  • Gefällt mir
Reaktionen: BreadPit und LuxSkywalker
Ich hab jetzt die alpha1 für Version 0.10.0.0 gepusht.
Die beinhaltet den automatischen Testmodus, der die Curve Optimizer-Werte (oder den Voltage Offset bei Intel) bei einem Fehler automatisch verringert.
Ebenso kann sich das Script jetzt nach einem Reboot von selbst neu starten, den CO/Offset-Wert verringern und bei dem Kern weitermachen, bei dem der Crash aufgetreten ist.
Damit sollte dann z.B. ein Lauf über Nacht deutlich effektiver sein.

Das Neustarten nach einem Reboot funktioniert über einen Scheduled Task beim nächsten Logon des Benutzers, für ein wirkliches "AFK"-Testen müsste man also den Autologon für den aktuellen Benutzer einrichten (siehe hier bzw. hier).
Und wichtig zu beachten ist, dass man das Fenster, in dem das Script läuft, währenddessen nicht einfach so schließen sollte, sondern das Script brav mit CTRL+C beenden sollte. Ansonsten wird der eingefügte Scheduled Task nämlich nicht gelöscht und wird beim nächsten regulären Reboot / Login ausgeführt, auch wenn es gar keinen Crash gab.
Ich hab ein paar Sicherungen eingebaut, die das Verhindern sollen, aber komplett fool-proof geht das leider nicht.
Die ganze Sache benötigt Admin-Rechte, das Script fragt dann auch danach, wenn die entsprechenden Settings gesetzt sind (die haben sich übrigens geändert im Vergleich zur letzten 0.9.7.0 alpha, siehe unten).

Des Weiteren gibt es nun eine neue Option, um WHEA Warnungen aus dem Event Log als tatsächliche Fehler zu werten, sofern die dort gemeldete APIC ID dem gerade getesteten Kern entspricht (tut sie es nicht, wird nur eine Warnmeldung ausgegeben).

Das Teil muss jetzt ziemlich eingehend getestet werden, ich hab da doch einiges umgeschrieben.

https://github.com/sp00n/corecycler/releases/tag/v0.10.0.0alpha2


Die relevanten Änderungen in der config.ini, inkl. der Erklärung für die Settings:
Code:
[General]

# Treat a WHEA Warning Event Log entry as an error
# If this is enabled, a WHEA warning (Event Id 19, "corrected hardware error") will be treated as a "real" error
# The testing on the core will be stopped and continued on the next one
# However only if the APIC ID from the WHEA message matches the core that was currently tested, otherwise
# only a warning will be displayed
#
# Default: 1
treatWheaWarningAsError = 1


[...]


# Settings for the Automatic Test Mode
[AutomaticTestMode]

# Enable the automatic test mode
# If you enable this setting, the script will automatically adjust the Curve Optimizer or voltage offset values
# when an error occurs
#
# For Ryzen CPUs up to Zen 4 (Ryzen 7000), it uses PJVol's "pbotest.exe", which is included in the /tools/pbocli/ directory
# For Intel, it uses "IntelVoltageControl", which allows you to set a voltage offset (also included in the /tools/ directory)
#
# Note that this will only INCREASE the Curve Optimizer / voltage offset values, i.e. it will try to make the settings
# more stable, it will never push the settings more into the negative
# Also note that enabling this setting will require the script to be run with administrator privileges
# And lastly, enabling it will set "skipCoreOnError" to 0 and "stopOnError" to 0 as long as the limit has not been reached
#
# IMPORTANT: This currently does not work for Ryzen 9000 (Zen 5) CPUs
#
# Default: 0
enableAutomaticAdjustment = 0


# The starting Curve Optimizer / voltage offset values
# You can provide the Curve Optimizer / voltage offset starting values here, or let them be automatically detected
# If you specify values here, they will overwrite your currently applied CO / voltage offset settings
# If you leave the value blank or at "Default", it will try to automatically detect your current settings
#
# Use a comma separated list or define a single value that will be applied to all cores
# For Intel, this currently only really supports a single voltage offset that is applied to each core
# For Ryzen, you can define the Curve Optimizer value for each core
#
# Note: For Ryzen, the minimum possible Curve Optimizer value is defined by your CPU (and possibly motherboard)
#       -30 is a common minimum value for Curve Optimizer, sometimes even -50
# Note: For Intel, the values are provided in millivolts, so e.g. -130 for an undervolt of -0.130v
#
# IMPORTANT: Use a negative sign if you want negative CO values / a negative voltage offset, not providing a
#            negative sign will instead apply a positive CO / voltage offset!
#
# Example for setting Curve Optimizer values for a Ryzen 5800X with 8 cores:
# startValues = -15, -10, -15, -8, 2, -20, 0, -30
#
# Example to assign a single Curve Optimizer value to all cores:
# startValues = -20
#
# Example to assign a voltage offset of -0.120v (120mv) for Intel processors:
# startValues = -120
#
# Default: Default
startValues = Default


# The upper limit for the Curve Optimizer values / voltage offset
# If this limit has been reached, no further adjustments will be performed
# Instead the core will now simply throw an error and the regular "skipCoreOnError" setting will be obeyed
# This is either a Curve Optimizer value or a voltage offset value
#
# IMPORTANT: Be sensible about this value, setting it too high into the positive could apply a too high
#            voltage to your CPU and may damage it!
#
# Default: 0
maxValue = 0


# The amount by which to increase the Curve Optimizer / voltage offset value
# On an error, the Curve Optimizer / voltage offset value will be increased by this amount
# For Ryzen, a value between 1 and 5 seems reasonable
# For Intel, you should probably set this to 5 to increase the vCore by 5mv after an error
#
# Setting it to "Default" will set the value to 1 for Ryzen and 5 for Intel
#
# Default: Default
incrementBy = Default


# Repeat the test on a core if it has thrown an error and the Curve Optimizer / voltage offset value was increased
# Setting this to 1 will restart the test, until it has not thrown an error, or until the maximum value has been reached
# Setting it to 0, the script will continue to the next core in line as normal
#
# Default: 1
repeatCoreOnError = 1


# Try to automatically resume after a crash / hard reboot
# If this setting is enabled, the script will try to automatically resume after a reboot has occurred
# It creates a Scheduled Task that will be run at logon, which then tries to resume where it left off,
# optionally repeating the last core with an adjusted value (see the repeatCoreOnError setting)
#
# IMPORTANT: If you just close the CoreCycler window without properly exiting the script with CTRL+C,
#            the Scheduled Task will remain and will be executed on the next reboot!
#            So make sure that you always exit CoreCycler by pressing CTRL+C
#
# IMPORTANT: The Scheduled Task will execute once you log back in to your user account
#            So for a true automated testing, it would be beneficial if you activated auto-logon
#            Be aware that this might pose a security risk though, so make sure to consider the risks!
#            https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
#            https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon
#
# Default: 0
enableResumeAfterUnexpectedExit = 0
[/spoiler]
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus, BreadPit, AthlonXP und 3 andere
Muss ich mehr änder als "AutomaticTestMode" auf 1 und "StartValues" auf z.B -20, dass der automatische Test läuft ?
bislang funktioniert das leider bei mir noch nicht.
 
[AutomaticTestMode] gibt es nicht als Setting, das man auf 1 setzen könnte, das ist die Sektion für die Einstellungen für den automatischen Testmodus innerhalb der config.ini.

Innerhalb dieser Sektion muss man dann enableAutomaticAdjustment = 1 setzen, das aktiviert die automatische Anpassung der Werte nach einem Fehler.
Und enableResumeAfterUnexpectedExit = 1 aktiviert dann zusätzlich das Neustarten nach einem Reboot.
 
meinte natürlich enableAutomaticAdjustment = 1
Die Überschrift der Sektion nennt sich AutomaticTestMode.

Edit:
klappt jetzt. Hab die Standard Config genommen. Mit den Custom Configs bzw. Allgemein mit YCruncher ging es nicht.
 
Zuletzt bearbeitet:

Ähnliche Themen

Zurück
Oben