CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[LuxSkywalker]

@Bread

hm, das kann ich bei meinen System jetzt so nicht bestätigen ->

das ist ne alte Intel SSD welche ausschliesslich für mein Win10Pro TestOS benutzt wird... und da sind hunderte Stunden Prime95, CoreCycler, yCruncher TM5 etc drauf gelaufen ^^

es könnte allerdings sein, das wenn du das System während Prime aktiv benutzt deine Auslagerungsdatei massiv benutzt wird und das wiederrum macht dann Sinn wenn während dessen ständig auf der SSD geschrieben/gelesen wird

aber idk... wäre nur eine Vermutung

 

[Bread]

Hm, ich hab halt sehr viel Prime95 + TimeSpy Loop gemacht, ich trau mich gar nicht sagen wie viele Stunden, äh Tage, äh Wochen ... ev ist es das?

 

[LuxSkywalker]

wäre mal insgesamt gut zu wissen was bei dir die abartig hohe SSD Belastung triggert ^^

also ich habe mein aktuelles AMD System Ende März 23 gekauft, Anfang April 23 zusammen gebaut und Mitte August 23 erst "live" genommen - bis dahin immer nur optimiert inkl. Prime / CoreCycler etc...

in der Zeit lief das System eigtl immer rund um die Uhr mit Prime / CoreCycler / yCruncher etc zum testen

 

[sp00n]

Prime95 im Torture-Modus schreibt eigentlich nicht viel auf die Platte. Eigentlich sind es nur die Log files.
Es gibt da ja noch andere Modi, die evtl. mehr auf die Platte schreiben, aber genau hab ich die mir nicht angesehen und die werden von CoreCycler auch nicht benutzt.


Und weil ich das hier auch erwähnt gesehen habe, die "Large", "Huge", etc. Presets beziehen sich da auch nicht auf Dateigrößen, sondern auf die zu testenden FFT-Größen. Kleine FFT-Werte stressen da eher die CPU, mit höheren Temperaturen und gegebenenfalls dadurch verursachtem niedrigeren Takt, höhere FFT-Werte / Presets dann eher den Speichercontroller / RAM mit eher niedrigeren Temperaturen und dadurch tendenziell etwas höheren Taktraten.
Welches jetzt besser ist, hängt dann anscheinend immer vom eigenen Chip bzw. dessen aktuellen "Testzustand" ab, bei mir war es am Ende dann eben SSE mit Huge, weswegen das jetzt als Voreinstellung drin steht.

Wobei CoreCycler so ausgelegt ist, dass so wenig RAM wie möglich (nötig) zum Testen belegt wird, da es ja primär die CPU testen soll und nicht den Speicher.

 

[LuxSkywalker]

...
I keep playing for a few days and if it doesn't crash for a few days, I keep it and call it stable.
...

you could do what you want - but what has this to do with this Thread?!?

This Thread is for People who want to stabilize their PBO CO Values with the mentioned Tool

 

[LuxSkywalker]

Mir ist bei weiterem "rumspielen" (SMT testweise deaktiviert) aufgefallen das trotz stabilem 36h+ Laufzeit des CoreCycler einige Kerne wohl ins Clock Stretching laufen

Ein Beispiel:

Core 6 Clock Stretching vorhanden

Core 7 top

das ganze ist mir erst vor gut 2 Wochen aufgefallen als ich SMT testweise deaktiviert und BIOS upgedatet habe und dann nochmals mit PBO rumgespielt habe zwecks weiterer Optimierung

weiterhin bewerte ich momentan erstmal nur die "Aktuell" Spalte (immer rot markiert) bei HWiNFO - weil die "Maximal" Spalte (grün) mir stellenweise eine absurd hohe Differenz anzeigt:

entweder ist HWiNFO zu langsam beim erfassen der "Maximal" Frequenz (grün markiert)- oder ich habe doch massives Clock Stretching auf Core 1

und das obwohl die "Aktuell" Spalte eigentlich Top aussieht (beide Screenshots einzeln erstellt - daher die diff in der maximal Spalte)

Wenn jemand Bock hat das ebenfalls gegenzuchecken habe ich die config.ini für CoreCycler mal mit angehangen mit welcher ich das teste...

 

[Wolf87]

Das was Veii mal dazu gesagt hat ist dass momentan es nicht wirklich Programme gibt welche die millisekunden Sprünge des Taktes erfassen können. Such mal nach clock gating unter dem user Veii. Was die korrekte Erfassung abbilden kann ist Ropbench vom User Kelutrel im overclock Forum. Ich hab das co händisch ausgelotet über den effektiv Takt quasi bis nix mehr takt mäßig skalierte. Der corecycler testet leider in einem Scenario was in der Praxis quasi nicht vor kommt. Durch die neuen Generationen ist das ausloten komplexer geworden. Fluch und Segen😉

 

[LuxSkywalker]

check, Danke für den Hinweis auf clock gating

bisher noch nix von gehört, werde ich mir mal ansehen

 

[Bread]

Ich hab das co händisch ausgelotet über den effektiv Takt quasi bis nix mehr takt mäßig skalierte.

Wie genau hast Du das gemacht / mit welchem Load-Test?

Der corecycler testet leider in einem Scenario was in der Praxis quasi nicht vor kommt.

Wie meinst Du das? Volle Last auf einen Kern bei maximalem Single Core Boost?

 

[Wolf87]

Das Programm ropbench führt gewisse Amd Instruktionen aus die den Prozessor mit max Takt laufen lassen. In der readme Datei steht ein Startbefehl mit der man den effektiven Takt über Zeitraum x messen kann. Ich bin da auf 10 Sekunden gegangen. Im Programm selbst kann man dann das Co Schritt für Schritt senken und immer wieder die Funktion ausführen die nacheinander alle Kerne mit max Takt fährt. Irgendwann skaliert der effektiv Takt nicht mehr mit dem Co. Dann kann man im oberen Teil des Programm noch sich die Taktkurven in der 25 ms Auflösung anschauen und pro Kern prüfen ob die Taktkurve "rampup" sehr springt bzw. einbricht dann würde ich das co bei diesem Kern etwas zurücknehmen.

 

[RedF]

Ich bin zu doof den y-cruncher Test für Ryzen 7000 zu starten.

Was mache ich falsch?

 

[LuxSkywalker]

mode = 22-ZN4 ~ Kizuna

nur "22-ZN4" reicht nicht

und btw. Kizuna testen ist zeitverschwendung ^^ - damit kannst lächerlich hohe PBO CO Werte fahren welche überhaupt nicht stabil sind

mode = 19-ZN2 ~ Kagari

ist womit du testen willst

 

[RedF]

Danke : )

 

[RedF]

19-ZN2 ~ Kagari geht ja richtig ran ^^

Da bleibt nichts übrig

Core 3 hat wirklich spezielle Bedürfnisse.^^

 

[LuxSkywalker]

ich muss 3 meiner 12 Kerne sogar in einen positiven Offset nehmen 🫣

über alle Kerne verteilt ist von -30 bis +8 alles bei mir drin 😁

 

[Bam_Bam]

Ist bei mir bei 103 ähnlich. Core 6 +8, Core 3 +5 Core 2 +2 .

Deswegen habe ich ein Optimum bei 100.9 und Core 6 -20 gefunden, mit recht hohem Allcoreboost. Beim CB23 komme ich damit um die 19.000

 

[RedF]

Na geht doch, die 19K wollte ich knacken.
Wer hätte gedacht das die LLC so viel Einfluss auf die Leistung hat. CO geht so warscheinlich auch noch weiter runter.

 

[Bread]

Definitiv! LLC 8 MSI, oder 1 Asus?

 

[RedF]

1 ASRock : )

 

[LuxSkywalker]

Na geht doch, die 19K wollte ich knacken.
Wer hätte gedacht das die LLC so viel Einfluss auf die Leistung hat. CO geht so warscheinlich auch noch weiter runter.
...

Ich muss in meiner Konfiguration LLC5 fahren sonst droppt meine CPU in Multicore Last frequenztechnisch ziemlich ordentlich

Habe aber auch Multicore Enhancement enabled 😇

 

[RedF]

Habe aber auch Multicore Enhancement enabled 😇

Pah, Neumodisches zeug^^. So ein klimbim gibts bei ASRock nicht.

 

[Bam_Bam]

Definitiv! LLC 8 MSI, oder 1 Asus?

Asus 670 hat Standard LLC 7. Stellt man dann auf 8 für Maximale Leistung. Bei MSI "beste Leistung" meine ich, wenn es aus ist "Disable".

 

[RedF]

Nennt sich bei ASRock Mode 1,2,3. Wobei 1 das aggressivste ist, also ohne oder sehr wenig Vdrop.

 

[Bam_Bam]

Na geht doch, die 19K wollte ich knacken.
Wer hätte gedacht das die LLC so viel Einfluss auf die Leistung hat. CO geht so warscheinlich auch noch weiter runter.
Anhang anzeigen 993055

Echt krass, dass der Boost so hält. Bei -2 zieht der schlechte Core den Allcore Boost ja mit in den Keller. Du solltest das Ganze Spiel nochmal mit weniger ECLK probieren. Bist dann insgesamt bestimmt effizienter und mit höherem Allcoreboost unterwegs. Oft hilft es auch die anderen Cores höher (weniger -CO) zu setzen um den schlechten Core zu stützen (mehr -CO).

Beitrag automatisch zusammengeführt: 24.04.2024

Das Programm ropbench führt gewisse Amd Instruktionen aus die den Prozessor mit max Takt laufen lassen. In der readme Datei steht ein Startbefehl mit der man den effektiven Takt über Zeitraum x messen kann. Ich bin da auf 10 Sekunden gegangen. Im Programm selbst kann man dann das Co Schritt für Schritt senken und immer wieder die Funktion ausführen die nacheinander alle Kerne mit max Takt fährt. Irgendwann skaliert der effektiv Takt nicht mehr mit dem Co. Dann kann man im oberen Teil des Programm noch sich die Taktkurven in der 25 ms Auflösung anschauen und pro Kern prüfen ob die Taktkurve "rampup" sehr springt bzw. einbricht dann würde ich das co bei diesem Kern etwas zurücknehmen.

Das Ganze funktionier aber nur, wenn du ein "Höchstleistung"-Profil aktiviert hast. Ansonsten hängt der Core 0 hinterher, zumindest bei mir ist es immer so.

 

[RedF]

Konnte Core 3 jetzt mit LLC 1 noch zu -5 bewegen.

ECLK runter werde ich auch noch versuchen.

Hydra habe ich versucht, kommt bei mir aber nichts sinnvolles raus.

 

[Bread]

MSI LLC 8 fahre ich, da ist die VID Baseline am geringsten, sprich ich krieg damit die vCore nochmal runter und er boostet höher.

 

[X909]

Interessantes tool! Ich hab WHEAs immer auf den favorite cores, 4 und 5 wenn ich die Spannung zu weit reduziere. Nehme an die sind nicht wirklich schlechter sondern werden einfach häufig genutzt bzw. boosten am meisten. Wers mit dem Tool mal verifizieren.

 

[Zyxx]

Und ein WHEA auf APIC ID 5, inkl. reset des PCs und neu booten.
Der Kern wurde dann jetzt auch von -15 auf -10 entschärft.

Das lief jeden Tag absolut stabil seit ich das letzte Mal hier vor Monaten gepostet habe.
Auch Corecycler hat einige Runden hier gedreht danach.
Ehrlicherweise die letzten Monate aber nicht mehr.

Eventuell sollte ich das mal wieder anwerfen, der 5900x wird alt :/

 

[Bread]

Oag. Wenn wir regelmäßig ans Limit testen, können wir offenbar die Degradation live mitverfolgen Musste auch schon einen Core nachjustieren, allerdings nur um +1

 

[sp00n]

Version 0.9.5.0 ist jetzt draußen, hat ein paar Änderungen.

Releases · sp00n/corecycler

Script to test single core stability, e.g. for PBO & Curve Optimizer on AMD Ryzen or overclocking/undervolting on Intel processors - sp00n/corecycler

github.com

• Updated Prime95 to version 30.19b20
• Updated y-Cruncher to version 0.8.4 Build 9538
• Updated PBO2 Tuner to the latest version
• It's now possible to catch the output from y-Cruncher, thus enabling the "auto" runtimePerCore setting for y-Cruncher as well. It will test all selected cores for one core and then proceed to the next one
  (this is made possible by a custom wrapper .exe and .dll in the /helpers directory)
• Greatly increased the support for Intel CPUs, it now tries to detect a core architecture where some cores only support one thread (i.e. Intel's big.LITTLE) and automatically adjusts the threads it runs on these cores if two threads and restartTestProgramForEachCore is selected.
  Note that running with two threads and without the setting enabled may result in very long test times on the E-Cores and any test afterwards, so it's strongly recommended to either enable restartTestProgramForEachCore, test only with one thread, or test the P- and E-Cores separately.
• Added support for processors with more than 64 (virtual) cores for you HEDT freaks!
• Added a testDuration setting for y-Cruncher that allows to set the test duration in seconds for each individual test (default: 60)
• The script now also checks for WHEA errors (Windows Hardware Error Architecture) during its runtime and notices the user if such an event has happened.
  It's not treated as a "real" error, as it doesn't necessarily coincide with the core that is currently being tested.
  You can disable this check with the lookForWheaErrors setting.
• The script now also uses the Windows Event Log to store log information. This is helpful if a hard reboot occurs during testing, which can corrupt the log file. The Event Log entry should still show which core had begun testing before the hard reboot happened.
  To be able to use this functionality, the script asks the user if a new "Event Source" should be added, which requires administrator privileges. This only needs to happen once, so after this "Source" has been added, no administrator privileges will be needed anymore. The script itself also doesn't need admin rights, instead it will open a new window to perform this action, and asks for elevation for this new window.
  The Event Log entries can be found in the "Windows Logs"/"Applications" section of the Event Viewer, and have the source "CoreCycler".
  This functionality can be controlled by the useWindowsEventLog setting in the [Logging] section.
• It's also possible to try to periodically force a "Disk Write Cache Flush", which can also help prevent log file corruption. It's not enabled by default though, to prevent possible negative performance impacts (setting flushDiskWriteCache in the [Logging] section)
• The check for the CPU utilization doesn't require Windows Performance Counters anymore, which malfunctioned far more often than I had ever imagined, and so should result in less false alarms. Instead it now uses the more readily available processor time.
  If you really want to, you can re-enable the use of the Windows Performance Counters by setting useWindowsPerformanceCountersForCpuUtilization in the [Debug] section, but I really advise against it.
• Added a beep on error! (Controlled with the beepOnError setting)
• Added a taskbar flash on error! (Controlled with the flashOnError setting)
• The CPU affinity is now set to the threads of the stress test program, and not to the program/main process itself anymore.
  This is required to be able to set the affinity for more than 64 CPUs, and also to fix a bug that appeared on Intel systems, where if set to use two threads, the two virtual CPUs weren't fully loaded if only the main program's affinity was set.
  You won't be able to easily see the current affinity using the Task Manager anymore, but a tool like System Informer can also show the current affinity for threads
• The new y-Cruncher version has updated tests and also doesn't support the 00-x86 algorithm anymore, so the new default low-load binary algorithm is 04-P4P instead
• However, the old y-Cruncher version (which is 0.7.10) is still included, and you can use it by setting stressTestProgram to YCRUNCHER_OLD
  Be aware that you will also need to adjust the tests setting in the config if you're switching between the versions!
• The config.default.ini is now automatically generated (and overwritten) on each script start. It doesn't have any functional use anymore and is purely there to give the user a starting point / reference for creating a custom config.ini
• The PowerShell code itself now uses the Set-StrictMode -Version 3.0 setting. This may introduce new and fun script error messages, but hopefully I have already caught most of them!
• This caused a general code cleanup and some refactoring due to the errors I caught this way. And also eliminated a couple of bugs
• Added a LICENSE file! It just includes the text of the "CC BY-NC-SA" Creative Commons license, which the script always had anyway