CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

Danke für das Tool, @sp00n :wink:

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

Code:
╔══════════════════════════════════════════════════════════════════════════════╗
╟──────────────────────────────────┤ 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 ? :)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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?
 
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:

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.
 
Zuletzt bearbeitet:
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
 
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.
 
@sp00n
wie schaut es mit der Entwicklung der v0.10 Version aus :)?
 
@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.
 
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.
 
"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?

Code:
[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"
 
@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.
 

Anhänge

  • Screenshot 2024-10-29 100618.jpg
    Screenshot 2024-10-29 100618.jpg
    124,5 KB · Aufrufe: 51
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.
 
@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.
 
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.
 
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. : )
 
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.
 
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 . . .
 
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.

"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. 😁
 
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. :)
 
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.
 
Zuletzt bearbeitet:
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:

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

Anhänge

  • CoreCycler_2024-11-14_03-00-09_YCRUNCHER_19-ZN2 ~ KAGARI.txt
    83,2 KB · Aufrufe: 18
  • yCruncher_2024-11-14_03-00-09_mode_19-ZN2 ~ KAGARI.txt
    6,1 KB · Aufrufe: 21
@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.
 
@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? :confused:
 
@Tundor hiermit testest am besten.
 
@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.
 
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
 
Dauertests bringen nicht allzu viel. Es kommt mehr auf die verschiedenen Scenarien an.
Wenn CB23 crasht kannst du ja bestens damit den Fehler suchen. Zuerst auf den CCD beschränken und nachher auf den Core, wenn das überhaupt möchtest.
 
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 :d

Aktuell läuft wieder der Core Cycler
 
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
 
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.
 
Habe Offset auf - 0,1 V gestellt und CO auf -20.
4.jpg

Gilt offensichtlich nur bei Einzelkernauslastung. Ich war mir nicht sicher, ob das MB überhaupt bei dem Offset startet.
5.jpg
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh