CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[swansong]

So, ~14h lief es mit dem Test bei -25 durch und bestätigt damit den Prime95 Test auf allen Kernen. -29 war gleich zu Beginn instabil, die Grenze liegt damit zwischen -25 und -28. Wohl ein ganz guter Wert, betreiben werde ich den PC sowieso mit Grenzewert+2 für etwas mehr Sicherheit.

 

[sp00n.82]

Version 0.9.5.0 ist jetzt draußen, hat ein paar Änderungen.

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

• Updated Prime95 to version 30.19b20
• Updated y-Cruncher to version 0.8.4 Build 9538
• Updated PBO2 Tuner to the latest version
• It's now possible to catch the output from y-Cruncher, thus enabling the "auto" runtimePerCore setting for y-Cruncher as well. It will test all selected cores for one core and then proceed to the next one
  (this is made possible by a custom wrapper .exe and .dll in the /helpers directory)
• Greatly increased the support for Intel CPUs, it now tries to detect a core architecture where some cores only support one thread (i.e. Intel's big.LITTLE) and automatically adjusts the threads it runs on these cores if two threads and restartTestProgramForEachCore is selected.
  Note that running with two threads and without the setting enabled may result in very long test times on the E-Cores and any test afterwards, so it's strongly recommended to either enable restartTestProgramForEachCore, test only with one thread, or test the P- and E-Cores separately.
• Added support for processors with more than 64 (virtual) cores for you HEDT freaks!
• Added a testDuration setting for y-Cruncher that allows to set the test duration in seconds for each individual test (default: 60)
• The script now also checks for WHEA errors (Windows Hardware Error Architecture) during its runtime and notices the user if such an event has happened.
  It's not treated as a "real" error, as it doesn't necessarily coincide with the core that is currently being tested.
  You can disable this check with the lookForWheaErrors setting.
• The script now also uses the Windows Event Log to store log information. This is helpful if a hard reboot occurs during testing, which can corrupt the log file. The Event Log entry should still show which core had begun testing before the hard reboot happened.
  To be able to use this functionality, the script asks the user if a new "Event Source" should be added, which requires administrator privileges. This only needs to happen once, so after this "Source" has been added, no administrator privileges will be needed anymore. The script itself also doesn't need admin rights, instead it will open a new window to perform this action, and asks for elevation for this new window.
  The Event Log entries can be found in the "Windows Logs"/"Applications" section of the Event Viewer, and have the source "CoreCycler".
  This functionality can be controlled by the useWindowsEventLog setting in the [Logging] section.
• It's also possible to try to periodically force a "Disk Write Cache Flush", which can also help prevent log file corruption. It's not enabled by default though, to prevent possible negative performance impacts (setting flushDiskWriteCache in the [Logging] section)
• The check for the CPU utilization doesn't require Windows Performance Counters anymore, which malfunctioned far more often than I had ever imagined, and so should result in less false alarms. Instead it now uses the more readily available processor time.
  If you really want to, you can re-enable the use of the Windows Performance Counters by setting useWindowsPerformanceCountersForCpuUtilization in the [Debug] section, but I really advise against it.
• Added a beep on error! (Controlled with the beepOnError setting)
• Added a taskbar flash on error! (Controlled with the flashOnError setting)
• The CPU affinity is now set to the threads of the stress test program, and not to the program/main process itself anymore.
  This is required to be able to set the affinity for more than 64 CPUs, and also to fix a bug that appeared on Intel systems, where if set to use two threads, the two virtual CPUs weren't fully loaded if only the main program's affinity was set.
  You won't be able to easily see the current affinity using the Task Manager anymore, but a tool like System Informer can also show the current affinity for threads
• The new y-Cruncher version has updated tests and also doesn't support the 00-x86 algorithm anymore, so the new default low-load binary algorithm is 04-P4P instead
• However, the old y-Cruncher version (which is 0.7.10) is still included, and you can use it by setting stressTestProgram to YCRUNCHER_OLD
  Be aware that you will also need to adjust the tests setting in the config if you're switching between the versions!
• The config.default.ini is now automatically generated (and overwritten) on each script start. It doesn't have any functional use anymore and is purely there to give the user a starting point / reference for creating a custom config.ini
• The PowerShell code itself now uses the Set-StrictMode -Version 3.0 setting. This may introduce new and fun script error messages, but hopefully I have already caught most of them!
• This caused a general code cleanup and some refactoring due to the errors I caught this way. And also eliminated a couple of bugs
• Added a LICENSE file! It just includes the text of the "CC BY-NC-SA" Creative Commons license, which the script always had anyway

 

[BlackDevCon]

Hi sp00n,
ich hatte die letzte Zeit die 0.9.5 alpha3 genutzt. Lief auch alles top. Mit der neuen 0.9.5.1 erhalte ich folgenden Fehler:
FATAL ERROR: Ausnahme beim Aufrufen von "SourceExists" mit 1 Argument(en): "Die Quelle wurde nicht gefunden, aber einige oder alle Ereignisprotokolle konnten nicht durchsucht werden. Protokolle, auf die kein Zugriff möglich war: Security."

Eine Idee was das sein könnte ?

 

[LuxSkywalker]

@BlackDevCon

als Administrator ausführen!

 

[sp00n.82]

Argl, eigentlich sollte das Ausführen als Admin nicht nötig sein, weil ich diese Exception "erwarte" und abfange. Allerdings habe ich nicht damit gerechnet, dass sie (mal wieder) lokalisiert wird.
Jetzt muss ich mal schauen, ich das auch für die ganzen anderen Sprachen generalisieren kann. 🧐

Der Workaround mit als Admin ausführen funktioniert, das will ich aber nicht zur Voraussetzung machen. Es sollte nur ein Mal nötig sein, und auch dann fragt das Script vorher.

 

[sp00n.82]

Hi sp00n,
ich hatte die letzte Zeit die 0.9.5 alpha3 genutzt. Lief auch alles top. Mit der neuen 0.9.5.1 erhalte ich folgenden Fehler:
FATAL ERROR: Ausnahme beim Aufrufen von "SourceExists" mit 1 Argument(en): "Die Quelle wurde nicht gefunden, aber einige oder alle Ereignisprotokolle konnten nicht durchsucht werden. Protokolle, auf die kein Zugriff möglich war: Security."

Eine Idee was das sein könnte ?

Müsste jetzt in 0.9.5.2 gefixt sein.
https://github.com/sp00n/corecycler/releases

 

[LuxSkywalker]

@sp00n.82

gerade getestet, funktioniert ohne Adminrechte

 

[BlackDevCon]

Müsste jetzt in 0.9.5.2 gefixt sein.
https://github.com/sp00n/corecycler/releases

Super danke für den schnellen Support. Spitzen Arbeit

 

[sp00n.82]

Ich spiele gerade mit dem Gedanken, verschiedene Configs direkt mitzuliefern, also z.B. sowas wie "quick initial test.ini", "overnight.ini", "final long term stability.ini", usw.
Die würde man dann einfach in config.ini umbenennen / dahin kopieren, damit könnte man recht schnell zwischen verschiedenen Konfigurationen hin- und herwechseln.

Bin für Vorschläge hinsichtlich der Konfigs offen (@BreadPit wink wink 😁)

 

[4BitDitherBayer]

Respekt für deine Arbeit !
Schön das du nach der Langen Zeit immer noch Features weiter Entwickelst.
Ich muss gestehen das ich in der Zwischenzeit zu einem andere Tool gewechselt war obwohl ich auch um die Schwierigkeiten denen du dich stellen musstes gewusst hab.
https://www.computerbase.de/forum/t...r-einstellungen.2009519/page-19#post-29453017

Schön das es weiter geht, ich habe meine Ersten schritte ins Undervolting (Zen 3) mit deiner Software bestritten.

 

[BreadPit]

@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:

Spoiler: CoreCycler 0.9.5.0 YCRUNCHER Config

[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

Spoiler: CoreCycler 0.9.5.0 YCRUNCHER_OLD Config

[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

 

[sp00n.82]

Danke dafür. Beim Testen ist mir gleich mal aufgefallen, dass YCRUNCHER_OLD einen Bug hat, bei dem nicht alle eingetragenen Tests übernommen werden (sondern nur die, die auch im neuen y-Cruncher vorhanden sind) 😌

Ansonsten ein paar Anmerkungen:

• runtimePerCore sollte vermutlich besser auf auto gesetzt werden. Das vermeidet das Jonglieren mit Sekundenwerten
• coreTestOrder dann auf Sequential, das entspricht 0, 1, 2, ... n
• delayBetweenCores hat nur eine Auswirkung, wenn auch restartTestProgramForEachCore auf 1 gesetzt ist. Wenn das Stresstest Programm nicht neu gestartet wird, dann läuft es einfach weiter zwischen den Cores
• lookForWheaErrors dachte ich hätte ich schon per Default auf 1 gesetzt, stand aber tatsächlich noch auf 0. Das wird dann in der nächsten Version auch standardmäßig aktiviert

 

[sp00n.82]

Ich hatte mir das jetzt so überlegt, dass es einen neuen Eintrag in der config.ini gibt, bei dem man eine weitere Datei angeben kann, die dann den alle weiteren Werte bestimmt.
D.h. praktisch bräuchte man nur noch diesen einen Eintrag in der config.ini ändern, um zwischen verschiedenen Konfigurationen hin- und herzuwechseln. Das sollte schneller gehen als die Dateien immer umzubenennen.
Das sähe dann so aus:

# General settings
[General]

# The config file to use
# If this value is set, it will use the content from the file provided and all other settings below are ignored
# It's useful for quickly switching between various configs
# You can find some predefined config files in the "configs" directory
# The setting uses a relative path from the location where this file is located in
# Example:
# useConfigFile = configs\quick-initial-test.yCruncher.config.ini
#
# Default: (empty)
useConfigFile =


[...]
Der Rest der Config geht erstmal so weiter wie gehabt, könnte dann aber entfernt werden,
wenn useConfigFile benutzt wird

Und hier sind jetzt ein paar Configs, die ich mir aus dem Ärmel geschüttelt habe (plus die von @BreadPit, etwas modifiziert).
Im Prinzip würde ich auch gerne eine kleine Zusammenfassung für jede Config haben, für was die eingesetzt werden könnte.


quick-initial-test.yCruncher.config.ini

# This file can be used for an initial test and should find immediate errors rather quickly
# It uses y-Cruncher with 19-ZN2 ~ Kagari and loads it with two threads
# Author: sp00n

[General]
stressTestProgram = YCRUNCHER
runtimePerCore = auto
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 2
restartTestProgramForEachCore = 1
delayBetweenCores = 5

[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = BKT, BBP, SFT, SNT, SVT, FFT, N63, VT3
testDuration = 20

long-final-test.Prime95.config.ini

# This will test ALL available FFT sizes with Prime95 for each core
# It will take a very long time, so it's best to use only after you're pretty sure that you've dialed in your settings
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = auto
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1

[Prime95]
mode = SSE
FFTSize = All

low-load-scenario.Prime95.config.ini

# This config uses a low-load scenario using Prime95 and is useful for finding possible crashes during load changes
# It uses Prime95 with the SSE instruction set and Huge FFTs
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = auto
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1
restartTestProgramForEachCore = 1
delayBetweenCores = 15

[Prime95]
mode = SSE
FFTSize = Huge

Prime95.720K.AVX2.config.ini

# Prime95 with 720K FFT size is a popular choice for stress testing CPUs
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = 3m
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1

[Prime95]
mode = AVX2
FFTSize = 720-720

Prime95.1344K.AVX2.config.ini

# Prime95 with 1344K FFT size is another popular choice for stress testing CPUs
# It was often used to test vCore stability
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = 3m
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1

[Prime95]
mode = AVX2
FFTSize = 1344-1344

Und die beiden von @BreadPit:

5800X3D.yCruncher.BreadPit.config.ini

# This config has been determined to be very good for quickly finding errors by the community
# The testing has mainly been done on a 5800X3D processor, but it's also useful for other processors
# Author: BreadPit
# Source: https://www.computerbase.de/forum/threads/corecycler-tool-zum-testen-der-curve-optimizer-einstellungen.2009519/post-29579457

[General]
stressTestProgram = YCRUNCHER
runtimePerCore = auto
coreTestOrder = Sequential
numberOfThreads = 2

[yCruncher]
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

5800X3D.yCruncherOld.BreadPit.config.ini

# This config has been determined to be very good for quickly finding errors by the community
# The testing has mainly been done on a 5800X3D processor, but it's also useful for other processors
# This config uses the "old" version of y-Cruncher (v0.7.10), which can produce better results in some cases
# Author: BreadPit
# Source: https://www.computerbase.de/forum/threads/corecycler-tool-zum-testen-der-curve-optimizer-einstellungen.2009519/post-29579457

[General]
stressTestProgram = YCRUNCHER_OLD
runtimePerCore = auto
coreTestOrder = Sequential
numberOfThreads = 2

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

 

[Fas7play]

Danke dafür. Beim Testen ist mir gleich mal aufgefallen, dass YCRUNCHER_OLD einen Bug hat, bei dem nicht alle eingetragenen Tests übernommen werden (sondern nur die, die auch im neuen y-Cruncher vorhanden sind) 😌

Thx und ich dachte schon es liegt an mir, denn die "_OLD" lieft nämlich nicht in CC 0.9.5.2.
Daher blieb ich bei 0.9.4.2! :>

@BreadPit yep, N64 ✅

 

[MehlstaubtheCat]

Ja, bei mir ist auch N64, was ich bisher am meisten gebrauchen kann beim Testen.
Ist einfach "besser" als N63 zumindest findet es schneller Fehler als N63, das mir einfach zu "weich" ist.

Schön das man das bald umstellen kann in den neuen Versionen.
Dann komme ich auch mal in den Genuss von was Neuerem

 

[sp00n.82]

Hab jetzt ein Bugfix-Release rausgebracht, um das Problem mit den nicht erkannten Tests bei YCRUNCHER_OLD zu beheben:
https://github.com/sp00n/corecycler/releases/tag/v0.9.5.3

Für das nächste major Release (0.9.6.0) plane ich folgendes:

• Integration von Linpack als Stresstest (momentan hab ich da Linpack Xtreme, ich denke ich wechsel aber auf das reguläre Intel Linpack)
• Die Möglichkeit, zwischen verschiedenen Configs zu wechseln mit dem useConfigFile Setting
• Ein Update-Check, der über eine neue Version informiert
• Hoffentlich ist bis dahin dann auch Zen 5 draußen und ich kann die nochmals neue Version von y-Cruncher mit Zen5-Optimierungen einbinden

 

[MehlstaubtheCat]

Linpack Xtreme > Intel Linpack

Hab es schon mehrfach getestet, das "Extreme" haut mehr rein.

 

[4BitDitherBayer]

@MehlstaubtheCat Sollte man das wirklich auf AMD CPUs verwenden wenn es:
a.) Für Intel CPUs im Speziellen geschrieben wurde.
b.) Nur durch einen dürftig dokumentierten Kompatibilitätsmodus überhaupt auf AMD CPUs ausgeführt werden kann.
Dieser Benchmark ist extrem Fordernd, was wenn dadurch Schäden entstehen wenn man eine Software verwendet die eigentlich nicht für diese CPUs geschrieben wurde?

Man sollte auch an die Leute denken die nicht so mit der Materie vertraut sind das die sich auch in einem Save Space bewegen.

 

[sp00n.82]

Die Geschichte von Linpack ist eine voller Missverständnisse... 😁

Linpack Xtreme ist im Prinzip Intel Linpack Version 2018.0.3.1 (bzw. 2018.0.3.011). Zumindest die linpack_intel64.exe Datei ist bit-identisch zu der aus dem offiziellem Release (linpack_xeon64.exe).
Die Version von Linpack Xtreme für AMD ist... irgendetwas anderes (linpack_amd64.exe). Evtl. selbst kompiliert? Die Größe ist komplett anders und zeigt auch keine Versionsnummer an. Leider antwortet der Autor nicht mehr im entsprechendem Thread bei Techpowerup.

Allerdings, wenn ich die offizielle Intel .exe selbst patche, damit sie auf AMD läuft, dann zeigt sich zumindest bei einem Thread kein merklicher Unterschied in den GFlops im Vergleich zu der mitgelieferten linpack_amd64.exe.
Bei zwei Threads ist die mitgelieferte dann minimal schneller (1-2% = 1-2 GFlops), bei 12 oder 24 Threads ist sie dann wieder ein wenig langsamer als die selbst gepatchte (aber für den CoreCycler sind ja nur 1 und 2 Threads interessant).
Also so ganz steige ich da nicht durch. Wenn sie selbst kompiliert wurde, dann zeigen sich da zumindest keine großartigen Optimierungen.

Die neueren Linpack Versionan ab 2020.irgendwas sind dann schon eher langsamer, da sind es dann ca 7% weniger GFlops bei ein und zwei Threads gegenüber der selbst gepatchten Version 2018.0.3.1.
In diesen Versionen wurde ja die MKL_DEBUG_CPU_TYPE Umgebungsvariable deaktiviert, mit der man AVX bzw. AVX2 auf AMD aktivieren konnte. Stattdessen wird das jetzt von selbst aktiviert, aber anscheinend nicht ganz so perfomant wie früher. Ist halt weiterhin eine für Intel optimierte Bibliothek.

Von AMD gibt es ja eine eigene Bibliothek (AOCL), mit der man vermutlich eine entsprechende linpack.exe für AMD selbst kompilieren könnte. Dazu fehlt mir allerdings die Erfahrung, das müsste ich mir erstmal selbst beibringen. Und keine Ahnung, ob sich das überhaupt lohnen würde.


@4BitDitherBayer
Kaputt geht da nix. Also zumindest nicht mehr, als es bei anderen Stresstests auch der Fall wäre, wenn die Kühlung nicht gut genug ist und man dann evtl. auch noch die Overtemperatur-Protection ausgeschaltet hat.

 

[BreadPit]

Danke dafür. Beim Testen ist mir gleich mal aufgefallen, dass YCRUNCHER_OLD einen Bug hat, bei dem nicht alle eingetragenen Tests übernommen werden (sondern nur die, die auch im neuen y-Cruncher vorhanden sind) 😌

Ansonsten ein paar Anmerkungen:

• runtimePerCore sollte vermutlich besser auf auto gesetzt werden. Das vermeidet das Jonglieren mit Sekundenwerten
• coreTestOrder dann auf Sequential, das entspricht 0, 1, 2, ... n
• delayBetweenCores hat nur eine Auswirkung, wenn auch restartTestProgramForEachCore auf 1 gesetzt ist. Wenn das Stresstest Programm nicht neu gestartet wird, dann läuft es einfach weiter zwischen den Cores
• lookForWheaErrors dachte ich hätte ich schon per Default auf 1 gesetzt, stand aber tatsächlich noch auf 0. Das wird dann in der nächsten Version auch standardmäßig aktiviert

Ich setze in meinen Konfigs einfach alle Parameter, die für mich relevant sind, explizit. Auch um zu veranschaulichen, was andere für sich ev ändern wollen. Deshalb auch CoreTestOrder explizit, damit gleich ersichtlich ist wie man nur bestimmte Cores testet. zB hab ich zuerst nur die 2 problematischen Cores getestet, bis die stable waren.

restartTestProgramForEachCore hab ich auf 0, weil man dann auch im YCruncher Testfenster durchscrollen und auf Fehler kontrollieren kann. War ja bei früheren Versionen manchmal so, dass der Corecycler keine Fehler erkannt hat, im Testfenster aber waren sie ersichtlich. Oder ist das jetzt nicht mehr nötig, weil die jetzt zuverlässig erkannt werden?