CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[XTaZY]

Danke für das Tool, @sp00n

Negative -20 lief probemlos bisschen mehr als 24 Stunden durch:

╔══════════════════════════════════════════════════════════════════════════════╗
╟──────────────────────────────────┤ Summary ├─────────────────────────────────╢
╚══════════════════════════════════════════════════════════════════════════════╝

Run time:     1 days, 02 hours, 52 minutes, 34 seconds
Iterations:   17 started / 16 completed
Tested cores: 16 cores / 268 tests
              Core 0 (17x), Core 1 (17x), Core 2 (17x), Core 3 (17x), Core 4 (17x)
              Core 5 (17x), Core 6 (16x), Core 7 (16x), Core 8 (17x), Core 9 (17x)
              Core 10 (17x), Core 11 (17x), Core 12 (17x), Core 13 (17x), Core 14 (16x)
              Core 15 (16x)

────────────────────────────────────────────────────────────────────────────────

No core has thrown an error

No WHEA errors were observed during the test

────────────────────────────────────────────────────────────────────────────────

Negative -24 läuft grad während ich auf der Arbeit bin.
Denk 24 Stunden Belastungstest für 16 Kerne sollten doch eigentlich ausreichenend, hm ?

 

[Datanette]

Würde mich da nicht allzu stark auf nur einen spezifischen Test versteifen.
Das kann 48Std fehlerfrei laufen und beim ersten realen Einsatzszenario kackt es ab.
Stark wechselnde und unterschiedliche Belastungen sind die härteste Anforderung und meist mit Games oder Grafikbenchmarks zu erreichen. Große Dateien entpacken ist auch sehr fordernd genauso wie wakeups aus dem Idle.

Ist es mit dem CoreCycler eigentlich möglich, automatisch und stetig zwischen verschiedenen Benchtools zu wechseln?

 

[RedF]

Würde mich da nicht allzu stark auf nur einen spezifischen Test versteifen.
Das kann 48Std fehlerfrei laufen und beim ersten realen Einsatzszenario kackt es ab.
Stark wechselnde und unterschiedliche Belastungen sind die härteste Anforderung und meist mit Games oder Grafikbenchmarks zu erreichen. Große Dateien entpacken ist auch sehr fordernd genauso wie wakeups aus dem Idle.

Ist es mit dem CoreCycler eigentlich möglich, automatisch und stetig zwischen verschiedenen Benchtools zu wechseln?

Vor allem kleine Boost Spitzen können da kritisch werden.

Beitrag automatisch zusammengeführt: 30.09.2024

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.

 

[XTaZY]

Würde mich da nicht allzu stark auf nur einen spezifischen Test versteifen.
Das kann 48Std fehlerfrei laufen und beim ersten realen Einsatzszenario kackt es ab.
Stark wechselnde und unterschiedliche Belastungen sind die härteste Anforderung und meist mit Games oder Grafikbenchmarks zu erreichen. Große Dateien entpacken ist auch sehr fordernd genauso wie wakeups aus dem Idle.

Ist es mit dem CoreCycler eigentlich möglich, automatisch und stetig zwischen verschiedenen Benchtools zu wechseln?

Aktuell handhab ich es so:
- 1x Run CB23 Multicore
- 1x Run 3Dmark TimeSpy
- 1x Run 3Dmark TimeSpy Extreme
- 1x 10 Min. CB23 Multicore
- 1x 30 Min. 3Dmark TimeSpy Extreme Stresstest
- 1x 24 Std. CoreCycler

Wie sich die PBO2 Einstellung dann final im Alltag dann bewahrheitet, wird sich dann zeigen

 

[Datanette]

Okay, das ist ja reichlich. Fehlt nur noch 24h Idle.

Ich habe viel weniger synthetisch getestet und startete relativ schnell mit dem finalen BS und den gewünschten Anwendungen. Zudem hilft ein großzügiges Sicherheitspolster z.Bsp. alle Cores 5 steps zurück vom ausgeloteten CO.
Grundlegend ist, dass man die maximal mögliche Taktfrequenz schon gewählt hat, respektive auch die Kühlmethode und das daraus resultierende Powertarget. Ansonsten muss man wieder von vorne beginnen.
Stündliche Backups sichern bei mir in der Testphase das System soweit ab, dass bei einem eventuell auftretenden Fehler gleich zurückgespielt werden kann und kein Risiko besteht, dass das BS beschädigt ist.

 

[Vista]

@sp00n
wie schaut es mit der Entwicklung der v0.10 Version aus ?

 

[sp00n]

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

 

[TingelTangel]

Bei meinem Ryzen 7800x3d lief der CoreCycler ohne Fehler durch mit AllCore -30.
Bei Prime95 sind dann 4 Kerne mit Fehler kurz nach dem Starten gestoppt.
Die Fehler auf den Kernen waren ziemlich zügig vorhanden.

Aktuell läuft alles bei -30 -32 -28 -25 -15 -20 -25 -28

Vielleicht habe ich auch etwas falsch getestet.

 

[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?