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.
CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen
- Ersteller sp00n
- Erstellt am
Karl Gustav
Banned
- Mitglied seit
- 12.08.2022
- Beiträge
- 733
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
.
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
.
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 435
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.
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.
Bread
Experte
Hey, super Tool das extrem nützlich ist beim CO ausloten! Ein Problem hab ich allerdings damit:
Screenshots unten für bessere Nachvollziehbarkeit!
- Bei Core 5 wirft "Logical Core 3" nen Error.
- Ich warte ab, das Fenster verschwindet (soll ja auch ein unattended Test sein)
- Core 6 Test beginnt
- Ich breche mit Ctrl-C ab
- Mir wird mitgeteilt "alles gut, keine Fehler"?!
Screenshots unten für bessere Nachvollziehbarkeit!
@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 ?
hatte ja -20 auf allen .
Sehe ich das richtig das Core 3 Fehler gemacht hat?
Im Biois wäre das dann CPU Core 3 ?
LuxSkywalker
Urgestein
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
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
Zuletzt bearbeitet:
Mache gerade per Core bzw habe gerade darauf umgestellt.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
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?
LuxSkywalker
Urgestein
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 😄
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
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.
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:
Bread
Experte
Den Thread hatte ja eigentlich ich wiederbelebt, mit Post hier - dann grätscht du mit Deinem Problem rein und meins geht unter
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?
Bread
Experte
Servus! Kurze Frage, bei mir zeigt das Ding von selber keine Fehler an, siehe oben - lässt Du das zufällig als Admin laufen? Ich nämlich nicht...
LuxSkywalker
Urgestein
nope, einfach doppelklick auf die .bat
Bread
Experte
Kommt dann ein Admin-Prompt ("Ja klicken"), oder nicht?
LuxSkywalker
Urgestein
nö, es startet direkt die Kommandozeile und das Script startet
Zuletzt bearbeitet:
Bread
Experte
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 ja: ev funzt das bei mir nicht, weil ich PowerShell nutze zum starten des CoreCycler? Versuche es mal wie Du mit Doppelklick
LuxSkywalker
Urgestein
wenn ein Fehler auftritt sehe ich das in der cmd-line wie in @Thunderburne seinem Post - etwas runter scrollen Error dick in lila
Bread
Experte
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...
Ergänzung: welchen Test fährst Du? Ich Kagari.
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.
LuxSkywalker
Urgestein
ich hab Win 10
Kagari passt - der stresst mein System am härtesten ^^
Kagari passt - der stresst mein System am härtesten ^^
Bread
Experte
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
Hier meine config - wahlweise 30s HNT per Core, oder 256s N64, HNT, VST, C17 :
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
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:
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 435
So, bin auch mal wieder hier. 🙃
@Bread
Du hast
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...
@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:
Bread
Experte
Ja, in HWinfo wenn Du CPPC enabled hast. 0 = bester
Beitrag automatisch zusammengeführt:
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:
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 435
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.
LuxSkywalker
Urgestein
Bread
Experte
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.
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
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
Zuletzt bearbeitet:
