CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

Den zweiten Abschnitt verstehe ich nicht ganz, inwiefern mehrmals starten? Das Fenster sollte sich immer aktualisieren, wenn es das nicht tut, dann hat man evtl. unbeabsichtigt etwas im Fenster markiert, was die Skriptausführung stoppt.
Core Cycler hatte ich per 2x CRTL+C abgebrochen, aber scheinbar lief es noch weiter, ich hatte es nochmals gestartet und dabei ist die CMD Ausgabe nicht mehr aktualisiert worden.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo,

ich mache mit meinem 8700K gerne PerCore OC, weil das erscheint mir einfach viel sinnvoller, als AllCore OC. Das Tool geht auch für Intel? Müßte ja, weil es ist ja im Grunde nur Prime spezifiziert laufen lassen.

Ist Intel PerCore OC das gleiche wie bei AMD das PBO? (Kenne mich mit AMD nicht so aus).

24h pro Kern ist halt sehr lange, das würde ja beim 8700K 144h dauern. Kann man das nicht optimieren? Im Grunde müßte es reichen, wenn 12K, 512K, 672K, 768K und 800K geprüft werden. Damit deckt man alles Wichtige ab.

Früher habe ich mit CB R15 SingleTest getestet, bin jetzt aber zum Defender übergegangen, Schnellüberprüfung und danach Vollüberprüfung. Da wird alles abegedeckt von Einkernlast bis Teillast und Vollast.
Dabei achte ich auf WHEAs. HWinfo64 läuft bei mir immer mit. Ein paar CPUz Benches mach ich auch noch.

Und dann halt zocken, weil wenn was passiert, dann passiert es meistens dort.

Aber super Idee mit dem CoreCycler (y) .
 
ich mache mit meinem 8700K gerne PerCore OC, weil das erscheint mir einfach viel sinnvoller, als AllCore OC. Das Tool geht auch für Intel? Müßte ja, weil es ist ja im Grunde nur Prime spezifiziert laufen lassen.

Ist Intel PerCore OC das gleiche wie bei AMD das PBO? (Kenne mich mit AMD nicht so aus).

24h pro Kern ist halt sehr lange, das würde ja beim 8700K 144h dauern. Kann man das nicht optimieren? Im Grunde müßte es reichen, wenn 12K, 512K, 672K, 768K und 800K geprüft werden. Damit deckt man alles Wichtige ab.
Ich hab schon länger keine Intel-CPU mehr gehabt, aber theoretisch sollte es auch dort funktionieren.
Bei den neuen Modellen mit E-Cores ohne einen zweiten virtuellen Kern müsste man diese aber vermutlich per coresToIgnore bzw. coreTestOrder ausschließen und separat testen.
Man kann in der Config auch nur bestimmte FFT-Größen einstellen, allerdings bislang nur als Range und nicht als Auflistung, das wäre evtl. eine Idee für ein Update. Wobei ich weiterhin der Meinung bin, dass für einen finalen Stabilitätstest alle FFT-Größen durchlaufen werden sollten. Aber für eine schnelle Einordnung wäre das gar nicht so verkehrt.


Core Cycler hatte ich per 2x CRTL+C abgebrochen, aber scheinbar lief es noch weiter, ich hatte es nochmals gestartet und dabei ist die CMD Ausgabe nicht mehr aktualisiert worden.
Ich kann dir da nicht ganz folgen.
Wenn du per CTRL+C abbrichst, dann versucht das Script, Prime95 (bzw. das gewählte Stresstestprogramm) zu beenden. Das kann teilweise nicht funktionieren, entsprechend steht da dann auch eine Meldung im Terminal.
Und wenn du das Script mit der Batch-Datei startest, öffnet sich ja ein neues Fenster, das alte sollte sich dann auch automatisch schließen. Und auch, wenn du das .ps1 Script direkt aus einem PowerShell-Terminal startest, sollte es eine normale Ausgabe anzeigen.
Wobei ich den Start aus PowerShell selbst heraus nicht empfehle, da kann es Probleme mit gecachten Performance-Countern geben, die sich auf die Fehlererkennung auswirken.
 
Hey, super Tool das extrem nützlich ist beim CO ausloten! Ein Problem hab ich allerdings damit:
  1. Bei Core 5 wirft "Logical Core 3" nen Error.
  2. Ich warte ab, das Fenster verschwindet (soll ja auch ein unattended Test sein)
  3. Core 6 Test beginnt
  4. Ich breche mit Ctrl-C ab
  5. Mir wird mitgeteilt "alles gut, keine Fehler"?!
Passiert übrigens zur Zeit nur bei C17 offenbar - als ob der keine Fehler an das Skript zurückliefern würde?
Screenshots unten für bessere Nachvollziehbarkeit!

1682323133325.png


1682323165816.png
 
@LuxSkywalker
hatte ja -20 auf allen .
Sehe ich das richtig das Core 3 Fehler gemacht hat?
Im Biois wäre das dann CPU Core 3 ?

Y Cruncher.jpg
 
korrekt, dann erstmal -18 testen - wenn das auch nicht stabil ist mit -16 usw

willst du denn bei AllCore bleiben oder per Core ausloten?

und btw. wie ich schon zuvor schrieb manchmal steigen einzelne Kerne auch erst im zweiten Durchlauf aus - exakt wie bei dir ^^

daher macht es durchaus Sinn nicht schon nach einem Durchlauf das ganze als stabil zu betrachten :sneaky:
 
Zuletzt bearbeitet:
korrekt, dann erstmal -18 testen - wenn das auch nicht stabil ist mit -16 usw

willst du denn bei AllCore bleiben oder per Core ausloten?

und btw. wie ich schon zuvor schrieb manchmal steigen einzelne Kerne auch erst im zweiten Durchlauf aus - exakt wie bei dir ^^

daher macht es durchaus Sinn nicht schon nach einem Durchlauf das ganze als stabil zu betrachten :sneaky:
Mache gerade per Core bzw habe gerade darauf umgestellt.
Hab jetzt für Core 3 negativ 17 den Rest auf 20 belassen.
Kann man irgendwas auf die SP geben die für jeden Core zugewiesen wird ?Wenn ich die 5 Runs schaffe wollte ich die restlichen 7 auf 25 setzen und schauen welcher dann aussteigt?
 
hört sich gut an. da die anderen Kerne -20 wohl problemlos mitmachen kannst die die auch etwas höher setzen -22 z.B.

jeder Schritt entspricht soweit mir bekannt 2-3mV an vCore - ist wohl abhängig vom MB und weiteren Einstellungen wie CPU LLC etc

jetzt heißt es rantasten an die optimalen Einstellungen. Viel Erfolg 😄
 
hört sich gut an. da die anderen Kerne -20 wohl problemlos mitmachen kannst die die auch etwas höher setzen -22 z.B.

jeder Schritt entspricht soweit mir bekannt 2-3mV an vCore - ist wohl abhängig vom MB und weiteren Einstellungen wie CPU LLC etc

jetzt heißt es rantasten an die optimalen Einstellungen. Viel Erfolg 😄
Ja ich hab da neulich ein Video gesehen da sag der 3-5 mv für einen Punkt wie du sagst wird bestimmt am Board liegen .
Hieße dann irgendwas zwischen 9 -15mv bei 3 punkten.
Danke erstmal für deine Hilfe :wink:
 
Macht das eigentlich einen Unterscheid bei den realen FPS oder nur bissl kühler halt?
 
Macht das eigentlich einen Unterscheid bei den realen FPS oder nur bissl kühler halt?
Beim undervolting Boostet die CPU höher also etwas mehr Takt in Summe dann etwas schneller.
Ist nicht die Welt aber bei meiner CPU sind das um 200mhz mehr in the Last of us zu Stock.
 
Aber wohl eher messbar als spürbar oder lohnt sich das außerhalb vom Spaß an der Sache? (Den ich durchaus nachvollziehen kann 😅)
 
Aber wohl eher messbar als spürbar oder lohnt sich das außerhalb vom Spaß an der Sache? (Den ich durchaus nachvollziehen kann 😅)
Ja natürlich ehr mess bar fühlt sich aber gut an wen das System optimiert ist.
Bei etwas weniger wärme etwas mehr Leistung ist doch fein.
TEST lief jetzt in 5 Instanzen durch.
-17 auf dem Core 3 war wohl ein Volltreffer.
Ich habe jetzt meine ganzen Scharfen Subtimmings zurück gestellt und versuche jetzt 6000 MHZ mit Cl 30 mit so wenig Spannung wie geht laufen zu lassen.
Auch die SOC voll runter drehen dann mach ich mit dem Curve optimzer weiter.
Bin gespannt was man da noch so einstellen kann.
Gruß
 
Zuletzt bearbeitet:
Hey, super Tool das extrem nützlich ist beim CO ausloten! Ein Problem hab ich allerdings damit:
  1. Bei Core 5 wirft "Logical Core 3" nen Error.
  2. Ich warte ab, das Fenster verschwindet (soll ja auch ein unattended Test sein)
  3. Core 6 Test beginnt
  4. Ich breche mit Ctrl-C ab
  5. Mir wird mitgeteilt "alles gut, keine Fehler"?!
Passiert übrigens zur Zeit nur bei C17 offenbar - als ob der keine Fehler an das Skript zurückliefern würde?
Screenshots unten für bessere Nachvollziehbarkeit!

Anhang anzeigen 880480

Anhang anzeigen 880481
Den Thread hatte ja eigentlich ich wiederbelebt, mit Post hier - dann grätscht du mit Deinem Problem rein und meins geht unter :d

Anyone ne Idee? Im Core 5 oder 6 Test wirft Logical Core 3 (?) nen Fehler, der aber nachher nicht in der Zusammenfassung angezeigt wird, als ob es kein Problem gegeben hätte?
 
nope, einfach doppelklick auf die .bat
 
Kommt dann ein Admin-Prompt ("Ja klicken"), oder nicht?
 
nö, es startet direkt die Kommandozeile und das Script startet
 
Zuletzt bearbeitet:
Und Du drückst nicht "beliebige Taste" im Y-Cruncher Fenster bei einem Fehler, sondern CoreCycler läuft durch, und Du siehst nachher dass ein Fehler war?
Wenn ja: ev funzt das bei mir nicht, weil ich PowerShell nutze zum starten des CoreCycler? Versuche es mal wie Du mit Doppelklick ;)
 
wenn ein Fehler auftritt sehe ich das in der cmd-line wie in @Thunderburne seinem Post - etwas runter scrollen Error dick in lila
 
Danke - das Problem ist, siehe mein Post oben: ich sehe das nicht!
Und ich denke es liegt nicht an meinen Augen, siehe Screenshot. Es gibt definitiv Fehler, aber die tauchen nur in der CMD auf wenn ich aktiv "any key" drück im Y-Cruncher Fenster bei einem Fehler. Sonst merk ich die Fehler nicht.

Bist Du zufällig auf Win 10 unterwegs?
Ich auf Win 11. Versuche herauszufinden warum es bei Dir so schön funzt und bei mir nicht...
Beitrag automatisch zusammengeführt:

Ergänzung: welchen Test fährst Du? Ich Kagari.
 
ich hab Win 10

Kagari passt - der stresst mein System am härtesten ^^
 
Alles klar - bei mir auch, in meinem Fall isses HNT - bei anderen C17, wieder anderen N64 ;)
Habe die Lösung für das "muss Y-Cruncher zuschauen" Problem gefunden. Und ein stabiles 8h30 CoreCycler Y-Cruncher HNT + VST + C17 Setup auch gleich dazu.

Zunächst zur CoreCycler Config: der entscheidende Parameter ist:
restartTestProgramForEachCore = 0

Hatte ich vorher auf 1 = enabled, weil ich wollte, dass jeder Core genau dieselben Tests durchläuft. Aber: auf 1 = enabled wird mit jedem Core der Y-Cruncher Prozess gekillt, und ein neuer gestartet - so gehen die Fehler verloren.

Auf 0 = Disabled (ist eh Standard...) bleibt der Y-Cruncher Prozess offen, und das Skript wechselt einfach im Hintergrund die Cores durch. So hat zwar nicht jeder Core das gleiche Programm, weil es sich dynamisch verschiebt mit der Laufzeit der Tests, aber wenn man die Testzeit pro Core ca auf 64s x Anzahl Tests setzt (zB 64 x 3 für HNT + VST + C17), dann passt das im Großen und ganzen und verschiebt sich nur leicht.

Jedenfalls kann man so kann man jederzeit, auch nach Ende des Tests, durch das Y-Cruncher Fenster scrollen und auf Fehler checken, und wahrscheinlich werden sie auch in die CoreCycler Konsole übernommen. Das weiss ich "leider" nicht, weil das genau der finale Test meines stable Setup war :d

Hier meine config - wahlweise 30s HNT per Core, oder 256s N64, HNT, VST, C17 :

Code:
# General settings
[General]
stressTestProgram = YCRUNCHER
runtimePerCore = 30s
# runtimePerCore = 30s --> HNT only Quick Check Cycles
# runtimePerCore = 256s --> N64, HNT, VST, C17 Final Check overnight
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
disableCpuUtilizationCheck = 0
restartTestProgramForEachCore = 0
# restartTestProgramForEachCore = 0 is default; 1=enabled leads to not seeing errors in the Y-Cruncher test window
coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
skipCoreOnError = 1
numberOfThreads = 2

# y-Cruncher specific settings
[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = HNT
# tests = HNT --> HNT only Quick Check Cycles
# tests = N64, HNT, VST, C17 --> Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17 --> all tests
 
Zuletzt bearbeitet:
So, bin auch mal wieder hier. 🙃

@Bread
Du hast disableCpuUtilizationCheck auf 1 gesetzt, damit ist keine Erkennung von Fehlern bei Y-Cruncher mehr möglich. Y-Cruncher gibt leider keinerlei Feedback außer über die eigene Terminal-Ausgabe. Weder legt es eine Logdatei an, noch kann man die Ausgabe selbst abfangen, also ist die einzige Möglichkeit zur Erkennung eines Fehlers über das Auslesen der CPU-Auslastung. Welche du ja mit disableCpuUtilizationCheck = 1 deaktiviert hast. Wenn du das wieder auf 0 setzt, sollte auch der CoreCycler wieder entsprechende Meldungen ausgeben.
Y-Cruncher wird übrigens immer mit Core 2 (und 3 bei zwei Threads) initialisiert, die tatsächliche Zuteilung zu den getesteten Kernen wird dann intern über das CoreCycler-Script geregelt. Die Meldung über den Kern dort ist also nicht korrekt!
Nicht, dass jemand deswegen Kern 2 immer weiter absenkt, ohne dass sich was an der Stabilität ändert...
 
Zuletzt bearbeitet:
Zur Vorbereitung der CO Werte per Core, sind die besten Kerne pro CCD irgendwo markiert?
 
Ja, in HWinfo wenn Du CPPC enabled hast. 0 = bester
Beitrag automatisch zusammengeführt:

So, bin auch mal wieder hier. 🙃

@Bread
Du hast disableCpuUtilizationCheck auf 1 gesetzt, damit ist keine Erkennung von Fehlern bei Y-Cruncher mehr möglich. Y-Cruncher gibt leider keinerlei Feedback außer über die eigene Terminal-Ausgabe. Weder legt es eine Logdatei an, noch kann man die Ausgabe selbst abfangen, also ist die einzige Möglichkeit zur Erkennung eines Fehlers über das Auslesen der CPU-Auslastung. Welche du ja mit disableCpuUtilizationCheck = 1 deaktiviert hast. Wenn du das wieder auf 0 setzt, sollte auch der CoreCycler wieder entsprechende Meldungen ausgeben.
Y-Cruncher wird übrigens immer mit Core 2 (und 3 bei zwei Threads) initialisiert, die tatsächliche Zuteilung zu den getesteten Kernen wird dann intern über das CoreCycler-Script geregelt. Die Meldung über den Kern dort ist also nicht korrekt!
Nicht, dass jemand deswegen Kern 2 immer weiter absenkt, ohne dass sich was an der Stabilität ändert...
Oha - danke! Weiss nicht wie das passiert ist, denke ich hab das von jemandem kopiert. Was macht dieser UtilCheck - einfach nur abfragen welcher Core benutzt wird, oder setzt der auch eine Handlung basierend auf dieser Info?
 
Zuletzt bearbeitet:
Oha - danke! Weiss nicht wie das passiert ist, denke ich hab das von jemandem kopiert. Was macht dieser UtilCheck - einfach nur abfragen welcher Core benutzt wird, oder setzt der auch eine Handlung basierend auf dieser Info?
Der Check fragt die momentane Auslastung des Prozessors ab und vergleicht den Wert dann mit einer zu erwartbaren Auslastung (100% Auslastung der getesteten Kerne * Anzahl der getesteten logischen Kerne(Threads) / Anzahl aller logischen Kerne). Für 16 physische Kerne mit 32 logischen Kernen wären das also 3,125% Auslastung insgesamt.
Liegt dieser Wert dann unterhalb der Erwartung bei 4 aufeinanderfolgenden Checks mit jeweils 2 Sekunden Abstand, dann wird ein "CPULOAD" Error ausgelöst, und das Script behandelt den momentan getesteten Core als fehlerhaft.

Und wie gesagt, bei Y-Cruncher ist das die einzige Möglichkeit herauszufinden, ob der Stresstest noch läuft oder nicht.
 
@sp00n

geiles Tool - vielen Dank für deine Arbeit! :hail:

hat mich tatkräftig unterstützt meine einzelnen Kerne maximal auszuloten

7900x

core0-core11
-7​
+4​
+6​
+10​
-3​
-7​
-31​
-33​
-27​
-29​
-31​
-27​

👍
 
Das "Gute" ist ja, dass bei mir HNT immer rebootet, und sonst läuft eh alles durch. Dann schau im Log welcher Core grad dran war vor dem "sudden Reboot" - und hab die nötige Info ;)

Aber OK, kenn mich aus - am besten UltiCheck auf 0, und RestartEachCore auch 0, dann bleibt das Y-Cruncher Fenster offen.
 
@sp00n bzw. auch gerne alle anderen:

Könnt ihr mir evtl. erklären warum Kagari die CPU (Ryzen 5 7600X) abschmieren lässt und Kizuna nicht ? Normalerweise müsste das doch genau andersrum sein weil Kizuna noch zusätzlich AVX512 testet

Was ich auch nicht verstehe ist, dass die Temperaturen mit Kagari deutlich höher sind als bei Kizuna.. Wobei wenn ich AIDA64 SHA3 hintereinander laufen lasse schmiert die CPU auch nicht ab nur bei Kagari :confused:
 
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