CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[sp00n]

Hilfe: Kann ich deine Config Bread zu umschreiben, dass ich nur noch die nicht finalen Kerne teste?

Also alle außer Core 8 u. 9. Macht das Sinn? Wie geht das denn? Kannst du mir ggf. die Code-Zeile dafür posten?

Entweder wie @Bread beschrieben hat, nur die zu testenden Kerne angeben, oder die nicht (mehr) zu testenden bei coresToIgnore.
Also dann z.B. coresToIgnore = 8, 9.

@pwnbert
Linux steht erstmal nicht auf dem Plan, das wäre ein größerer Akt. Das Script benutzt ein paar Windows-eigene Funktionen, die ich dann ersetzen müsste.

 

[pwnbert]

Na ist ja auch kein Problem, wie gesagt, das mit dem Win-Stick geht ja gut.
War bloß interesse, ob ich was übersehen habe, oder obs was ähnliches gibt.

Coole Sache auf jeden Fall der Core-Cycler, hat mir schon gute Dienste erwiesen!

 

[hanneslan]

Entweder wie @Bread beschrieben hat, nur die zu testenden Kerne angeben, oder die nicht (mehr) zu testenden bei coresToIgnore.
Also dann z.B. coresToIgnore = 8, 9.

@pwnbert
Linux steht erstmal nicht auf dem Plan, das wäre ein größerer Akt. Das Script benutzt ein paar Windows-eigene Funktionen, die ich dann ersetzen müsste.

Danke dir für eine zweite Alternative. Ist auf jeden Fall kürzer.

PS: Wird der CoreCycler sehr wahrscheinlich auch z.B. für meinen neuen 9950X3D funktionieren?

Glaskugel an, ich weiß, aber gibt doch bestimmt Meinungen dazu.

Bastelst du dann ggf. wieder dran?

Beitrag automatisch zusammengeführt: 24.07.2024

Klar:
coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7, 10, 11, 12. 13, 14, 15

Am Schluss dann alles nochmal 12h durchlaufen lassen, gibt auch leichte Abhängigkeiten von "Nachbar-Core-Spannungen",

Ich bin genau auf +1 vom Crashwert weg. Musste in ca 2 Jahren 3 Cores um 1-2 nachbessern, also ja, degradiert, oder auch etwas andere Belastungen durch neue AGESA.

OK. Mit der möglichen Degradierung kann ich leben. Bevor ich da was davon merke, kommt eh bald mein 9950X3D an den Start.

 

[sp00n]

PS: Wird der CoreCycler sehr wahrscheinlich auch z.B. für meinen neuen 9950X3D funktionieren?

Glaskugel an, ich weiß, aber gibt doch bestimmt Meinungen dazu.

Bastelst du dann ggf. wieder dran?

Im Prinzip ist es ja nur ein Tool ist, um die Single-Core Stabilität zu testen. Von daher sehe ich momentan keinen Grund, warum es nicht mit Ryzen 9000 funktionieren sollte (bei den irgendwann kommenden Intels ohne Hyperthreading müsste man das aber mal testen, ob sich das dann einfach wie deaktiviertes Hyperthreading oder irgendwie anders verhält).

Ryzen 9000 hat allerdings den neuen "Curve Shaper" anstatt des Curve Optimizer, was entweder die Einstellungen viel komplizierter oder viel einfacher machen könnte. Komplizierter, weil man mehr einstellen kann. Und einfacher, weil man evtl. (hoffentlich) die meisten Idle-Crashes eliminieren kann, indem man die Spannung nur bei Last absenken lässt. Das wird sich aber erst mit Erfahrung aus der Community zeigen. Das generelle Vorgehen sollte aber das gleiche bleiben.

(Und ich hab grad gesehen, dass Ryzen 9000 nochmals um zwei Wochen verschoben wird)


Im jetzt gerade getesteten Release Candidate für 0.9.6.0 ist auch die neue y-cruncher Version enthalten, die die für Ryzen 9000 optimierte Binary beinhaltet. Ob die jetzt allerdings tatsächlich schneller Fehler findet als die 19 Kagari, muss sich auch erst zeigen. Um AVX512 zu testen müsste man aber definitiv die neue für Zen 5 nehmen.

 

[LuxSkywalker]

...
Also alle außer Core 8 u. 9. Macht das Sinn? Wie geht das denn? Kannst du mir ggf. die Code-Zeile dafür posten?
...

bitte beachten das sich "benachbarte" Kerne (des gleichen CCD) gegenseitig beeinflussen:

z.B. hast du Core 4 "fertig" mit -6 und du kannst bei Core 3 oder auch Core 5 nochmals niedrigere CO setzten von -3 auf -5 wirst du mit Sicherheit den eigentlich fertigen Core 4 auch nochmals testen müssen und gegenfalls wieder etwar höher stellen von z.b. -6 auf -4 runter.

Es gibt irgendwo hier im CoreCycler Thread irgendwo eine entsprechende Grafik 😉

ausserdem würde ich bei 2 CCD Prozessoren immer abwechselnd einen Kern des jeweils anderen CCD testen:

coreTestOrder = Alternate

bzw.

coreTestOrder = 0, 6, 1, 7, 2, 8, 3, 9, 4, 10, 5, 11

bei einem 12-Kerner

sonst glüht erstmal ein CCD vor sich hin ^^

des weiteren musst du ggf. mit neueren BIOS/AGESA Versionen das ganze Spielchen nochmals testen weil AMD u.U. die Spannungstabellen angepasst hat

/edit
Schreibfehler korrigiert - Danke @sp00n

 

[sp00n]

coreTestOrder = Aternate

Kleiner Schreibfehler, das müsste Alternate heißen.

Und wenn die CPU mehr als 8 physische Kerne hat, dann wird auch ein Default intern zu Alternate aufgelöst.

 

[hanneslan]

Anbei mal meine bisherigen Erkenntnisse:

Frage an die Experten:

Auffällig für mich als Laien ist, dass CCD1 (8-15) als erstes schlapp macht... Zufall?

Oder liegt dass daran, dass CCD0 den 3D VCache hat, der ja nicht so hochtaktet?

Beitrag automatisch zusammengeführt: 26.07.2024

Kleiner Schreibfehler, das müsste Alternate heißen.

Und wenn die CPU mehr als 8 physische Kerne hat, dann wird auch ein Default intern zu Alternate aufgelöst.

OK. Gut zu wissen.

Reicht es dann aus, wenn ich in meiner Config sequential durch Alternate ersetze?

Ohne die einzelnen zu testenden Cores aufzulisten?

Beitrag automatisch zusammengeführt: 26.07.2024

"des weiteren musst du ggf. mit neueren BIOS/AGESA Versionen das ganze Spielchen nochmals testen weil AMD u.U. die Spannungstabellen angepasst hat"

Bios Update habe ich derweil nicht vor. Danke für den Hinweis.

 

[hanneslan]

bitte beachten das sich "benachbarte" Kerne (des gleichen CCD) gegenseitig beeinflussen:

z.B. hast du Core 4 "fertig" mit -6 und du kannst bei Core 3 oder auch Core 5 nochmals niedrigere CO setzten von -3 auf -5 wirst du mit Sicherheit den eigentlich fertigen Core 4 auch nochmals testen müssen und gegenfalls wieder etwar höher stellen von z.b. -6 auf -4 runter.

Es gibt irgendwo hier im CoreCycler Thread irgendwo eine entsprechende Grafik 😉

ausserdem würde ich bei 2 CCD Prozessoren immer abwechselnd einen Kern des jeweils anderen CCD testen:

coreTestOrder = Alternate

bzw.

coreTestOrder = 0, 6, 1, 7, 2, 8, 3, 9, 4, 10, 5, 11

bei einem 12-Kerner

sonst glüht erstmal ein CCD vor sich hin ^^

des weiteren musst du ggf. mit neueren BIOS/AGESA Versionen das ganze Spielchen nochmals testen weil AMD u.U. die Spannungstabellen angepasst hat

/edit
Schreibfehler korrigiert - Danke @sp00n

OK. Danke für den Hinweis mit Alternate.

Hab eine 360 AiO u hatte mit CoreTemp die Temps im Blick. Temps waren nie höher als 60-80 Grad.

Sollte ich jetzt ggf. nochmals Alles neu testen?

Oder macht das bei mir nicht viel aus?

LG Hannes

 

[LuxSkywalker]

@hanneslan

nee alles gut... nur wegen

coreTestOrder = Alternate

brauchst du nix neu testen

 

[sp00n]

Reicht es dann aus, wenn ich in meiner Config sequential durch Alternate ersetze?

Ohne die einzelnen zu testenden Cores aufzulisten?

Jupp.

 

[sp00n]

Version 0.9.6.0 0.9.6.1 ist jetzt draußen, @Bread 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

 

[hanneslan]

Guten Morgen,

bin mittlerweile bei -32 für CCD0 angekommen: Klar muss Alles noch über Nacht 12 Stunden getestet werden, aber da ich bei Error/Neustart immer +4 hochgehe. Könnte das schon so in etwa funktionieren, denke ich mir zumindest.

Nochmals meine Frage an die Experten:

Auffällig für mich als Laien ist, dass CCD1 (8-15) als erstes schlapp gemacht hat... Zufall?

Oder liegt dass daran, dass CCD0 den 3D VCache hat, der ja nicht so hochtaktet?

Gibt es da so große Unterschiede?

 

[sp00n]

Also bei den Ryzens ohne 3D-Cache ist der CCD1 in der Regel der schlechtere, soweit ich das mitbekommen habe (bei mir auch).
Bei den 3D-Modellen soll der ja aber der höher taktende sein, also in der Hinsicht "besser". Ich halte das also für gar nicht so weit hergeholt, dass der niedrigere Takt beim CCD0 für mehr Spielraum beim Undervolting (was CO ja ist) sorgt.

Wobei @Bread et al da mit seinem 5800X3D mehr Erfahrung, vor allem aus der Praxis, haben dürfte. 😎

 

[Bread]

Naja - mit dem 5800X3D hab ich Erfahrung, aber der hat halt nur 1 CCD 😉 Vorher hatte ich einen 5800X, aber da war ich noch nicht so ein CoreCycler Fanboy 😁

Die Theorie macht durchaus Sinn. Je höher der Takt, desto höher die nötige vCore, also desto weniger CO.

Wie ich immer wieder sage, CO ist ein relativer Wert, der wenig Aussagekraft hat. Er hangt von der definierten vCore Basis ab. Ich vergleiche deshalb nur noch gemessene, absolute vCore Werte. Bei meinem 5800X3D liegen die bei im Schnitt ca 1150mV (CoreCycler stable). Auslesen mit dem PBO2Tuner Monitor.

 

[sp00n]

Stimmt, komplett vergessen, dass der 5800X3D nur ein Core-Chiplet hat 😀

 

[hanneslan]

Noch 5 Kerne to go...

Beitrag automatisch zusammengeführt: 28.07.2024

Aktuell nutze ich noch CoreCycler v0.9.5.3.

Und Bread's Config:

Beitrag automatisch zusammengeführt: 28.07.2024

@sp00n

Kann ich diese Config auch für deine neue Version 0.9.6.1 so verwenden?

Würde dann damit gerne den 12 Stunden Stabilitätstest machen wollen.

Oder bietet sich da noch eine andere Config mit weiteren neuen Tests an?

Wenn ja welche?

Danke dir!

 

[Bread]

0.9.5.3 Konfigs kannst Du 1:1 weiter verwenden.

Für die 12h aber Test Duration auf 60.

 

[hanneslan]

0.9.5.3 Konfigs kannst Du 1:1 weiter verwenden.

Für die 12h aber Test Duration auf 60.

Kann es sein, dass Duration auf 60 noch etwas anspruchsvoller ist, als 30?

Musste schon 3 Kerne nachjustieren, die vorher 5 Wiederholungen mit Duration auf 30 ohne Probleme geschafft haben?

 

[Bread]

Ja klar. Derselbe Test brennt halt einfach jeden Kern doppelt so lang her. Deshalb sind die 30s auch der Schnelltest, und die 60s der finale Test.

Das ist einfach das effektivste 80/20 Vorgehen im Sinne des Zeiteinsatzes. 80% der Nachjustierungen passieren in den ersten 20% der schnellen Tests. Die letzten 20%, um auf 99,9% Stabilität zu kommen (weil 100% Sicherheit und Stabilität gibt es prinzipiell nicht ), brauchen dann auch 80% der gesamten Testzeit, also ein paar Übernacht-Tests.

Und 5 Wiederholungen ist nix. Musste den letzten Kern nach ~14h / 25 Iterationen á 4x60s nachjustieren.

 

[hanneslan]

Ja klar. Derselbe Test brennt halt einfach jeden Kern doppelt so lang her. Deshalb sind die 30s auch der Schnelltest, und die 60s der finale Test.

Das ist einfach das effektivste 80/20 Vorgehen im Sinne des Zeiteinsatzes. 80% der Nachjustierungen passieren in den ersten 20% der schnellen Tests. Die letzten 20%, um auf 99,9% Stabilität zu kommen (weil 100% Sicherheit und Stabilität gibt es prinzipiell nicht ), brauchen dann auch 80% der gesamten Testzeit, also ein paar Übernacht-Tests.

Und 5 Wiederholungen ist nix. Musste den letzten Kern nach ~14h / 25 Iterationen á 4x60s nachjustieren.

Alles klar. Danke dir für die nützlichen Infos.

Werde ich Alles so beherzigen u Schritt für Schritt mich weiter vorkämpfen.

PS: Andere Configs u Tests brauche ich dann aber nicht mehr, wenn ich deine Config oben mit Duration 60 verwende oder?

 

[Bread]

Du erinnerst mich an mich selbst vor meinem Wiedereinstieg ins PC Tuning vor ein paar Jahren, mit meiner Denke "da muss es doch inzwischen die eine richtige Konfig geben" bzw "den einen wahren Stabilitätstest" Moment, eigentlich bin ich immer noch so, und ich denke wir sind hier nah dran Aber das ist meine Meinung - Du findest dazu jede Menge Meinungen und Erfahrungen im Netz. In meiner begrenzten Erfahrung ist der CoreCycler mit der yCruncher_old Konfig das härteste, das ich kenne, um per-Core Stabilität zu testen, weil eben max-Boost per Core getestet wird. Das ist ein sehr unwahrscheinliches Szenario (Stichwort preferred Cores / CPPC, das trifft normal nur 2 der Cores), deckt aber eben alle Evnetualitäten ab. Ich habe mit meinem so getesteten Rechner keinerlei Probleme, und auch ein paar andere nicht, die das genau so betreiben - teils professionelle PC-Assemblierer. Also was die CPU betrifft, sollte das reichen

Dann noch:
RAM: TM5 ABSOLUT@anta777 für mind. 12h
GPU: 3DMark Timespy Custom Loop Test 1+2 über Nacht, und Witcher 3 NG Praxistest

Das sollte wohl reichen, und ist wohl 90% mehr als die meisten machen Aber Du könntest mal Test Duration 120 machen und berichten, das wird wohl noch härter sein und hab ich noch nicht versucht. Wäre schon interessant

 

[hanneslan]

Du erinnerst mich an mich selbst vor meinem Wiedereinstieg ins PC Tuning vor ein paar Jahren, mit meiner Denke "da muss es doch inzwischen die eine richtige Konfig geben" bzw "den einen wahren Stabilitätstest" Moment, eigentlich bin ich immer noch so, und ich denke wir sind hier nah dran Aber das ist meine Meinung - Du findest dazu jede Menge Meinungen und Erfahrungen im Netz. In meiner begrenzten Erfahrung ist der CoreCycler mit der yCruncher_old Konfig das härteste, das ich kenne, um per-Core Stabilität zu testen, weil eben max-Boost per Core getestet wird. Das ist ein sehr unwahrscheinliches Szenario (Stichwort preferred Cores / CPPC, das trifft normal nur 2 der Cores), deckt aber eben alle Evnetualitäten ab. Ich habe mit meinem so getesteten Rechner keinerlei Probleme, und auch ein paar andere nicht, die das genau so betreiben - teils professionelle PC-Assemblierer. Also was die CPU betrifft, sollte das reichen

Dann noch:
RAM: TM5 ABSOLUT@anta777 für mind. 12h
GPU: 3DMark Timespy Custom Loop Test 1+2 über Nacht, und Witcher 3 NG Praxistest

Das sollte wohl reichen, und ist wohl 90% mehr als die meisten machen Aber Du könntest mal Test Duration 120 machen und berichten, das wird wohl noch härter sein und hab ich noch nicht versucht. Wäre schon interessant

Ich fasse das mal ganz bescheiden als ein Kompliment auf.

Wenn ich was mache, dann will ich es von Anfang bis Ende richtig machen, um mir zumindest nicht nachsagen zulassen, dass ich nicht Alles gegeben habe.

So für heute ist erst Mal Schluss...

Die Übernacht-Tests müssen erstmal noch warten, wobei ich die lieber Tags über mache, denn dann kann ich die PV auf unserem Dach besser dafür nutzen.

Und im Home Office kann man da immer gut beobachten u. ggf. frühzeitig eingreifen, um das max. ressourcenschonend auf die Wege zu bringen.

Vielen Dank für deine ausführlichen Schilderungen.

Gerne komme ich bestimmt nochmals auf deine Expertise u. dein Fachwissen zurück.

Nichtsdestotrotz dürfen mir auch gerne andere Experten mit Tat u Rat zur Seite stehen.

Gibt doch nichts über Schwarmintelligenz at its Best.

LG Hannes

 

[Bread]

Absolut - war von mir ganz bescheiden als Kompliment gemeint Die ewige Suche nach dem Optimum ist ja was Gutes. Wie hab ich in einer Sig erst neulich gelesen? "Wer aufgehört hat besser zu werden, hat aufgehört gut zu sein"

 

[hanneslan]

Absolut - war von mir ganz bescheiden als Kompliment gemeint Die ewige Suche nach dem Optimum ist ja was Gutes. Wie hab ich in einer Sig erst neulich gelesen? "Wer aufgehört hat besser zu werden, hat aufgehört gut zu sein"

So schaut's aus!

PS: Wie sieht's denn in meinem jetzigen Zustand mit normalen Windows Betrieb aus?

Sollte doch eigentlich kein großes Problem sein, da solche Lasten auf den max-Boost Cores ja eher ganz selten sind oder?

Ich weiß, sowas weiß man in der Regel erst immer hinterher, aber bin da guter Dinge.

Try and find out!

 

[LuxSkywalker]

Wie sieht's denn in meinem jetzigen Zustand mit normalen Windows Betrieb aus?

solange das System nicht 100% getestet und damit stabil ist kannst du dir jederzeit nen BSOD einfangen. Wenns ganz doof läuft auch Dateisystemfehler.

Ich habe das ganze testen und optimieren ausschließlich mit einem zweiten Windows durchgezogen

 

[Bread]

Wenn ich das richtig lese, 12h / 10 Iterationen ohne Fehler? Sollte passen, aber wie gesagt, mein letzter Fehler kam bei Iteration 25 nach 12h, sprich 30min pro Kern. Du hast doppelt so viele Kerne, also lass mal 24h laufen

 

[hanneslan]

Wenn ich das richtig lese, 12h / 10 Iterationen ohne Fehler? Sollte passen, aber wie gesagt, mein letzter Fehler kam bei Iteration 25 nach 12h, sprich 30min pro Kern. Du hast doppelt so viele Kerne, also lass mal 24h laufen

Gemach, gemach! Kommt alles nach u nach. 😉 Das sind erst mal Platzhalter u 24 Stunden habe ich noch nicht angehängt bzw. ist abgeschnitten vom Screenshot. Hast du nicht ganz richtig gelesen. Bin noch bei 3,5 Stunden am Ausloten. Denke da kommen noch Anpassungen vor allem bei CCD0. Die Werte kommen mir alle noch sehr hoch im Verhältnis zu CCD1 vor. Aber mal gucken. Alles was weiß ist, ist dann noch als Nächstes zu tun. Zum guten Schluss dann 24 Stunden laufen zu lassen, aber soweit bin ich noch nicht. Werde ich aber definitiv mal machen.

Heute ist erst mal Pause!

Beitrag automatisch zusammengeführt: 30.07.2024

solange das System nicht 100% getestet und damit stabil ist kannst du dir jederzeit nen BSOD einfangen. Wenns ganz doof läuft auch Dateisystemfehler.

Ich habe das ganze testen und optimieren ausschließlich mit einem zweiten Windows durchgezogen

Danke für deine Rückmeldung. Für ein zweites Windows ist es für mich jetzt leider eh zu spät: Ich gehe All In! Aber für die Zukunft gar keine schlechte Idee.

 

[sp00n]

Ich hatte mir dann auch irgendwann ein zweites Windows auf einer anderen SSD installiert. 😁

Übrigens arbeite ich gerade an der automatischen Anpassung der Curve Optimizer Werte nach einem Fehler mithilfe von PBO2Tuner (bzw. einer Version komplett für die Kommandozeile, die PJVol dann freundlicherweise gebastelt hat).
Sieht recht viel versprechend aus.

// Edit
Hier ist mal die momentane Entwicklerversion. Die configs/config.default.ini enthält bereits die Beschreibung für das [AutomaticCurveOptimizer]-Feature (die normale config.ini wird in der Version nicht gleich mitgeliefert, sondern erst beim ersten Aufruf erstellt).

Release v0.9.7.0alpha5: Fixed a bug where not all threads could be correctly identified while… · sp00n/corecycler

… suspending the stress test process. Fixed a bug where the stress test program wasn't re-started if the first core on the first iteration threw an error and Automatic Curve Optimizer and restart f...

github.com

# Settings for the Automatic Curve Optimizer adjustment
[AutomaticCurveOptimizer]

# Enable the automatic Curve Optimizer adjustment
# It uses PJVol's PBO2 Tuner, which is included in the /tools/ directory
# If you enable this setting, the script will automatically adjust the Curve Optimizer values
# when an error occurs
# Note that it will only INCREASE the Curve Optimizer 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" also top 0
# IMPORTANT: This only works up to Ryzen 7000 (Zen 4) so far
#
# Default: 0
enableAutomaticAdjustment = 0


# The starting Curve Optimizer values
# You can provide the Curve Optimizer starting values here, or let them be automatically detected
# If you specify values here, they will overwrite your currently applied CO settings
# If you leave the value blank or at "Default", it will try to automatically detect your current settings
#
# Important: use a negative sign if you have negative CO values, not providing a negative sign will
# instead apply a positive CO offset
# Use a comma separated list or define a single value that will be applied to all cores
#
# Note: The minimum possible value is defined by your CPU (and possibly motherboard). -30 is a common value
#
# Example for a Ryzen 5800X with 8 cores:
# startValues = -15, -10, -15, -8, 2, -20, 0, -30
# Example to assign a single value to all cores:
# startValues = -20
#
# Default: Default
startValues = Default


# The upper limit for the Curve Optimizer values
# If this limit is reached, the CO value will no longer be increased, instead the core will now simply
# throw an error and the regular "skipCoreOnError" setting will be obeyed
#
# Default: 5
maxValue = 5


# The amount by which to increase the Curve Optimizer value
# On an error, the Curve Optimizer value will be increased by this amount
#
# Default: 1
incrementBy = 1


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

 

[pwnbert]

Danke für deine Rückmeldung. Für ein zweites Windows ist es für mich jetzt leider eh zu spät: Ich gehe All In! Aber für die Zukunft gar keine schlechte Idee.

Flotter USB Stick reicht ja schon. Per Rufus ein Win10 to Go machen und gut ists? Ich hab das so gemacht.

solange das System nicht 100% getestet und damit stabil ist kannst du dir jederzeit nen BSOD einfangen. Wenns ganz doof läuft auch Dateisystemfehler.

Jup, Windooze mit NTFS ist recht gut drin, been there, done that (waren allerdings RAM Fehler, seither gibts ECC für mich). Wobei... ist mir genau einmal passiert nach vielen, vielen Jahren.
Wenn man aber vor hat öfter zu BSODen, tät ich tatsächlich ein Mobile-Windows (oder eins auf irgend ner alten SATA SSD) verwenden.

 

[Bread]

Übrigens arbeite ich gerade an der automatischen Anpassung der Curve Optimizer Werte nach einem Fehler mithilfe von PBO2Tuner (bzw. einer Version komplett für die Kommandozeile, die PJVol dann freundlicherweise gebastelt hat). Sieht recht viel versprechend aus.

Sensationell! Genau das sollte mein zweites GitHub Projekt werden, hatte die Idee vor ein paar Wochen, aber keine Zeit - und jetzt baust Du das schon Ein Auto-CoreCycler CO Tuning, wie cool!

Gleich mal ein Input dazu: ich habe kaum Fehler im yCruncher Log, bei mir ist in 99% der Fällen das Fehlerverhalten ein "sudden reboot", wie bei @hanneslan offenbar auch? Damit ich das sinnvoll nutzen kann, hier ein Vorschlag wie man das umsetzen könnte:

• (optional) Beim Start des CC Tests ein Flag setzen für "Auto-CC ON" inkl. Angabe der aktiven Logfiles (bei regulären Beenden des Tests wird das dann OFF gesetzt)
• Bei jedem Bootvorgang checken, ob "Auto-CC ON" --> dann wurde CC beim letzten Mal nicht ordnungsgemäß beendet
• ON? Im Windows Eventlog nach WHEA 18 suchen und den Kern auslesen
• Im PBO2tuner den CO Wert für diesen Core raufsetzen
• CC Test wieder starten
• Nach definierter Zeit / Durchläufen wird CC beendet und "Auto-CC OFF" gesetzt

Für reguläre Fehler ist es natürlich deutlich einfacher, während des Tests fehlerhafte Cores auslesen, und mit PBO2Tuner das CO für die betreffenden Cores raufsetzen.

Btw ich nutze schon ewig PBO2Tuner in der Kommandozeile (Task Scheduler mit cmd Befehl), das geht doch schon lange?