CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[Bread]

"Falsch" - der neue yCruncher ist leider deutlich gutmütiger, imho nicht mehr brauchbar als Stresstest. Was wirft der YCRUNCHER_OLD mit dieser Config nach 6-12h?

[General]
# General settings
stressTestProgram = YCRUNCHER_OLD
numberOfThreads = 2

stopOnError = 0
skipCoreOnError = 1
beepOnError = 1
flashOnError = 1
lookForWheaErrors = 1

coreTestOrder = sequential
runtimePerCore = auto
#                                                        # runtimePerCore auto executes all the tests listed in the stressTestProgramgram section with the defined testDuration
suspendPeriodically = 1
#                                                        # Periodically suspend the stress test program to simulate load changes / switches to idle and back
restartTestProgramForEachCore = 1
#                                                        # restartTestProgramForEachCore 0 is default, and leaves the stressTestProgramgram window open so you can scroll thru to double-check for errors
delayBetweenCores = 5
#                                                        # delayBetweenCores 15 is default, 5 simply accelerates the test. If "restartTestProgramForEachCore" is 0, this setting has no effect

[yCruncher]
# y-Cruncher specific settings
mode = 19-ZN2 ~ Kagari
tests = N64, HNT, VST, C17
# testDuration = 30                                        # 30 to do a quick check only, 60 is default
# 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 "could not find the correct stress test window"

 

[raniell.o.bi.nnas]

@Vista
Bislang habe ich keine eindeutigen Fehlermeldungen für die Alpha-Versionen bekommen, also habe ich auch nichts gemacht. 😁

Theoretisch könnte ich die letzte Alpha dann also für die finale erste Version 0.10 nehmen.

Die Automatische Spannungsänderung ist Murks!
Das ganze setzt du ja über den beiliegenden PBO2Tuner um. Problem das Ding startet nicht immer mit.
Normal kommt dank der ZenStates-Core.sys/dll ja ne Warnung die man 512635612x bestätigen muss, die bleibt aber oft aus, ergo läuft das Ding auch nicht und die vermeintlichen Änderungen sind nur Placebos.
Weiter stimmen die Werte nicht überein.
Als Startwert habe ich mal bei einem CCD über all -20 gesetzt, diese Werte sind nach 2 Jahren testen garantiert nichts stabil bei mir.
Öffne ich den PBO2 Tuner oder den Ryzen SDT sieht man das die Gesetzen -20 real -10 sind. keine Wunder als das diese Werte dann angeblich stabil sein sollen.

 

[RedF]

Die Automatische Spannungsänderung ist Murks!
Das ganze setzt du ja über den beiliegenden PBO2Tuner um. Problem das Ding startet nicht immer mit.
Normal kommt dank der ZenStates-Core.sys/dll ja ne Warnung die man 512635612x bestätigen muss, die bleibt aber oft aus, ergo läuft das Ding auch nicht und die vermeintlichen Änderungen sind nur Placebos.
Weiter stimmen die Werte nicht überein.
Als Startwert habe ich mal bei einem CCD über all -20 gesetzt, diese Werte sind nach 2 Jahren testen garantiert nichts stabil bei mir.
Öffne ich den PBO2 Tuner oder den Ryzen SDT sieht man das die Gesetzen -20 real -10 sind. keine Wunder als das diese Werte dann angeblich stabil sein sollen.

Gibt ja noch mehr Tools die das können. Z.b. Ropbench von Kelutrel aus dem OCN.

 

[sp00n]

@raniell.o.bi.nnas
Die Anpassung der CO-Werte wird nicht von PBO2 Tuner übernommen, sondern von pbotest.exe. Vom gleichen Autor (PJVol), aber eben nicht das gleiche.

Bei dir scheint irgendwas Unvorhergesehenes vorzugehen. Hast du einen der CCDs deaktiviert? Der 7950X3D müsste eigentlich mit 16 Kernen & 32 Threads identifiziert werden, bei dir sind es nur 8/16.
Die Anzeige in den beiden Tools deutet auch darauf hin, dass da etwas nicht so ganz stimmt. Generell müsste man die CO Werte für alle Kerne definieren und nicht nur z.B. die für die ersten 8, ansonsten werden die Änderungen nicht durchgeführt. Da sollte dann allerdings auch eine entsprechende Fehlermeldung ausgegeben werden, die bei dir anscheinend aufgrund der falschen Erkennung der 16 Kerne nicht kommt.

Falls du einen der CCDs deaktiviert hast, dann aktiviere ihn mal und teste erneut. Wenn es dann geht, kann ich einen entsprechenden Hinweis in der Beschreibung für die Funktion hinzufügen. Oder evtl. gleich eine Warnung beim Starten ausgeben lassen.

 

[Major2312]

Für die X3D Nutzer, die ein Board mit ECLK haben.
Stellt euch einen ECLK mir z.b. 102 und ein PBO -100MHz ein, oder ECLK 104 und -200MHz

Das ändert das Boost verhalten zum positiven. Die 5050MHz beim 7800X3D bleiben, aber er bleibt länger am Limit.

Gibt es dazu auch irgendwo etwas beispielhaftes zum Vergleich oder so? Denn das hört sich interessant an!
Könnte ja beim encoding noch ein weiteres Prozent an Zeitersparnis heraus holen, CO-Tuning wird schon betrieben.

 

[RedF]

Gibt es dazu auch irgendwo etwas beispielhaftes zum Vergleich oder so? Denn das hört sich interessant an!
Könnte ja beim encoding noch ein weiteres Prozent an Zeitersparnis heraus holen, CO-Tuning wird schon betrieben.

Schlag was vor. : )

 

[sp00n]

Gibt es dazu auch irgendwo etwas beispielhaftes zum Vergleich oder so? Denn das hört sich interessant an!
Könnte ja beim encoding noch ein weiteres Prozent an Zeitersparnis heraus holen, CO-Tuning wird schon betrieben.

Der Boostclock wird vermutlich anhand des Multilpliers erkannt und nicht anhand der tatsächlichen Frequenz. Ebenso die angefragte Spannung auf der Voltage/Frequency Kurve (V/F Curve).

Dadurch verschiebt ein Anheben des BCLCK bzw. hier halt ECLCK die gesamte Kurve und der Prozessor taktet höher bei gleicher Spannung (Vcore).

Bei Intel ist es ziemlich gleich, dort könnte man auch einen Offset für einzelne "V/F-Punkte" setzen, das ist so ähnlich wie Curve Optimizer, nur eben für bestimmte Punkte auf der Kurve einzeln. Und die "Frequency" auf dieser Kurve wird auch nur anhand des Multiplikators erkannt, hebt man also den Basistakt an, den dieser Multiplikator multipliziert (😬), dann verschiebt sich auch hier die Kurve hin zu mehr Frequenz, ohne dass der Vcore dafür steigt.

 

[Major2312]

Okay, dann könnte man rein theoretisch die selbst ermittelten CO-Werte mit eCLK=Auto(100MHz) und PBO +-0MHz auch nutzen um eCLK=102MHz und PBO -100MHz zu realisieren!?
Und unterm Strich noch testen wo es einem im Alltag etwas bringt das so zu betreiben . . .

 

[sp00n]

Vermutlich schon. Oder noch höher übertakten.

SkatterBencher hat die ECLK benutzt, um den maximalen Boosttakt zu erhöhen, hat dafür dann allerdings auch einen positivten CO Offset verwendet.

SkatterBencher #60: AMD Ryzen 7 7800X3D Overclocked to 5400 MHz - SkatterBencher

We overclock the AMD Ryzen 7 7800X3D up to 5400 MHz with the ASUS ROG Crosshair X670E Hero motherboard and EK-Quantum water cooling.

skatterbencher.com

"ECLK also affects the maximum frequency ceiling. With an ECLK of 105 MHz, the newly programmed Fmax for the 7800X3D is 5050 MHz x 1.05 = 5303 MHz. If that’s too high for your CPU, you can always reduce the Fmax by setting a negative CPU boost clock override."

Und da hab ich grad gesehen, dass der zum Testen auch CoreCycler verwendet. 😁

 

[hoeki2010]

Moin zusammen,
habe mir nen 9800X3D gegönnt und würde gerne den CO ausprobieren.
Welches Setting sollte man am besten nehmen um schon vorab auszuloten obs einigermaßen Stabil läuft?
Hätte vielleicht sogar jemand ein Setting für mich parat?

Ich danke euch und einen schönen Tag.

 

[TingelTangel]

Guten Tag in die Runde,

ich habe als alternativen Stabilitätstest festgestellt, dass War Thunder sehr schnell beendet wurde, wenn die Cores Probleme gemacht haben.

Entweder war ich auf dem Desktop, Bild eingefroren im Spiel oder der PC hat sogar einmal neu gestartet.

Zuvor war in den Test CC kein Fehler aufgetaucht. Oder halt, wie weiter oben vorgeschlagen, parallel CC laufen lassen und schauen, ob dort die fehlerhaften Cores angezeigt werden.

Nur so als Idee zum Testen der Hardware.

 

[KristallBurgen]

Hallo miteinander,

ich habe gestern etwas komisches mit CoreCycler erlebt und hoffe, dass mir hier vielleicht jemand helfen kann zu verstehen, was da passiert ist.

Ich habe mir erstmal die Config eingestellt und wollte kurz schauen ob alles glatt läuft, bevor ich das dann über Nacht laufen lasse. Dabei habe ich dann mit dieser Config nach ~1 Minute auf dem 2. Core einen Error bekommen:

Spoiler: Config

[General]

stressTestProgram = YCRUNCHER
runtimePerCore = auto
coreTestOrder = Sequential
numberOfThreads = 1


[yCruncher]

mode = 19-ZN2 ~ Kagari
tests = BKT, BBP, SFTv4, SNT, SVT, FFTv4, N63, VT3
testDuration = 10
memory = 26GB


[Debug]

stressTestProgramPriority = AboveNormal

Besonders zu beachten sind "testDuration = 10" und "memory = 26GB". "testDuration" habe ich kurz eingestellt, um zu sehen ob die "auto" runtime funktioniert und wirklich zum nächsten Core gesprungen wird, und "memory" hatte ich so hoch, weil ich y-cruncher sonst immer nur mit allen Threads benutzt hatte und vergaß, dass das Ganze hier ja nur auf einem Thread läuft.

Die Fehlermeldung ist im Anhang (y-cruncher und CoreCycler logs)

Jedenfalls habe ich dann probiert diesen Fehler zu reproduzieren, was mir allerdings nicht gelang. Ich habe dann einmal den Rechner neu gestartet und das Ganze über Nacht laufen lassen (und vorher "testDuration" auf 300 gesetzt und "memory" auf 25MiB), und das ist ohne Fehler durchgerattert.

Jetzt meine Frage: Dieser Fehler, den ich gestern Abend bekommen habe - war das wirklich eine Instabilität? Wenn der Fehler bereits ~1 Minute nach Start auftritt, muss der über Nacht doch nochmal auftreten. Oder war das ein Bug weil ich "memory" auf 26GB hatte? Wobei dieser Fehler auch bei mehrmaligem Versuchen mit "memory" auf 26GB nicht wieder auftrat.

 

[sp00n]

@KristallBurgen

Das war ein "CPULOAD" Error ("The y-cruncher process doesn't use enough CPU power anymore (only 0ms instead of the expected 2000ms"). Kann durchaus sein, dass das von den 26GB verursacht wurde, evtl. war da y-cruncher noch mit beschäftigt, den RAM aufzufüllen.
Wenn es nicht nochmal auftritt, ignoriere das einfach erstmal.

Wenn man so viel Speicher freigibt, dann testet man natürlich auch den RAM mit, womit man nicht so ganz sicher sein kann, ob ein Fehler jetzt von der CPU oder vom RAM kam.

 

[KristallBurgen]

@sp00n Danke für die Antwort!

Ja dann lag das bestimmt daran, dass ich zuviel Speicher zugewiesen habe... Ich teste heut Nacht dann nochmal mit prime95 statt y-cruncher, und wenn da auch kein Fehler erkannt wird, reicht mir das 😁

Gibt es irgendwo eine genauere Erläuterung dieses Fehlers (und auch anderer Fehler, die auftreten könnten)? Verstehe den Output bezüglich des Errors nicht wirklich... Was genau hat Zeit (0ms instead 2000ms) mit zu geringer CPU Power zutun?

 

[Techlogi]

@Tundor hiermit testest am besten.

 

[sp00n]

@KristallBurgen
Eine Auflistung gibt es nicht, die Fehler kommen in der Regel von den Stresstestprogrammen selbst und sind dann tatsächliche Hardwarefehler (eben durch zu wenig Spannung / zu hohem Takt).

Dieser CPULOAD Fehler ist ein wenig anders, da schaut das Skript, wieviel Auslastung das Stresstestprogramm innerhalb einer definierten Zeitspanne auf dem zu testenden Kern verursacht hat. Das Ganze wird in Millisekunden zurückgegeben, in deinem Fall waren das 0ms innerhalb von 2000ms, also gar nichts innerhalb von 2 Sekunden, wobei das Skript intern 8 Sekunden lang schaut und erst dann einen Fehler wirft.

Das könnte durch die Speicherzuweisung verursacht worden sein. Manchmal wird das auch durch instabile Settings verursacht und geht dann mit mehr Spannung weg. Und auf manchen Systemen funktioniert die Erkennung an sich aber aus irgendwelchen Gründen nicht zuverlässig, dann kann man die komplette Sache in der Config auch deaktivieren.

 

[Anarchist]

nachdem -30 auf jeden Fall instabil bei mir ist auf allen Cores, weil Freeze im CB23 versuche ich herauszufinden warum.
Core Cycler rennt und rennt bisher. Ich hab heute Nacht 12 Stunden laufen lassen, ohne Probleme. Aber evtl. wegen zu schwachen Default Einstellungen im Programm.
Hab jetzt mal 24-ZN5 ~ KOMARI laufen, immer 10min und er soll bei Fehler komplett stoppen. Ich lass das jetzt mal mehrere Stunden laufen, evtl. bis morgen wenn nichts passiert.

Wenn der aber nichts findet ist es ziemlich unbrauchbar irgendwie. CB23 hatte den Freeze beim normalen 30min Stabilitäts Run

 

[Anarchist]

Core1 hat mir im Y-CRUNCHER 24-ZN5 jetzt Fehler geworfen. Bin dann mal von -30 auf -25 jetzt für diesen Core und hab wieder CB23 laufen lassen -> Freeze nach 15min

Aktuell läuft wieder der Core Cycler

 

[LuxSkywalker]

teste mit

• stressTestProgram = YCRUNCHER_OLD
• mode = 19-ZN2 ~ Kagari

die anderen Optionen sind zu lasch beim testen, die belasten die enzelnen Cores nicht ausreichend. Damit kannste dir das ganze auch sparen

...aber das ist in diesem Thread auch schon lang durchgekaut worden ^^ ja ich weiß es sind 14 Seiten, ohne lesen und einarbeiten wird das aber nix

 

[Anarchist]

werde ich auch testen danke.
bisher schlägt der 24-ZN5 aber auch schon an. mal schauen aktuell 2 cores die mit -30 nicht mögen.

 

[Bimer]

Habe Offset auf - 0,1 V gestellt und CO auf -20.


Gilt offensichtlich nur bei Einzelkernauslastung. Ich war mir nicht sicher, ob das MB überhaupt bei dem Offset startet.

 

[Ranz405]

Hallo
Ich habe mal wieder etwas rumgespielt, nachdem mein BIOS Update alle Settings zurückgesetzt hat.

Habe zuerst DOCP aktiviert und eingestellt
Dann PBO aktiviert mit Limits 200, 140, 180 und danach den Ryzen Master Curve Optimizer genutzt.
Danach dann nochmal den Corecycler und der hat mir zumindest auf dem 1. CCD die Offsets weit zurück gedreht.

Nun habe ich zwar Allcore 4,8Ghz in Call of Duty B06 z.B. und 4,7-4,75Ghz unter Cinebench23. (Was ich sehr beachtlich finde)

aber trotz um >200Mhz gestiegenem Allcore Takt ist der Cinebench Wert minimal gesunken. Ergibt das Sinn?

Hier meine Ergebnisse des Corecycler

 

[sp00n]

Hast du auf Clock Stretching geachtet in HWiNFO (Core Effective Clocks vs. Core Clocks)?

 

[Ranz405]

Hast du auf Clock Stretching geachtet in HWiNFO (Core Effective Clocks vs. Core Clocks)?

hmm, ich weiß dass der Wert da ist, aber mehr habe ich den noch nie beachtet.

TL: DR was sagt der aus?

 

[Ranz405]

ok, hab´s grob erlesen was das ist.
Was mach ich dagegen oder wie sollte ich neu anfangen?

 

[Bread]

Ich teste mit YCRUNCHER_OLD, also vor allem HNT, VST, C17. Ist der härteste mir bekannte Test. Damit ist das bombenstabil, und auch kein Clock Stretching, was mir logisch erscheint, weil auf "ausreichende Mindest-Spannung" für die härteste mögliche Vollbelastung für jeden Core getestet wurde.

 

[yehudarodrig]

Das Tool finde ich klasse, es hat aber einen fetten Fehler bzgl. der Umsetzung mit der automatischen Schrittanpassung der Spannung.
Standard sind ja -25 auf allen Kernen ...
Ich habe einen 7950X3D und betreibe den auch mit 200Mhz PBO, die 3D Kerne Takten aus politischen Gründen ;-) ja nicht so hoch wie die normalen. AMD fährt nur eine Einheitspannung dank nur einem Spannungswandler. Sprich es ist die natur das die 3D Kerne mehr Luft nach unten haben als die nicht 3D Kerne die eher an der Kotzgrenze laufen.
Ich poste mal meine stabilen Werte abzüglich -1 als Reserve für schlechte Fälle:

-25, -25, -23, -25, -16, -25, -21, -25,
-14, -10, -04, -07, -05, -09, -17, -13,

Lege ich jetzt am Start bei allen Kernen -25 an und Teste Kern1 braucht Windows nur mal einen Zucker auf Kern 11 zu machen der eben bei -4 bereits abschmiert, der Fehler wird dann aber natürlich dem Kern1 zugeschrieben der dann unnötig runter gesetzt wird. Bei so vielen Kernen ist es reine Glücksache nach dem System durch zu kommen! Das bei der Umsetzung nichts valides raus kommt wird man merken wenn man mehrfach kreuzweise die Testreihenfolge ändert, es kommen da gravierende Unterschiede raus. Je mehr schlechte Kerne man zuerst trifft desto genauer wird dann das Ergebnis. Mit dem Standardablauf würde so mancher Kern bei mir auch im Plus laufen obwohl es ein guter -25 Kern ist!
Man kann in der Config löblich ja auch zu beginn jedem Kern eine Spannung zuteilen, bringt nur erst mal nix ohne jeden Anhaltspunkt.
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.
Hat man einmal die Reihe einzeln durch kann man alle Kerne noch mal mit ihrer ermittelten Spannung zusammen durchjage (optional)

zumindest den Einzeltest würde ich als fauler äh Mensch ohne Zeit zumindest mal grob in >=5 Schritten abstecken um zu sehen wo die schlechten Kerne sind. Es bringt noch mal wie gesagt überhaupt nichts wenn man Kerne bei der Spannung beschneidet die aber nicht geprüft werden und von Windows dann eben trotzdem genutzt werden und bei einer falschen Mausbewegung das System neu starten kann.
Ganz faule können das sogar on-the-fly mit dem PBO2Tuner oder SMUDebugTool machen um zu sehen wann ihre Kiste abschmiert, dazu muss man nicht ewig testen. Wirklich zuverlässig lässt sich mit Corecyler auch erst arbeiten wenn man nicht mehr über den Punkt kommt wo das System komplett abstürzt.
Auch könnte man Fehler durch falsche Kerne minimieren wenn man im Bios ein CCD abschaltet, dann hat aber Coreycler ein Problem mit der Kern Zuordnung, Weder passt dann die Anzeige Corycycler zu YCruncher zu Taskmanger, letzterem traue ich da eher, noch passt die gesetze Spannung dann. CCD Abschalten per manuellem Test ja immer, automatisch beim Stand heute auf keinen Fall, das gibt auch nur Blödsinn.
Oder man bescheißt sich selbt in dem man nur Standardtest mit Prime macht, da komm ich dann auch überall auf -30er Werte und habe eine Gold CPU.

 

[el_froggo]

Ich hab mittlerweile so viel Zeit mit einem 5800x sowie 5900x in potenzielle Optimierung (inkl. RAM) gesteckt, da hätte ich mir auch gleich ne neue CPU bzw Konfiguration gönnen können.
So tricky und unterschiedlich (je batch / cpu) war das wie mit CO/PBO meiner Meinung nach noch nie. Da würde ich lieber ein Bleistiftmod machen und entspannt den fsb oder multi erhöhen oder irgendwas an GPUs löten, Bios flashen etc. und relativ schnell ein Maximum bzw Optimum finden.
Die CPUs sind wirklich nicht mal eben feingetuned...

 

[WinsBins]

Moin,

bräuchte da mal Hilfe.
bekomme immer mal wieder zwischendurch den Fehler "Could not read CCD fuse!"

hab ich der config irgendwas falsch?
der y-cruncher läuft dabei trotzdem weiter aber das "Kern-Fenster" aktualisiert sich nicht weiter.

Ist natürlich doof, weil das automatische Neu starten nach blackscreen anfangs super funktioniert hatte, kommt jetzt nicht mehr, da die Kerne schon besser ausgelotet sind.
Man sieht dann nur nicht mehr die Kerne durchlaufen und die Änderung des CO Werts.

Danke

 

[sp00n]

@WinsBins
Der Fehler scheint von der ZenStates Bibliothek zu kommen, die dabei verwendet wird. Allerdings kann ich dir da auch nicht weiterhelfen, ich sehe das jetzt zum ersten Mal. 😕
Vielleicht könntest du dort ein Issue erstellen, das wird zwar jetzt nicht weiterhelfen, aber könnte vielleicht zumindest eine Erklärung bringen, was da los ist.

@yehudarodrig
Hmm, das klingt nach gar keiner so schlechten Idee, den CO-Wert nur für den getesteten Kern zu setzen. Muss ich mal als Feature Request eintragen und wenn ich mal wieder Zeit habe drüber nachdenken.