CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[Sushi01]

Mal eine Frage in die Runde.
Macht es Sinn irgendwann auch mit SMT, also 2 Threads, zu testen?
Und momentan mache ich ein All Run, also alle FFT Größen. Reicht hier ein Durchlauf? Für mein Verständnis sollte er kein Fehler mehr produzieren, wenn ich alle FFT-Größen einmal durch habe, oder liege ich hier falsch?
Danke und Gruß

 

[Ragnador]

@Sushi01
Sollte eigentlich alles abgedeckt sein wenn du zu allererst mit cinebench r23 allcore getestet hattest
(kann meist weggelassen werden wenn du boost takt nicht anhebst und nur curve optimizer nutzt)
und dann mit core cycler AVX2 und danach SSE für singlecore testest.

 

[Sushi01]

Und welche Einstellungen meinst du im CoreCycler?
Glaube AVX2 Stable benötige ich nicht. AVX sollte mir reichen.
SSE Stable ein ALL Run ist es schon mal. Jetzt noch AVX. Ich bleibe aber bei einer Iteration. Teste ja alle Größen.

 

[Ragnador]

Man testet AVX2 weil damit der Takt unter größter Hitzeproduktion im singlecore getestet wird. SSE um den Höchsten Takt im Singlecore zu testen.

Also meine Ryzen (5000er und) 7000er (hier war avx2 stable essentiell für games) hatte ich eigentlich nur noch AVX2 prime getestet ,beim curve optimizer, als Zeiteinspaarung. Sind alle noch nie abgestürzt und haben keine zicken gemacht.

Sicherer ist aber beides testen.
30 Iterationen.

5000er waren sehr SSE abhängig (SSE instabil während AVX2 keine Probleme verursachte)
7000er waren sehr AVX2 abhängig (AVX2 instabil während SSE keine Probleme verursachte)
9000er hatte ich noch keinen.


Du solltest viele Iterationen durchlaufen lassen, da er ja alle 6 Minuten den nächsten kern testet, damit der andere wieder runter kühlt. Dadurch hast du ja nicht alle fft größen auf einem kern gestestet.
Manchmal spuckt er erst in Iteration 20 oder so nen Fehler aus.

 

[Sushi01]

Ok alles klar, danke dir.
Ja ich mache immer einen Auto Durchlauf. Das bedeutet, dass er einen Kern solange testet, bis alle FFT-Größen des gewählten Presets durch sind. Erst danach springt er zum nächsten Kern. Und ich habe ALL FFT ausgewählt. Also alle FFT Größen bei z.B. SSE (4k-32768k). Deshalb nur eine Iteration, weil jeder Kern damit alle FFT Größen durchläuft.

Thema SMT, macht das einen Unterschied beim Stabilitätstest, ob dies aktiviert oder deaktiviert ist?

 

[sp00n.82]

Hab jetzt endlich mal die 0.10.0.0 finalisiert:
https://github.com/sp00n/corecycler/releases

Spoiler

Version 0.10.0.0 offers a new "Automatic Test Mode" For Ryzen 5000 and 7000 and Intel processors up to 14th gen, which will automatically adjust the undervolt value upwards if a core has thrown an error.
To activate it you need to enable the enableAutomaticAdjustment setting in the config.ini. Additionally you can also enable the enableResumeAfterUnexpectedExit setting, which will try to resume the script if an unexpected crash of the computer has happened. Although for this to work correctly you would need to enable the automatic logon for Windows, otherwise the script cannot automatically restart.

More info can be found here:
https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
https://learn.microsoft.com/en-us/t...er-profiles-and-logon/turn-on-automatic-logon



Changelog:

Final:

• The script now tries to find the stress test process more thoroughly (fixes #72)
• Now checking if the Windows Event Log service is running (fixes #101)
• Renamed WriteVerbose to WriteVerboseText and WriteDebug to WriteDebugText to prevent possible collisions with the built-in methods
• Disabled the "QuickEdit Mode" feature of the Windows command line terminal, which should prevent accidental script pauses
• You can now use "shortcuts" for y-cruncher (for example "19-ZN2" instead of "19-ZN2 ~ Kagari")

alpha5:

• Fixed a bug that prevented the automatic test mode to resume the test if the crash happened on core 0 (fixes #89)

alpha4:

• Fixed a bug with Linpack's path AGAIN
• The Automatic Test Mode unfortunately doesn't work with Ryzen 9000

alpha3:

• Added config presets for Automatic Test Mode
• Fixed a bug where Linpack wouldn't start from a directory including a space (fixes #84)
• Fixed a bug where resuming after a crash with a "default" coresToTest order would result in an index out of bounds error (fixes #85)
• Also it didn't resume on the crashed core
• The config file's content is now put into the log file for easier debugging
• Fixed a bug where the log file for y-cruncher was actually using the naming scheme for Linpack (under unclear circumstances, but it happened at least once)
• Fixed a bug when the update check doesn't return any output at all (fixes #83)

alpha2:

• Fixed a bug with the detection of the starting values (see #79)

alpha1:

• Added an automated test mode with automatic Curve Optimizer / voltage offset adjustment on error
• Added the possibility to automatically resume the script after a reboot via a Scheduled Task
• A WHEA warning/error can now be treated as a "real" error if the APIC ID matches the tested core
• See the default.config.ini for the new settings

 

[BreadPit]

Sehr fein, Glückwunsch!

 

[MGFirewater]

@sp00n.82 also funktioniert der automatic test nicht mit ryzen 9000? ich habe bestimmt vor 3 jahrne zuletzt corecylcler für meine zen3 cpu eingesetzt, und irgendwie bin ich jetzt mit dem setzen der paramater überfordert. gibts irgendwo ein tutorial, gefühlt haben sich die parameter in der readme verdreifacht

edit: habs gefunden: configs liegen jetzt in einem separaten Ordner und da ist alles wie früher

 

[user7789]

@sp00n.82, danke für deine Arbeit und dein super Tool!
Allerdings ist mit aufgefallen, dass bei deiner v0.10.0.0 und auch schon bei der v0.9.6.2 bei einer normalen Core-Reihenfolge von 0, 1, 2, 3, 4, 5, 6, 7 (wobei auch eine andere Reihenfolge nichts ändert) fehlerhafter Weise der logische HT-Kern und nicht der phyische Kern angesprochen und ausgelastet wird, was natürlich wenig Sinn macht.

Umgehen kann ich das Problem nur, indem ich bei numberOfThreads eine 2 definiere, was dann wenigstens beide Kerne (den physischen und den logischen/virtuellen) gleichzeitig anspricht und auslastet. Kurioser Weise lauft bei der v0.8.2.4 alles wie es sein soll mit den gleichen Settings, dort wird korrekter Weise immer nur der phyische Kern ausgelastet.

Das Problem besteht sowohl bei Prime95 als auch bei yCruncher. Getestet mit aktuellem Win11 System mit einem Ryzen 5800x (Zen3).

Vielleicht hat jemand eine Idee oder kann das Problem bestätigen.

 

[Baal Netbeck]

Vielleicht hat jemand eine Idee oder kann das Problem bestätigen.

Es gibt doch keinen Unterschied zwischen core 0 und 1?

Ist beides der erste Kern, nur als zwei logische Prozessoren präsentiert.
Welchen davon du auslastest ist egal.

 

[user7789]

@Baal Netbeck Das ist nicht korrekt

Also ja, beides ist der erste Kern (Windows Kern 0 + Windows Kern 1, aber zusammengesetzt aus physisch + logisch und nicht wie du schreibst aus zwei logischen Kernen). ABER, beim Stresstest will man doch den physischen und nicht den logischen HT-Kern testen! Selbstverständlich ist es also nicht egal wie du es schreibst und natürlich gibt es einen Unterschied, sowohl technisch als auch leistungsbezogen.

Bei einem 8-Kerner (16 im HT), wie dem 5800x, sind die Kerne von 0-15 durchnummeriert, schau einfach mal in den Task-Manager. Bei AMD wären die logischen Kerne immer die geraden Nummern. Bei Stresstests oder bei Programmen, die HT gar nicht ansprechen, steht 0 für CPU0, also den ersten physischen Kern und 1 für CPU2, also den zweiten physichen Kern, usw...daher bitte nicht verwirren lassen

So wird es ja auch im CMD bzw. Powershell Fenster angezeigt, bspw.:
07:12:08 - Set to Core 0 (CPU 0)
Running for 8 minutes...
07:20:11 - Completed the test on Core 0 (CPU 0)
07:20:11 - Set to Core 1 (CPU 2)
Running for 8 minutes...
07:28:13 - Completed the test on Core 1 (CPU 2)

Daher sollte der Stresstest mit der Reihenfolge 0, 1, 2, 3, 4, 5, 6, 7 jeden physischen Kern einzeln ansteuern und keinen HT-Kern, sofern die besagte Option "numberOfThreads" wie default auf "1" steht. Übersetzt werden dann mit dieser Reihenfolge die physischen Kerne 0, 2, 4, 6, 8, 10, 12, 14 getestet. Mit der Version v0.8.2.4 funktioniert das auch noch wunderbar, aber eben mit den späteren genannten Versionen nicht mehr.

Gibt man bspw. in der config an, dass nur Kern 1 getestet werden soll, sollte korrekter Weise der zweiten physischen Kern "CPU2" genutzt werden. Fehlerhafter Weise springt er bei den neueren Versionen aber zum HT-Kern der zweiten CPU, also eigentlich zur Windows-CPU3 laut Task-Manager.
Fakt ist, egal welchen Kern ich in der config zum Test bei der Reihenfolge angebe, es wird stets nur der HT-Kern der einzelnen CPU´s verwendet. Dass diese weniger Leistung wie physiche Kerrne haben, sollte uns allen klar sein. Das Problem ist hier aber eher, dass wenn ich einen HT-Kern zu 100 Prozent auslaste, die Last (Hitze+Strom) bei weitem nicht so hoch für den CPU ist, wie bei einer 100-Prozent Auslastung eines pysischen Kerns. Demnach läuft der Test bei dieser fehlerhaften HT-Kern Ansteuerung natürlich viel stabiler ab, als bei einer korrekten Ansteuerung der Last auf ausschließlich alle logischen Kerne.

Bei den damaligen Intel-CPU´s würde das auch Sinn machen, denn bei Intel war damals immer der ungerade Kern der physische Kern (keine Ahnung ob das heute auch noch so ist, bin zu lange raus bei Intel).

 

[Baal Netbeck]

@user7789 ich bin mit ziemlich sicher, dass du hier derjenige bist, der auf dem Holzweg ist.

Wie gesagt... Es gibt keinen Unterschied zwischen den zwei Threads die jeder CPU Kern mit HT/SMT hat.

Das sind einfach zwei Warteschlangen für Instruktionen für den gleichen Kern.

Und die Aufteilung ist auch richtig.

Wenn der core cycler auf Thread 0 läuft, spricht er Kern 0 an und dann überspringt er ganz korrekt den Thread 1, weil dieser ebenfalls zu kern 0 gehört und macht mit Thread 2 weiter, was zu Kern 1 gehört....er könnte genauso so gut Thread 1 und dann Thread 3 testen... Aber wenn er 0,1,2,3 testet, hat er jeweils zweimal hintereinander den jeweils gleichen Kern getestet.

Ergänzung (Mittwoch um 11:46)

Du kannst das z.B. sehen wenn du mit sisoft sandra die Latenzen zwischen allen CPU Threads testen lässt.

Dann siehst du das die besten Latenzen zwischen jeweils 0 und 1, 2 und 3 usw. Sind, weil das die gleichen Kerne sind.

Von 0 zu 2 oder 1 zu 2 ist länger aber gleich.

Und wenn du mehrere CCX hast wie bei Zen bis Zen2, siehst du die zusätzliche Latenz zwischen den Threads 0-7 zu 8-15....und wenn du zwei CCD hast, nochmal höhere Latenzen von 0-15 zu 16-31.

 

[Tanzmusikus]

Ich glaube, du verstehst ihn falsch.

Daher sollte der Stresstest mit der Reihenfolge 0, 1, 2, 3, 4, 5, 6, 7 jeden physischen Kern einzeln ansteuern und keinen HT-Kern, sofern die besagte Option "numberOfThreads" wie default auf "1" steht. Übersetzt werden dann mit dieser Reihenfolge die physischen Kerne 0, 2, 4, 6, 8, 10, 12, 14 getestet. Mit der Version v0.8.2.4 funktioniert das auch noch wunderbar, aber eben mit den späteren genannten Versionen nicht mehr.

Er bestätigt damit doch das, was auch du schreibst.

Wenn der core cycler auf Thread 0 läuft, spricht er Kern 0 an und dann überspringt er ganz korrekt den Thread 1, weil dieser ebenfalls zu kern 0 gehört und macht mit Thread 2 weiter, was zu Kern 1 gehört

Die Frage ist, was meint @user7789 genau?

07:12:08 - Set to Core 0 (CPU 0)
Running for 8 minutes...
07:20:11 - Completed the test on Core 0 (CPU 0)
07:20:11 - Set to Core 1 (CPU 2)

Das ist doch vollkommen okay. Da wird der HT-"Core" ausgelassen.
Bin mir nicht sicher, was Du überhaupt für ein Problem siehst.

 

[Baal Netbeck]

Die Frage ist, was meint @user7789 genau?

Wenn ich das richtig verstehe, glaubt er, dass die Threads/Kerne anders angeordnet sind, als sie es sind....und das es einen Unterschied macht, ob man den einen oder den anderen Thread eines Kernes belastet.

 

[Tanzmusikus]

Ich glaube ihr habt einfach die Bezeichnungen nicht ein-eindeutig festgelegt.
Das führt schnell zu Missverständnissen.

Je nach Prozessor kann man da verschiedene Bezeichnungsmodelle (z.B. mit/ohne HT) anwenden.

Allerdings ist mit aufgefallen, dass bei deiner v0.10.0.0 und auch schon bei der v0.9.6.2 bei einer normalen Core-Reihenfolge von 0, 1, 2, 3, 4, 5, 6, 7 (wobei auch eine andere Reihenfolge nichts ändert) fehlerhafter Weise der logische HT-Kern und nicht der physische Kern angesprochen und ausgelastet wird, was natürlich wenig Sinn macht.

Bei einem 8-Kerner z.B. 5800X:
0-7 sind alle physischen 8 Kerne.
0-15 sind alle logischen 16 Kerne (Threads)
0,2,4,6,8,10,12,14 wären z.B. 8 logische Kerne (Threads)
1,3,5,7,9,11,13,15 wären auch 8 logische Kerne (Threads)

Beim CoreCycler ist es wohl so:
Core 0 (CPU 0)
Core 0 (CPU 1)
Core 1 (CPU 2)
Core 1 (CPU 3)
Core 2 (CPU 4)
...
@user7789 nur welche CoreCycler-Version ist damit gemeint?

Ergänzung (Mittwoch um 12:13)

Er meint wohl eher die Latenzen. Was auch immer daran suspekt oder wichtig sein soll, ich weiß es nicht.
Geringere Latenzen beim Wechsel von Thread 0 zu 1 des selben Kern ist eine Sache.
Eine geringere Temperatur beim Wechsel von Kern 0 zu 1 ist eine andere Sache.

Eine minimal höhere Latenz beim Wechsel zu einem anderen Kern als zum anderen Thread des selben Kerns, erscheint mir logisch. Was aber soll das im Zusammenhang mit dem CoreCycler zu tun haben? @user7789

 

[MehlstaubtheCat]

Hi@all!

Gruß
Mehlstaub

 

[Tanzmusikus]

Wie gesagt... Es gibt keinen Unterschied zwischen den zwei Threads die jeder CPU Kern mit HT/SMT hat.

Das sind einfach zwei Warteschlangen für Instruktionen für den gleichen Kern.

Dem stimme ich zu.

@user7789
https://en.wikipedia.org/wiki/Hyper-threading
https://www.ionos.de/digitalguide/server/knowhow/hyperthreading/

Damit ist die Disskusion haltlos. Es kann weiter ge'corecycle't werden.

 

[sp00n.82]

Ich glaube, ihr redet aneinander vorbei. 🤔

Gibt man bspw. in der config an, dass nur Kern 1 getestet werden soll, sollte korrekter Weise der zweiten physischen Kern "CPU2" genutzt werden. Fehlerhafter Weise springt er bei den neueren Versionen aber zum HT-Kern der zweiten CPU, also eigentlich zur Windows-CPU3 laut Task-Manager.

Das sollte natürlich nicht der Fall sein, kannst du mal einen Screenshot davon machen und die Logdatei mit anhängen?


@MGFirewater
Support für Ryzen 9000 existiert noch nicht, ich teste aber gerade die Integration eines neuen Tools, das das erlaubt.

 

[user7789]

Hallo zusammen,

ohne jetzt einzeln auf alles einzugehen dachte ich eigentlich, ich hätte mich verständlich ausgedrückt und hätte eher zu viel geschrieben, aber nicht schlimm, ich kläre gern noch genauer auf. @sp00n.82 hat es denke ich direkt richtig verstanden was ich meine und eigentlich detailliert (wahrscheinlich zu detailliert) geschrieben und erklärt habe


Nochmal, es geht nicht um Warteschlangen oder Threads und wie HT funktioniert ist mir ebenfalls bekannt Wie gesagt geht es mir rein um die Auslastung der Kerne und vor allem der korrekten Kerne! Daher schrieb ich auch, schaut doch gern mal in den Task-Manager oder kontrolliert es mit Tools wie Process Lasso. Da sieht man doch während des Tests ganz genau, welcher Core gerade zu 100 Prozent ausgelastet wird wärhend des Tests. Mehlstaub hat es doch auch als Bild schön gepostet was ich kompliziert versucht habe zu erklären...ausschließlich die linke Spalte "Physisch" mit Core 0,2,4,... sollte durch die Stresstests belastet werden. Bei der Version v0.8.2.4 ist das auch der Fall, wie man in meinem oberen Post sehen kann. Bei den beiden höheren Versionen jedoch die rechte Spalte, also ausschließlich die HT Kerne, belastet.

Eine Aussage von @Baal Netbeck mit dem Wortlaut "Ist beides der erste Kern, nur als zwei logische Prozessoren präsentiert. Welchen davon du auslastest ist egal." ist einfach grundlegend falsch, Holzweg hin oder her Denn weder sind beide Kerne von Core 0 logisch (wie beschrieben ist einer physisch, einer logisch), noch ist es egal, welcher dieser beiden Kerne genutzt wird. Denn naürlich bietet nur der physische die maximale Leistung und auch nur dieser ist für den Stresstest interessant. Ich weiß zwar nicht, wo ich mich unklar ausgedruckt habe, aber scheinbar habe ich es, nehm ich gern auf mich .

Daher hoffe ich, die zwei schnellen Screenshots belegen mein Problem nachvollziehbar. Wenn ihr eine Idee habt, was ich falsch eingestellt haben könnte, gern her damit. Die Configs habe ich jedenfalls nahezu auf Standard gelassen und Änderungen auf SSE oder AVX2 ändern nichts an dem Problem (hab es jetzt zum Test nur auf 1 Minute gestellt). Weil es kompakter ist, habe ich beim Screenshot Process Lasso statt dem Task-Manager eingeblendet und man kann gut erkennen, dass bei der neueren Version der logische HT-Kern statt dem physischen Kern unter Last gesetzt wird. Testreihenfolge bei beiden configs 0, 1, 2, 3, 4, 5, 6, 7.

EDIT: ein kleiner Nachtrag noch, hatte heute morgen zu schnell geschrieben bzw. hatte die Testdauer auf 8 Minuten und mir fiel der Fehler bereits vorher auf: Das Problem scheint nur den ersten Kern zu betreffen, bei den weiteren Kernen werden korrekter Weise die physischen cores angesprochen...er mag wohl nur core 0 nicht

16:02:33 - Set to Core 0 (CPU 1)
Running for 1 minute...
Progress 1/8 | Iteration 1/10000 | Runtime 00h 00m 05s
Test completed in 00h 01m 00s
16:03:34 - Set to Core 1 (CPU 2)
Running for 1 minute...
Progress 2/8 | Iteration 1/10000 | Runtime 00h 01m 05s
Test completed in 00h 01m 01s
16:04:35 - Set to Core 2 (CPU 4)
Running for 1 minute...
Progress 3/8 | Iteration 1/10000 | Runtime 00h 02m 07s
Test completed in 00h 01m 01s
16:05:37 - Set to Core 3 (CPU 6)
Running for 1 minute...
Progress 4/8 | Iteration 1/10000 | Runtime 00h 03m 08s
Test completed in 00h 01m 01s
16:06:38 - Set to Core 4 (CPU 8)
Running for 1 minute...

 

[sp00n.82]

EDIT: ein kleiner Nachtrag noch, hatte heute morgen zu schnell geschrieben bzw. hatte die Testdauer auf 8 Minuten und mir fiel der Fehler bereits vorher auf: Das Problem scheint nur den ersten Kern zu betreffen, bei den weiteren Kernen werden korrekter Weise die physischen cores angesprochen...er mag wohl nur core 0 nicht

Ok, dann ist es working as intended, Core 0 habe ich zwischenzeitlich ausgenommen, weil da viele Sachen vom Betriebssystem etc automatisch drauf laufen. Und Aida64 z.B. funktioniert erst überhaupt gar nicht, wenn man es manuell auf Core 0 beschränkt.

Das sollte dann aber auch in der Logdatei auftauchen.

# Always try to avoid CPU 0 for single threads if Hyperthreading is enabled, switch to CPU 1 instead
if ($cpuNumbersArray[0] -eq 0 -and $cpuNumbersArray.Count -eq 1 -and $isHyperthreadingEnabled) {
    Write-VerboseText('Trying to avoid Core 0 / CPU 0, as this is mainly used by the OS')
    Write-VerboseText('Setting to CPU 1 instead, which is the second virtual CPU of Core 0')
    $cpuNumbersArray[0] = 1
}

// Edit
Wenn du unbedingt Core 0 / CPU 0 testen willst, dann könntest du assignBothVirtualCoresForSingleThread in der config.ini auf 1 setzen, dann werden beide virtuellen Kerne zugewiesen und Windows sucht sich selbst den "richtigen" Kern aus.
Das ist anders als direkt die Anzahl der Threads auf zwei zu setzen, weil eben nur ein Thread mit der Last existiert. Ich hab das jetzt nicht explizit getestet, ob er dann auch auf CPU 0 spring, aber vom Code her müsste er das.[/icode]