CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[Verangry]

Das Programm muss ja auch irgendwo verwaltet werden, der Windows Prozess läuft fast immer auf Kern 0 deswegen kann es da zu Schwankungen kommen.

 

[wegdra]

Hab ich da Glück oder Pech, dass Core 0 der schnellste ist? 🤔
Also ist das der Grund wieso bei mir Core 0 derart aus der Reihe tanzt? Bin da akteull bei -4, der nächst schlechtere kommt bei -16 dann gehts erst bei 23 weiter.

 

[sp00n.82]

Wenn jemand testen möchte, neuer Versuch, um die blöden lokalisierten Counter in den Griff zu bekommen.
Das ist nur die script-corecycler.ps1, wenn das funktioniert, kann ich das als neue Version releasen.

 

[wegdra]

Sieht denke ich gut aus.

 

[sp00n.82]

Ok, dann hab ich grad die 0.7.8.9 hochgeladen, die den hoffentlich jetzt endgültigen Fix für die Performance Counter beinhaltet (WEHE NICHT! ).
Außerdem hab ich ein neues "Huge" Preset als Standardwert festgelegt, das testet alles oberhalb von 8192K (also von "Large"). Eventuell werfen jetzt eure bisher stabilen Kerne wieder Fehler, mal sehen. 😀
https://github.com/sp00n/corecycler/releases

 

[SeniorY]

sieht gut aus

 

[Sarkura]

hatte heute schon 2x den Fehler mit der Version 0.7.8.9 das er bei einer Core (unterschiedliche) stehengeblieben ist und die dann weiter dauerhaft durchgetestet hat ohne zum nähsten zu gehen. Also auch über die Zeit von 360sek.

Wenn ich es dann beende mit STRG C kommt das

Das troubleshooting läuft auch auf einen Fehler

 

[sp00n.82]

@Sarkura
In der Logdatei müssten mehr Infos stehen, sofern der verbosityMode in der Config nicht geändert wurde.

 

[wegdra]

@sp00n.82 Könntest du noch eine Option einfügen, dass wenn ein Fehler auftritt, dieser gezählt wird aber dennoch der Core weiter beim nächsten Durchlauf getestet wird? Bitte, bitte, bitte!
Also zB man sieht das bei 20 Durchläufen Core X (x Fehler bei x Durchläufen) Fehler hatte? Ich habe da, bei manchen Probleme mit dem Verständnis. Ich teste seit Tagen und ein Core schafft immer die -30. Teste ich schnell hintereinander, soll genau dieser plötzlich fehlerhaft sein. Zufall? Immer?

Ein Problem habe ich noch, was aber glaube ich eher an Prime liegt. Wenn ich nur Large teste und das schnell hintereinander (60s), wird nach einem Fehler Prime zwar immer neu gestartet, zeigt aber direkt einen Fehler ohne das der jeweilige Core belastet wurde. Das passiert nur bei Large. Das ganze auch bei Cores die zuvor All komplett und mehrfach Fehlerfrei durchlauf haben.

@alle: Kann es sein das Cinebench bei knapp unter stabil weniger Punkte hat als bei stabil, teilweise schwankend? Also mit niedrigeren Spannungen. Fehlerkorrektur?

 

[sp00n.82]

Könntest du noch eine Option einfügen, dass wenn ein Fehler auftritt, dieser gezählt wird aber dennoch der Core weiter beim nächsten Durchlauf getestet wird? Bitte, bitte, bitte!
Also zB man sieht das bei 20 Durchläufen Core X (x Fehler bei x Durchläufen) Fehler hatte? Ich habe da, bei manchen Probleme mit dem Verständnis. Ich teste seit Tagen und ein Core schafft immer die -30. Teste ich schnell hintereinander, soll genau dieser plötzlich fehlerhaft sein. Zufall? Immer?

Ein Problem habe ich noch, was aber glaube ich eher an Prime liegt. Wenn ich nur Large teste und das schnell hintereinander (60s), wird nach einem Fehler Prime zwar immer neu gestartet, zeigt aber direkt einen Fehler ohne das der jeweilige Core belastet wurde. Das passiert nur bei Large. Das ganze auch bei Cores die zuvor All komplett und mehrfach Fehlerfrei durchlauf haben.

Kannst du mir die Logs für die jeweiligen Situationen zur Verfügung stellen?
Die vorgeschlagene Funktion schaue ich mir mal an, sollte kein großes Problem darstellen.

 

[wegdra]

Scheint aber nicht immer so zu sein. Habe auch gerade paar Anläufe gebraucht um es zu reproduzieren.

 

[sp00n.82]

@wegdra
Sieht seltsam aus, kannst du auch noch die results_CoreCycler_2021-03-12_21-07-26_SSE_FFT_448K-8192K.txt hochladen?

 

[wegdra]

Wie gesagt, ich denke eher ein Prime Problem.

 

[sp00n.82]

Ja krass, da hat Prime tatsächlich bei jedem Kern direkt am Anfang beim ersten Durchlauf den gleichen Fehler geworfen. 😮

 

[sp00n.82]

Könntest du noch eine Option einfügen, dass wenn ein Fehler auftritt, dieser gezählt wird aber dennoch der Core weiter beim nächsten Durchlauf getestet wird? Bitte, bitte, bitte!
Also zB man sieht das bei 20 Durchläufen Core X (x Fehler bei x Durchläufen) Fehler hatte?

Ich hab die Funktion jetzt in 0.7.9.0 eingebaut: skipOnError, die standardmäßig auf 1 gesetzt ist für die gleiche Funktionalität wie zuvor.
https://github.com/sp00n/corecycler/releases

 

[robinps215@gmai]

Sollte ich idealerweise beim testen "delayBetweenCycles" aktivieren? Viele meinen ja, die reboots kommen u.a. durch Lastwechsel.

 

[Jabdah]

Hi , ich muss mal doof fragen: Wie lange rennt das .bat eigentlich? Bin nun bei Iteration 21 und es geht weiter und weiter.... Gibt es da ein Ende ?

 

[sp00n.82]

Hi , ich muss mal doof fragen: Wie lange rennt das .bat eigentlich? Bin nun bei Iteration 21 und es geht weiter und weiter.... Gibt es da ein Ende ?

Bis zur eingestellten maxIterations Zahl. Standardmäßig steht die auf 10000, ist also in der Tat für quasi unendlich gedacht.

Sollte ich idealerweise beim testen "delayBetweenCycles" aktivieren? Viele meinen ja, die reboots kommen u.a. durch Lastwechsel.

Dazu bräuchte ich tatsächlich noch Erfahrungsberichte. Persönlich habe ich den überwiegenden Teil meiner Tests ohne diese Einstellung gemacht (habe ich ja erst vor kurzem eingebaut), und bislang hatte ich dann auch noch keinen einzigen Reboot im Idle.
Ein möglicher Nachteil dieses Settings ist, dass man dafür auch restartPrimeForEachCore aktivieren muss, und wenn letzterer Wert aktiv ist, kann es sein, dass bei zu kurzer Laufzeit pro Kern nicht alle eingestellten FFT-Größen von Prime95 getestet werden, man unter Umständen also einige Tests verpasst.
Die FFTs sind so eingestellt, dass sie maximal eine Minute pro Größe laufen, bei kleineren Größen kann das auch schneller rum sein - Prime95 handhabt diese Einstellung wie "maximal ein Durchlauf oder maximal eine Minute, was immer davon schneller ist".

Bei den jetzt standardmäßig auf "Huge" eingestellten FFT-Größen dauert das mit seinen 30 Einträgen im SSE-Modus (bei AVX sind es 29, bei AVX2 35) dann also rund 30 Minuten, bis ein kompletter Durchlauf geschafft wurde. Ist jetzt aber restartPrimeForEachCore auf 1 gesetzt und die runtimePerCore bleibt auf den standardmäßigen 6 Minuten, dann werden nicht alle FFTs getestet, sondern nur das, was innerhalb der 6 Minuten reinpasst.

 

[maverick80]

hi
so ich melde mich mal zurück
war die woche beruflich nicht da und konnte nicht weiter testen
0.7.8.9 lief gestern nicht durch hing sich irgend wann auf
0.7.9.0 läuft bis jetzt durch bin bei iteration 6
wenn du was brauchst sag bescheid

 

[sp00n.82]

0.7.8.9 lief gestern nicht durch hing sich irgend wann auf
0.7.9.0 läuft bis jetzt durch bin bei iteration 6

Inwiefern "hing sich auf"? An der Testroutine hat sich zwischen den beiden Versionen eigentlich nichts geändert.
Die entsprechende Log-Datei wäre also hilfreich.

Und apropos aufhängen:
Gestern hatte jemand ein Phänomen, dass das Script anscheinend eingefroren war, ohne jegliche Fehlermeldung. Es aber dann nach Benutzerinteraktion wieder weiter lief.
Es stellte sich dann heraus, dass ein Powershell-Script jegliche Arbeit einstellt, wenn man Text in dem Terminal-Fenster markiert. 😵 Dazu reicht auch schon ein einfacher Klick in das Fenster, wodurch dann die Stelle unter dem Mauszeiger markiert wird. Mit Enter oder jeglicher anderen Taste kann man die Textmarkierung wieder aufheben und das Script macht da weiter, wo es aufgehört hat.

Siehe hier:
https://stackoverflow.com/questions/3204423/long-running-powershell-script-freezes
https://stackoverflow.com/questions/44698285/can-i-disable-select-mode-in-a-powershell-script

Einen entsprechenden Eintrag habe ich auch zur FAQ hinzugefügt.