CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[autoshot]

Was mir noch aufgefallen ist: mein PC hat sich, während der CoreCycler gelaufen ist, einfach in den Energiespar-Modus verabschiedet. Kann man da evtl. noch irgendeinen Blocker einbauen in den Cycler, der das verhindert?

 

[sp00n.82]

Interessant, bislang bin ich davon ausgegangen, dass ein laufender Stresstest / CPU-Auslastung einen automatischen Sleep/Hibernate verhindert. Aber anscheinend war das nur bis Windows XP der Fall, seit Vista geht der PC auch dann in den Sleep.

Es sieht aber so aus, als könnte ich ein Flag setzen, dass dem PC signalisiert, dass er das nicht machen soll. Muss ich dann noch integrieren und austesten.

 

[heijck]

runtimePerCore

Kannst du das Bitte etwas genauer erläutern?

 

[sp00n.82]

Die runtimePerCore Einstellung in der config.ini kann man jetzt auf auto setzen, damit werden dann bei Prime95 je Kern alle FFT-Größen des eingestellten Presets getestet, bevor er zum nächsten Kern wechselt und das ganze wiederholt.

(Bei Aida64 und y-Cruncher habe ich leider bislang keine Möglichkeit, einen "Durchlauf" festzustellen, dort sind es dann einfach 10 Minuten pro Kern.)

 

[heijck]

Gut das ich nachgefragt habe. Habe das doch glatt überlesen in der config! Coll. Gleich mal testen

 

[sp00n.82]

Ich hab jetzt die finale Version 0.8.1.0 gepusht, wobei sich das Script an sich nicht von der RC5 unterscheidet (bis auf die Versionsänderung).

https://github.com/sp00n/corecycler/releases

• Die runtimePerCore Einstellung kann man jetzt auf auto setzen. Bei dieser Einstellung wird bei Prime95 jede FFT-Größe des ausgewählten Presets für einen einzelnen Kern getestet, bevore er zum nächsten Kern wechselt, wo sich das ganze Spielchen wiederholt.
  Für y-Cruncher und Aida64 hat der"auto" Modus eine Laufzeit von 10 Minuten pro Kern (weil ich dort den Fortschritt nicht auslesen kann).
• Für die FFTSize bei Prime95 kann man jetzt auch eigene Werte eintragen, also z.B. 36-1344. Damit muss man nicht mehr den mode auf CUSTOM stellen, um eigenen FFT-Größen zu testen (natürlich kann man den CUSTOM mode aber auch weiterhin verwenden).
• Die Einstellung verbosityMode wurde in logLevel umbenannt
• Das Script sollte jetzt auch dann funktionieren, wenn man es als Administrator startet
• Einige Fehler behoben, wenn in der Config Groß-/Kleinschreibung oder überschüssige Leerzeichen vorhanden waren
• Die Fehlererkennung bei Prime95 wurde neu geschrieben, hoffentlich mit besserer Erkennung der Fehler
• Ebenfalls eine verbesserte Erkennung von zu geringer CPU-Auslastung

 

[c9hris]

@sp00n.82 Danke für deine Mühnen und Arbeit sobald ich meinen Ryzen 5900x bekomme. Werde ich ihn gleich testen mit deinen Tool

 

[K0N574N71N]

Vielen Dank für das Erstellen und Teilen dieses Skripts! <3

 

[sp00n.82]

Ich habe eben Version 0.8.2.0 veröffentlicht.

HINWEIS:
In der bislang mitgelieferten Version von Prime (30.4 bzw. 30.5) gibt es anscheinend einen Bug, der zu falschen Fatal Errors bei Prime95 selbst geführt haben könnte. In der nun mitgelieferten Version 30.6 build 4 soll dieser Fehler laut dem Entwickler nun behoben sein (siehe hier: https://www.mersenneforum.org/showpost.php?p=577388&postcount=274).
Demzufolge sollten alle, die bisher auch bei Stock Settings unerklärliche Fehlermeldungen hatten, auf diese Version wechseln!


https://github.com/sp00n/corecycler/releases


Changelog:

• Anscheinend gibt es einen Bug in Prime 30.4 & 30.5, der zu falschen Fatal Errors geführt hat. In der nun mitgelieferten Version 30.6 build 4 soll dieser Fehler laut dem Entwickler behoben sein (siehe hier: https://www.mersenneforum.org/showpost.php?p=577388&postcount=274)
• Beim Beenden des Scripts gibt es nun eine kurze Zusammenfassung
• Das Script verhindert nun den Wechsel in den Sleep/Hibernate/Standby-Modus des Computers während der Laufzeit

 

[Baal Netbeck]

Es ist toll, wie sehr du da an Ball bleibst!

 

[sp00n.82]

Bugfix-Release 0.8.2.1:

• Das Script konnte nicht gestartet werden, wenn der Verzeichnispfad ein Leerzeichen enthielt
• Wenn das /logs/ Verzeichnis nicht vorhanden ist, wird es jetzt automatisch angelegt (was Fehlermeldungen verhindert)

https://github.com/sp00n/corecycler/releases

 

[Shaddow_Phönix]

Kann man unterschiedliche Fehler finden wenn man ein Mal mit SMT (2Kerne) testet und das andere Mal ohne SMT (1Kern) ?

@sp00n.82

Die restlichen Einstellungen im Core Cyler sind identisch gewesen.

 

[sp00n.82]

Ein ganz klares "Vielleicht". 😬
Ich empfehle generell, so viele verschiedene Konfigurationen wie möglich durchzutesten, und dazu gehört dann natürlich auch 1 Thread vs. 2 Threads. Bei zwei Threads verändert sich ja wieder die benötigte Leistungsaufnahme, die Last auf den Kernen, die Temperatur, etc.

 

[snickers303]

Da ich dein Tool seid heute ausgiebig nutze - vielen lieben Dank dafür!

 

[Einstein90]

Was ein geniales Tool, vielen Dank für deine Mühe! Das gehört gepusht.

 

[snickers303]

Eine Frage hätte ich dann doch noch: Kann man die Config.ini so gestalten das für einen abschließenden Test über Nacht bzw. Nächte wirklich alles der Reihe nach abgearbeitet wird? Also das mit den Größen der Aufgaben ist klar (=All), aber kann man auch direkt SSX, AVX, AVX2 auf einmal mit angeben?

 

[sp00n.82]

Nein, SSE, AVX oder AVX2 müssen spezifisch angegeben werden, eine "all" Funktion gibt es dort nicht.

 

[stbdudu]

Hallo zusammen,

ich nutze gerade den Cycler und habe ein Frage zur Auswertung.
Wie kann ich am besten sehen, ob die Kerne stabil laufen. Ich habe die Standardeinstellungen beibehalten und aktuell erstmal nur von 6 auf 2 Minuten reduziert.

Wenn ich die readme richtig verstanden habe, dann wird ein instabiler Kern bei der nächsten Iteration automatisch rausgeschmissen?! Das wäre dann der Anhaltspunkt für mich zu erkennen, welcher Kern der Übeltäter ist?

Habe ich das so richtig verstanden, oder gibt es noch aufschlussreichere Analyseoptionen?

Grüße

 

[SeniorY]

um jeden Kern gewissenhaft zu testen braucht das schon mehrere Tage. Ich hab das mit einem 5800X durchgemacht. Nicht am Stück, da wird man sonst bekloppt

Von 6 auf 2 Minuten reduzieren ist ab einer bestimmten FFT Größe nicht so gut, denn dann werden nicht alle FFTs abgearbeitet. Irgendwo gibt es eine grobe Auflistung, wie lange ein Kern für die jeweilige FFT Größe benötigt.

Wenn ich die readme richtig verstanden habe, dann wird ein instabiler Kern bei der nächsten Iteration automatisch rausgeschmissen?!

genau. Sehr praktisch, wenn du das über Nacht laufen lässt.
Den Übeltäter dann weniger Offset geben und erneut testen. Möglichst alle FFT Größen. Eine Nacht small, eine Nacht medium usw. Gibt ja presets in der ini.

 

[sp00n.82]

Wenn ich die readme richtig verstanden habe, dann wird ein instabiler Kern bei der nächsten Iteration automatisch rausgeschmissen?! Das wäre dann der Anhaltspunkt für mich zu erkennen, welcher Kern der Übeltäter ist?

Habe ich das so richtig verstanden, oder gibt es noch aufschlussreichere Analyseoptionen?

Bei jedem Durchlauf wird angezeigt, welche Kerne bis dahin einen Fehler geworfen haben und zusätzlich kannst du noch in der Log-Datei nachsehen, welchen Fehler genau Prime95 da ausgegeben hat.

Zum Thema Testen: am Ende sollte man alles mit allem getestet haben. Also FFT "All" mit "auto" runtimePerCore jeweils in SSE, AVX und AVX2.
Das lohnt sich aber erst dann, wenn man die offensichtlicheren Fehler, die vergleichsweise schnell auftreten, beseitigt hat. Deswegen ist das Standardsetting auf 6 Minuten pro Kern.