CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[LuxSkywalker]

@WinsBins

mein 7900x benötigt auf 3 Kernen auch ein positives Offset:

Core0	Core1	Core2	Core3	Core4	Core5	Core6	Core7	Core8	Core9	Core10	Core11
-4​	+4​	+5​	+8​	-1​	-9​	-30​	-35​	-27​	-29​	-31​	-25​

ist halt so ^^

 

[WinsBins]

@LuxSkywalker Ja. Dann ist das wohl so.
War dann nur falsches denken das bei CO 0 alles stabil laufen würde. 😉

Jetzt muss ich nur noch herausfinden und gezielt reproduzieren können warum nach Last, wie z.B. Prime und HWinfo offen ein gewollter WindowsNeustart! der PC dann in der CPU Erkennung (rote LED) hängen bleibt. Hätte ich ein herunterfahren! gemacht und danach wieder eingeschaltet, passiert das nicht.
Also Warmstart vs Kaltstart.
Ob da die CO Werte irgendwie Hineinfunken.
Manchmal hängt er auch bei der gelben LED (RAM).
Aber auch bei Default Settings hatte ich das schon. Manchmal hilft dann nur Clear CMos.

Werde noch nicht ganz schlau daraus. Irgendwas ist da noch im argen.

Kann HWinfo da irgendwas mit zu tun haben?

 

[LuxSkywalker]

das da irgendeine Software was mit zu tun haben könnte, würde ich mal pauschal ausschließen. Schließlich ist die Software da mal überhaupt noch nicht geladen

ABER wenn dein System halt nicht 100% stabil könnte das sowohl an CO als auch an wackeligem RAM liegen

evtl auch mal eine BIOS Version zurück gehen

Beitrag automatisch zusammengeführt: 04.01.2025

@LuxSkywalker Ja. Dann ist das wohl so.
...
Aber auch bei Default Settings hatte ich das schon. Manchmal hilft dann nur Clear CMos.
...

bitte auch immer bedenken das bei Default immer noch sämtliche Mainboard OC Funktionen aktiviert sind...

ich hatte das im Ryzen DDR5 Thread die Tage erst thematisiert - kann gut sein das deine CPU die voreinstellungen der MB Hersteller nicht packt oder nur wackelig mit startet

es ist halt komplett scheiße, das Load Setup Default nicht zu 100% die AMD Vorgaben lädt sondern IMMER auch die OC Funktionen der jeweiligen Boardherstellt aktiviert

 

[Katinka95]

kann man den core cdycler auch für ryzen 9000 verwenden?

 

[Vista]

@sp00n
Wann kommt die v0.10.0.0 Final?

 

[LuxSkywalker]

kann man den core cdycler auch für ryzen 9000 verwenden?

klar, warum auch nicht - immer wenn Kerne aussteigen ist das System halt instabil

 

[Katinka95]

In der Beschreibung bei Computerbase, da steht halt für Ryzen 5000

 

[LuxSkywalker]

das ist schon lange nicht mehr zutreffend - arbeite dich durch den Thread. Da haben wir haufenweise Tips&Tricks zusammen getragen

grundsätzlich kannst du alle Hinweise für 7000 auch für 9000 CPUs nutzen

ab Seite 2 geht es schon mit den 7000er CPU los

 

[Katinka95]

Ist leider alles bisschen viel, hab das aktuelle mal runtergeladen, und das läuft schon ne Weile, hab aber nichts umgestellt.
Bisher keine Fehler

 

[LuxSkywalker]

nun den CoreCycler benötigst du idR nur um zu prüfen ob deine CPU deine (gewünschten) Einstellungen bzgl Curve Optimizer mitmacht - z.B. allcore -15 o.ä.

wenn du da nichts einstellst brauchst du idR auch nicht damit testen - kann sicherlich nicht schaden. Aber sinnvoll ist das nicht

 

[Katinka95]

Ja ich hab erst das PBO -40 Max temp 85 getestet, da ist’s schon in cb23 abgeschmiert,
Jetzt hab das preset mit -30 da läuft cb2, und auch YouTube, und der Core cycler seit um 10 bisher ohne Fehler.

Weil wenn ich kein pbo curve optimizer preset wähle überhitzt die CPU in Sekunden bei cb23,
Mit dem -30 geht die CPU wie meine alter 5800x3d nur auf 78-81 grad

 

[LuxSkywalker]

du musst zwingend die corecycler Config anpassen sonst testet der mit prime - das ist nicht zielführend! - damit wird dein System nicht hart genug ausgelastet!

bitte lies dir den Thread einmal komplett durch...

 

[Katinka95]

Weiß garnicht wo ich da da anfangen soll

 

[eum3l]

Eine Alternative ist OCCT - da kannste auch die einzelnen Cores durchprüfen. Kostet halt 3-5 € im Monat ?! Ist aber monatlich kündbar.

Nur so als Tipp.

 

[Katinka95]

Hab’s mal auf avx512 umgestellt, hab in nem YouTube Video gesehen

 

[Bam_Bam]

@sp00n Ich nutze Asus x670e Gene und 9800X3D cpu. Wenn ich mit dem YC vt3 laufen lasse bekomme ich einen Fehler mit logischer Core Angabe. Die stimmt mit dem "echten Core" nicht überein. Ist das ein YC Fehler oder ein Fehler im BIOS? Test mit YC 8.5 (CC) und 8.6 zeigen die gleichen Auffälligkeiten.

Dabei ist egal ob ich CO im BIOS oder im SMUDebugTool anpasse.

 

[sp00n]

Hat zwar jetzt nichts mit CoreCycler zu tun, aber hab ich das richtig verstanden, y-cruncher zeigt dir einen Fehler bei logischem Kern (CPU) 10 und 11 an, also für den physischen Kern 5, aber nur wenn du stattdessen Kern 6 änderst, dann verschwinden die Fehler?

Das klingt in der Tat merkwürdig, y-cruncher hat auch eine GitHub-Seite, vielleicht ist es tatsächlich ein Bug dort.

Im CoreCycler wird die Erfassung/Erkennung der Kerne intern gehandhabt, da spielt die Ausgabe vom y-cruncher nur für die Fehlermeldung eine Rolle.

 

[Bam_Bam]

Ja genau so. Ein Beispiel:

Im CC sieht es dann so aus:

Es ist mir ein Rätsel. Vielleicht ist ja auch im BIOS 2806 von dem 670er Gene etwas nicht ganz in Ordnung?

 

[sp00n]

Ok, ich hab keine Ahnung. Sowas hab ich bislang noch nicht gesehen.

Y-cruncher stand-alone macht die Zuordnung zu den Kernen selbst, CoreCycler verwendet die Windows-API. Wenn beides fehl schlägt, dann deutet das eigentlich auf ein tiefer gehendes Problem hin.

Tritt das denn auch bei Prime95 oder Linpack auf?

 

[Vista]

Frage, ist die v0.10 Alpha 5 nun als Final anzusehen?

Release v0.10.0.0alpha5 (Release Candidate) · sp00n/corecycler

alpha5: Fixed a bug that prevented the automatic test mode to resume the test if the crash happened on core 0 (fixes #89) alpha4: Fixed a bug with Linpack's path AGAIN The Automatic Test Mode un...

github.com

 

[Bam_Bam]

Ok, ich hab keine Ahnung. Sowas hab ich bislang noch nicht gesehen.

Y-cruncher stand-alone macht die Zuordnung zu den Kernen selbst, CoreCycler verwendet die Windows-API. Wenn beides fehl schlägt, dann deutet das eigentlich auf ein tiefer gehendes Problem hin.

Tritt das denn auch bei Prime95 oder Linpack auf?

Bei schnelltest mit Allcore CO-40 passt bei Prime95 alles.

 

[sp00n]

@sp00n
Wann kommt die v0.10.0.0 Final?

Jetzt 😁


Hab jetzt endlich mal die 0.10.0.0 finalisiert:

Releases · sp00n/CoreCycler

Script to test single core stability, e.g. for PBO & Curve Optimizer on AMD Ryzen or overclocking/undervolting on Intel processors - sp00n/CoreCycler

github.com

Spoiler

Version 0.10.0.0 offers a new "Automatic Test Mode" For Ryzen 5000 and 7000 and Intel processors up to 14th gen, which will automatically adjust the undervolt value _upwards_ if a core has thrown an error.
To activate it you need to enable the `enableAutomaticAdjustment` setting in the config.ini. Additionally you can also enable the `enableResumeAfterUnexpectedExit` setting, which will try to resume the script if an unexpected crash of the computer has happened. Although for this to work correctly you would need to enable the automatic logon for Windows, otherwise the script cannot automatically restart.

More info can be found here:

Autologon - Sysinternals

Bypass password screen during logon.

learn.microsoft.com

Configure Windows to automate logon - Windows Server

This article describes how to turn on the automatic logon feature in Windows by editing the registry.

learn.microsoft.com

***Changelog:***

**Final:**

• The script now tries to find the stress test process more thoroughly (fixes #72)
• Now checking if the Windows Event Log service is running (fixes #101)
• Renamed WriteVerbose to WriteVerboseText and WriteDebug to WriteDebugText to prevent possible collisions with the built-in methods
• Disabled the "QuickEdit Mode" feature of the Windows command line terminal, which should prevent accidental script pauses
• You can now use "shortcuts" for y-cruncher (for example "19-ZN2" instead of "19-ZN2 ~ Kagari")

**alpha5:**

• Fixed a bug that prevented the automatic test mode to resume the test if the crash happened on core 0 (fixes #89)

**alpha4:**

• Fixed a bug with Linpack's path AGAIN
• The Automatic Test Mode unfortunately doesn't work with Ryzen 9000

**alpha3:**

• Added config presets for Automatic Test Mode
• Fixed a bug where Linpack wouldn't start from a directory including a space (fixes #84)
• Fixed a bug where resuming after a crash with a "default" `coresToTest` order would result in an index out of bounds error (fixes #85)
• Also it didn't resume on the crashed core
• The config file's content is now put into the log file for easier debugging
• Fixed a bug where the log file for y-cruncher was actually using the naming scheme for Linpack (under unclear circumstances, but it happened at least once)
• Fixed a bug when the update check doesn't return any output at all (fixes #83)

**alpha2:**

• Fixed a bug with the detection of the starting values (see #79)

**alpha1:**

• Added an automated test mode with automatic Curve Optimizer / voltage offset adjustment on error
• Added the possibility to automatically resume the script after a reboot via a Scheduled Task
• A WHEA warning/error can now be treated as a "real" error if the APIC ID matches the tested core
• See the `default.config.ini` for the new settings

 

[Vista]

Sehr gut, danke

 

[ApolloX]

kann man den core cdycler auch für ryzen 9000 verwenden?

Ja und Nein.

Ja, weil der natürlich ganz genauso für 9000er wie für alle anderen geht.
Nein, weils grad nichts bringt. Aktuell scheints so zu sein, dass diese "Per Core" Werte im Curve Optimzer nicht wirklich stimmen, bzw. nicht so funktionieren wie sie sollten. Und das ist ja die große Stärke des Core Cyclers. Wenn die Per Core aber grad ein Problem haben und ich eh mindestens die CO Werte fürs gesamte CCD stellen sollte, dann muss ich ja nicht kleinteiliger einzelne Kerne testen. Ne Quelle dafür hab ich keine, nur Hörensagen aus dem Netz.

 

[sp00n]

Hm, ich hab davon bislang nichts gehört. 🤔 Wo war denn das Hörensagen, vielleicht kann ich da mehr Infos finden.

Was allerdings definitiv der Fall ist, und was beim Ryzen 9800X3D vielleicht deutlicher sichtbar wird als bei anderen, "normalen" Ryzen-Chips, ist dass bei Multicore-Last die höchste benötigte Spannung eines der Kerne für alle Kerne verwendet wird. Theoretisch hätten sie wohl die Möglichkeit, auch da mit unterschiedlichen Spannungen zu laufen, aber AMD hat dies wohl für die Consumer-Chips deaktiviert. Demzufolge teilen sich dann alle Kerne eine Spannung, und das ist dann natürlich die höchste von all denen, die benötigt wird.

Der Ryzen 9800X3D hat ja den gleichen Takt für Multicore wie für Singlecore, und viele Leute testen den deswegen dann auch (nur?) mit Multicore, deswegen fällt das da vielleicht eher auf.


Und der automatische Testmodus funktioniert mit Ryzen 9000 (und 8000) derzeit nicht, weil der PBO2 Tuner, auf dem das Ganze basiert, vom Entwickler PJVol wohl nicht weiter geführt wird.
Ich bin mittlerweile auf ein neues Tool gestoßen (ryzen-smu-cli), da müssen aber noch ein paar Kinderkrankheiten ausgebügelt werden, bevor ich das einsetzen kann. Aber wenn das so weit ist, sollte die automatische Anpassung auch für Ryzen 9000 funktionieren.

In der Zwischenzeit könnte man bei Ryzen 9000 zB mit dem SMUDebugTool anstatt des PBO2 Tuners selbst die CO Werte ändern.

 

[sp00n]

Man müsste, so mache ich es per Hand, beim testen nur beim eben aktuell prüfenden Kern die Spannung anpassen und den Rest auf 0 setzen,
Sprich Kern0 wird am Anfang mit -25 getestet und der Rest bleibt auf 0, ist Kern0 erfolgreich ermittelt worden, setzt man Kern1 auf -25 etc. Nur eben das setzen was eben auch gerade getestet wird!
So scheiden Fehler von fremden Kernen die überhaupt nicht getestet werden eben komplett aus und man kann auch ohne Angst einfach normal beim testen weiterarbeiten.

Ich hab das in meiner aktuellen Entwicklerversion jetzt mal so eingebaut und hab gedacht "hey super, das wird toll!"... aber irgendwie ist genau das Gegenteil der Fall.
Mein 5900X ist mit dieser Art von Test auf einmal angeblich super stabil, wo ich mit -30 CO und +200 MHz auf allen Kernen vorher am laufenden Band Neustarts hatte mit Anpassung der Kerne, hatte ich bei einem Testlauf über Nacht gerade mal zwei Kerne, die von -30 auf -29 gegangen sind. 😵

Muss das mal noch weiter testen. Falls das noch jemand testen möchte, bitte melden.

// Edit
Ok, mittlerweile sehe ich mehr Aktivität, evtl. waren da noch ein paar Bugs vorhanden. Mal sehen, was er morgen so anzeigt.

 

[Bread]

Nette Idee, nur nicht zu Ende gedacht, weil widerspricht einer der ganz frühen Erkenntnisse, dass man die Kerne immer in voller Abhängigkeit voneinander testen muss. Sprich, die Spannungen der benachbarten Kerne beeinflussen einander. Selbst getestetes Beispiel: Test startet mit -25 auf allen Kernen, Core 0 läuft stabil bis zu -29 . Core 7 wird getestet, geht bis zu -28. Core 0 wieder getestet, plötzlich braucht dieser auch -28.

Deshalb immer alle auf einmal durchtesten, und den ersten der crashed halt raufsetzen. Wenn man es etwas methodischer angehen will, ich mache das so wie ich hier ausführlich beschrieben habe.

Generell plädiere ich dafür, nur noch in absoluten Spannungen = VID zu kommunizieren. Die CO Werte sind relativ zu einer je nach Hersteller unterschiedlichen VID-Baseline, dadurch ist das alles nicht vergleichbar. VID Werte sind 1:1 vergleichbar, daher imho viel nützlicher um schnell zu soliden Referenzwerten zu kommen - macht leider fast niemand, alle unterhalten sich in CO statt in VID.

 

[Vince96]

Thema Y-Cruncher im CoreCylcer für Ryzen 9000.
24-Zn5 Komari ausreichend oder gibt es bessere Alternativen?

Aktuell je 4 Iteration (24-Zn5 & 19-Zn2) mit einer pro Kernzeit von je 15min bestanden.
1h OCCT AVX2 bestanden (MT Workload)

Meine Kurve ist über den CurveShaper so eingestellt das im Idle kein Offset anliegt, um keine low Idle Freezes zu erhalten.

 

[Bam_Bam]

Ich verstehe die Vorgehensweise des Automaten nicht. Warum werden beim 9800X3D von 8 Cores 7 Cores auf 0 und nur einer auf -50 gesetzt und dann durchgetestet und dann der nächste auf -50 usw.? Wie soll man damit auf ein valides CO kommen?

Beitrag automatisch zusammengeführt: 15.04.2025

Ein Gedanke:
Um schnellstens an CO Werte (allcore) zu kommen habe ich festgestellt, dass YC VT3 für den 9800X3D gut geeignet ist.
Vorgehen:
z.B. Allcore -30 testen und mit co des ausfallenden Cores immer weiter hoch gehen bis er nicht mehr ausfällt (z.B. -12). Dann diesen Core nicht mehr testen und in YC deaktivieren. Mit den verbleibenden 7(14) Cores wieder "allcore" testen und mit co wieder hoch gehen bis der ausfallende core stabil bleibt. USW. Wäre das eine gute Variante?

 

[sp00n]

Gedacht ist die Einstellung in der Config, um Instabilitäten der anderen Kerne während des Testens auszuschließen, also eventuelle "falsche" Fehler, wie Abstürze, die z.B. durch Kern 0 verursacht werden, während gerade ein anderer Kern getestet wird.

Die Einstellung ist übrigens auch nur in der neuen Ryzen.AutomaticTestMode.Start.ini auf aktiv gesetzt, standardmäßig ist die nicht an, d.h. der Automatic Test Mode setzt weiterhin bei allen Kernen gleichzeitig die CO-Werte.

Wobei ich bei meinen kurzen Tests über Nacht erstmal keine Veränderung der CO-Werte mehr feststellen konnte, wenn ich von einer Nacht mit setVoltageOnlyForTestedCore = 1 auf eine Nacht mit = 0 gewechselt bin.
Allerdings waren die CO Werte bei einigen Kernen da auch noch teilweise weit von dem entfernt, was ich damals bei der Entwicklung von CoreCycler in vermutlich wochenlangen Tests herausgefunden hatte. Andere waren aber schon relativ nah dran.

Es ist halt wieder nur ein weiteres Tool im Werkzeugkasten und kein alleinheilbringendes Wundermittel.

// Edit
Dein Edit erst jetzt gesehen.
Der 9800X3D ist natürlich ein Sonderfall, da er die gleiche Frequenz bei AllCore wie bei Single Core erreichen kann, im Unterschied zu allen anderen Ryzen-Chips.
In dem Fall ist ein AllCore Testszenario tatsächlich viel nützlicher als bei den anderen Chips, da dort bei gleicher Frequenz durch den Vdroop eine niedrigere Spannung anliegt (sofern du die gleiche Frequenz erreichst natürlich).

Des Weiteren muss man allerdings beachten, dass bei einem AllCore-Test diejenige Spannung verwendet wird, die die höchste aller belasteten Kerne ist, d.h. die einzelnen CO-Werte haben dann nur bedingt Einfluss und werden gegebenenfalls "überschrieben". Also wenn z.B. ein Kern nach 1.175v verlangt, die anderen aber nur 1.15v, dann wird trotzdem für alle 1.175v angelegt.