CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[sp00n.82]

Über die letzten Tage bzw. Wochen habe ich mich näher mit dem Curve Optimizer bei Ryzen beschäftigt, hatte aber keine Möglichkeit gefunden, die Einstellungen vernünftig auf Stabilität zu testen. CineBench Singlethread lief eigentlich so gut wie immer durch, Prime95 mit Belastung auf allen Kernen war auch relativ einfach stabil zu bekommen. Auf Crashes im Idle zu warten oder in Spielen kam mir auch nicht so sinnvoll vor, und auf Reddit hatte jemand dann sogar von dem Windows Reparatur-Tool als gutem Stabilitätstest angefangen... das war mir dann doch zu blöd.

Also ist die Idee zu diesem Tool entstanden. Es ist ein PowerShell-Script, das eine Instanz von Prime95 startet und diese mit nur einem Worker Thread auf nur einem Kern laufen lässt. Und dieser Kern wird dann nach einer einstellbaren Zeit gewechselt, sodass man das Tool dann z.B. schön über Nacht laufen lassen kann und am nächsten Tag dann sieht, welche Kerne bisland einen Fehler verursacht haben.

Mittlerweile sieht es ganz gut für eine Veröffentlichung aus, wobei ich bisher der einzige bin, der das getestet hat, weitere Erfahrungsberichte wären also recht hilfreich.

Zu finden ist es hier:
https://github.com/sp00n/corecycler/releases

Aktuelle Version: 0.9.2.0 (19.10.2022)

Changelog:
Update 19.10.2022
Version 0.9.2.0 ist jetzt verfügbar:

• Die mitgelieferte Prime95-Version ist jetzt 30.8b17
• Die mitgelieferte y-Cruncher-Version ist jetzt 0.7.10 Build 9513
• Unterstützung von AVX-512
• Einige Fehler mit der Erkennung der Logdatei von Prime95 behoben

Spoiler

Update 09.05.2022
Version 0.9.0.0 ist jetzt verfügbar:

Spoiler

• Neuere Prime95-Versionen wie 30.7 und 30.8 werden jetzt unterstützt
• Die mitgelieferte Prime95-Version ist jetzt 30.8b15
• Bei neueren Prime95-Versionen wird die FFT Größe im Log ausgegeben, wenn ein Fehler aufgetreten ist. Das wird jetzt für die Ausgabe herangezogen sofern verfügbar.

Update 30.04.2022
Version 0.8.2.5 ist jetzt verfügbar:

Spoiler

• Ein reines Bugfix-Release, einige Sprachversionen wir Türkisch haben ein großes "I" in ein kleines "punktloses i" umgewandelt (also z.B. von "PRIME95" in "prıme95" anstatt "prime95"), was dann zu Fehlern geführt hat. Das sollte jetzt behoben sein.

Update 11.05.2021
Version 0.8.2.4 ist jetzt verfügbar:

Spoiler

• Einige Bugfixes

Update 08.05.2021
Version 0.8.2.2 ist jetzt verfügbar:

Spoiler

• Keine funktionalen Änderungen, es gibt jetzt aber mehr Informationen wenn ein Fehler bei den Process Performance Countern aufgetreten ist.

Update 06.05.2021
Version 0.8.2.1 ist jetzt verfügbar:

Spoiler

• 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)

Update 03.05.2021
Version 0.8.2.0 ist jetzt verfügbar:

Spoiler

• Anscheinend gibt es einen Bug in Prime 30.4 & 60.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

Update 25.04.2021
Version 0.8.1.0 ist jetzt verfügbar:

Spoiler

• 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

Update 13.03.2021
Version 0.7.9.0 ist jetzt verfügbar:

Spoiler

• Neue skipOnError Funktion
  Auf 1 gesetzt wird ein Kern mit einem Fehler bei den nächsten Überprüfungen übersprungen (Standardwert)
  Auf 0 wird der Kern auch bei den nächsten Durchläufen mitgetestet und die kumulierte Anzahl der Fehler dieses Kerns wird angezeigt

Update 12.03.2021
Version 0.7.8.9 ist jetzt verfügbar:

Spoiler

• Hoffentlich endgültig die Probleme mit dem Performance Process Countern behoben
• Ein neues "Huge" Preset für die FFT-Sizes hinzugefügt, was jetzt auch der eingestellte Standartwert ist

Update 11.03.2021
Version 0.7.8.8 ist jetzt verfügbar:
(Version zurückgezogen, da sie fehlerhaft war)

Spoiler

• Noch ein Fehler bei den Performance Process Countern behoben
• Einen Fehler behoben, wenn die config.ini korrupt war (z.B. kein Inhalt, weil direkt am Anfang abgestürzt durch instabilen Overclock)
• Die Affinity hatte bei CPUs mit 32 Kernen und 2 Threads nicht korrekt funktioniert, behoben
• Die "numberOfThreads" Einstellung hatte nicht funktioniert

Update 09.03.2021
Version 0.7.8.5 ist jetzt verfügbar:

Spoiler

• Neues "verbosityMode" Setting in der Config. Damit werden mehr Informationen ausgegeben (standardmäßig nur in die Logdatei).
• Neues "delayBetweenCycles" Setting in der Config. Damit kann eine Wartezeit zwischen dem Ende des Runs von einem zum anderen Kern festgelegt werden. Funktioniert nur in Kombination mit "restartPrimeForEachCore".
• Die Fehlererkennung von Prime95 wurde überarbeitet. Nun wird alle 10 Sekunden die generierte results_x.txt auf eine Fehlermeldung in den letzten 3 Zeilen untersucht, und erst wenn keine Fehlermeldung gefunden wurde wird auf die CPU-Auslastung als Erkennungsmerkmal zurück gegriffen.
  Hoffentlich behebt das die Probleme, dass Prime95 einen Fehler geworfen hat, das Script aber keine entsprechende Ausgabe anzeigt.

Update 08.03.2021
Version 0.7.7 ist jetzt verfügbar:

Spoiler

Damit sollten jetzt auch deutschsprachige Windows-Versionen korrekt funktionieren, und die Verfügbarkeit des Process Counters wird vor dem Start abgefragt.
Die Readme habe ich auch um eine "Troubleshooting & FAQ"-Sektion ergänzt, dort wird auch auf die beigefügte "enable_performance_counter.bat" Batch-Datei hingewiesen, die den Performance-Counter wieder aktivieren sollte, wobei ich keine Garantie dafür übernehmen kann, dass das tatsächlich funktioniert.
Im Prinzip macht die Batch Datei nur das, was in den entsprechenden Anleitungen manuell gemacht wird.

Und auch Version 0.7.8.1:

Spoiler

Die installierte .NET-Version wird jetzt auf mindestens 3.5 geprüft.
Überarbeitete Fehlermeldung bei fehlenden Performance Process Countern.

Zum Ausführen reicht ein Doppelklick auf "Run CoreCycler.bat".
Lest die beigefügte readme.txt und schaut euch die config.ini an, dort kann man ein paar Sachen ändern.


Screenshots des Scripts in Aktion:



Hier noch eine beispielhafte Auswertung, wie es bei mir ablief während der Entwicklung. Wie man sieht, braucht das ganze weiterhin seine Zeit (nein, die Auswertung wird nicht automatisch angelegt, das müsst ihr selbst machen ):




Ein Auszug aus der readme.txt:

Mit diesem kleinen Script kann man die Einstellungen des Curve Optimizer für jeden einzelnen Kern seiner CPU auf Stabilität überprüfen. Das Script startet Prime95 mit einem Worker-Thread und setzt die "Affinity" von Prime95 abwechselnd auf die einzelnen Kerne, d.h. es wird immer nur ein einziger Kern gleichzeitig belastet, wodurch sehr gut die Stabilität der Curve Optimizer Einstellung ausgetestet werden kann.
Die bisherigen Stabilitätstests mit PBO und dem Curve Optimizer waren entweder nicht zuverlässig (Cinebench, Windows Repair) oder mit sehr viel Arbeit verbunden (manuell die Affinity über den Task Manager setzen, warten, neu setzen, etc) oder gleich beides. Mit diesem Script braucht man eigentlich nur noch Zeit - davon allerdings doch recht viel. Da immer nur ein Kern gleichzeitig getestet werden kann, bräuchte man für einen 12 Stunden "Prime-stable" Stabilitätstest, wie man ihn bei normalen Overclocks gerne macht, bereits 12x12 = 144 Stunden bei einem 5900X. Bei einem 5600X mit seinen 6 physischen Kernen dann entsprechend "nur" 6x12 = 72 Stunden.
Solch ein All-Core Test mit Prime95 ist leider nicht effektiv mit dem Curve Optimizer, da die Kerne dann nicht so hoch takten können, und man so eventuelle Instabilitäten nicht erkennen kann. Bei meiner CPU konnte ich z.B. den Curve Optimizer auf -30 auf allen Kernen und +75 MHz Boost stellen und damit problemlos 24 Stunden Prime95 durchlaufen lassen,während ich bei diesem Einzeltest dann bei +0 MHz Boost einen der Kerne nur noch mit -9 stabil laufen lassen konnte (ein anderer dagegen lief auch beim Einzeltest noch mit -30 weiter).

Beim ersten Start des Scripts wird automatisch eine config.ini angelegt (die config.default.ini wird kopiert). In dieser kann man einige Parameter ändern, z.B. welcher Modus beim Testen ausgeführt wird (SSE, AVX, AVX2, CUSTOM, wobei SSE den höchsten Takt produziert, da es die CPU am wenigsten belastet), wie lange ein einzelner Kern getestet werden soll, bevor es zum nächsten geht, ob bestimmte Kerne ignoriert werden sollen, etc. Für jedes Setting ist in der Datei auch eine Beschreibung vorhanden.

Als Startpunkt am Anfang könnte man im Curve Optimizer jeden Kern auf z.B. auf -15 oder -20 setzen und dann schauen, welcher Kern durchläuft und welcher davon einen Fehler wirft. Die Kerne mit Fehler könnte man dann z.B. um 2 oder 3 Punkte nach oben setzen (also z.B. von -15 auf -13), die fehlerfreien dagegen 2 oder 3 weiter ins Negative (-15 auf -17). Ab einem gewissen Punkt kommt man aber nicht daran vorbei, nur noch um einen Punkt nach oben/unten zu korrigieren und das Tool sehr lange laufen zu lassen, um auch die letzten Instabilitäten herauszufiltern.

Es ist übrigens beabsichtigt, dass bei aktiviertem Hyperthreading / SMT nur der erste Thread eines jeden Kerns belastet wird, da dabei ein höherer Takt erreicht wird, wie wenn beide (virtuellen) Threads eines Kerns belastet würden. Man kann in der config.ini allerdings auch die Anzahl der Threads auf 2 setzen, wenn man das möchte, dann werden beide belastet.[/spoiler]

 

[Verangry]

@sp00n.82

Danke!
Genau so etwas habe ich gesucht.

Kurze Frage:
Gab es von 29.8b5 zu 30.4b9 noch irgend welche große Änderungen?

Ich hatte meine Kerne alle mit 29.8 B5 ausgelotet, und ohne Fehler je Kern 20 Minuten überstanden, mit der 30.4 B9 gibt es beim 48k Run Fehler.

Stellt sich mir die Frage, traue ich der neuen Version oder der alten?
Klar, Fehler bleibt Fehler, ich würde nur gerne wissen wieso es bei dem einen "stabil" und beim anderen "instabil" ist

 

[sp00n.82]

Kurze Frage:
Gab es von 29.8b5 zu 30.4b9 noch irgend welche große Änderungen?

Ich hatte meine Kerne alle mit 29.8 B5 ausgelotet, und ohne Fehler je Kern 20 Minuten überstanden, mit der 30.4 B9 gibt es beim 48k Run Fehler.

Stellt sich mir die Frage, traue ich der neuen Version oder der alten?
Klar, Fehler bleibt Fehler, ich würde nur gerne wissen wieso es bei dem einen "stabil" und beim anderen "instabil" ist

Ich weiß nicht, inwiefern es Änderungen gab, die den Torture Test betreffen. Aber ja, Fehler ist Fehler.

Anzumerken ist noch, dass bei dem Script hier standardmäßig der SSE-Modus verwendet wird, also kein AVX und kein AVX2. Aus dem einfachen Grund, dass damit etwas weniger Last auf dem Kern erzeugt wird (bei weiterhin 100% Auslastung), wodurch der Boost Takt etwas höher gehen kann als bei AVX / AVX2. Dadurch erkennt man eher Instabilitäten im Grenzbereich, die bei einem Test mit AVX so nicht auftreten würden.

In der config.ini kann man aber auch AVX oder AVX2 dazuschalten. Das entspricht den beiden Checkboxen beim Torture-Test von Prime95.
Und die zu testenden FFTs kann man dort auch einstellen.

 

[Verangry]

Hab das Script gerade mal im Discord geteilt, wir alle (die es bislang getestet haben) bekommen entweder beim 48k Test einen Fehler oder es wird angezeigt, das alle Kerne Fehler werfen.

Mit manuell gesetzten 2-138 gibt es hingegen keine Fehler. Also irgendwas stimmt da nicht. (Und ja ich nutze immer alle avx (2) Instruktionen, weil ich ja alles abdecken will.

 

[sp00n.82]

Hab das Script gerade mal im Discord geteilt, wir alle (die es bislang getestet haben) bekommen entweder beim 48k Test einen Fehler oder es wird angezeigt, das alle Kerne Fehler werfen.

Mit manuell gesetzten 2-138 gibt es hingegen keine Fehler. Also irgendwas stimmt da nicht. (Und ja ich nutze immer alle avx (2) Instruktionen, weil ich ja alles abdecken will.

Das Problem mit AVX und AVX2 ist, dass das eine höhere Last = höhere Temperatur in dem getesteten Kern erzeugt, wodurch der Boost-Takt halt nicht so hoch gehen kann. Und evlt. liegen auch noch andere Spannungen an.
Ich hab das mal getestet, so sah das bei mir aus:




In der config.ini kannst du auch AVX oder AVX2 aktivieren, dann läuft er damit.

Oder du könntest manuell auch mal mit Prime95 gegentesten, indem du die Worker Threads auf 1 setzt und AVX und AVX2 deaktivierst und dann die Affinity des prime95.exe Prozesses im Task Manger auf CPU 0 setzt:



// Edit
Natürlich kann auch sein, dass irgendwo im Script noch ein Bug lauert. Die Testeranzahl war ja wie erwähnt bisher n=1 (ich 🙃).

 

[Verangry]

Deswegen teste ich es ja, je mehr desto besser..

Also aktuell ist es so, dass bei jedem der es bislang ausgeführt hat (egal ob SSE oder AVX(2) beim 48k Test aussteigt.

Aber nichts destotrotz find ich das script gut.

Und als gegentest habe ich gerade mal versucht die "alte" p95.exe gegen die neue zu ersetzen, aber da gibt es Fehler, heißt da wurde schon was an der Testmethodik geändert.

Ich mag es jetzt schon. noch ein paar feinarbeiten und es wird.

 

[sp00n.82]

Und als gegentest habe ich gerade mal versucht dei alte p95.exe gegen die neue zu ersetzen, aber da gibt es Fehler, heißt da wurde schon was an der Testmethodik geändert.

Welche war denn die alte Version?

Wenn du mit der alten Version glücklicher bist, kannst du auch einfach diese Version in den /p95 Ordner kopieren.

 

[Verangry]

Alles gut, ich find nur die Unterschiede seltsam, manuell alles ok (egal welche version) mit Script eben fehler bei 48k instant.. (Alte Version wie gesagt die 29.8B5)

 

[sp00n.82]

@Verangry Hast du beim manuellen Test auch AVX und AVX2 deaktiviert gehabt? Und/oder in der config mal auf AVX/AVX2 gestellt?

 

[Verangry]

Bei manuellem Testen nehme ich immer AVX2, wie gesagt will ich ja maximale Stabilität bei hoher Belastung haben.

Für die Low Load Szenarien nutze ich dann die Idle States zwischen den Runs, wenn Fehler kommen, dann meinstens zwischen den load / Idle drops und da hilft einfach ein 2 - 5 minuten Idle Timer zwischen den Tests.

Aktuell teste ich viel in Games, die viele Kerne unterstützen, da die Wechsellast oft ein Fehler hervorruft. Games Wie BFV oder COD, Horizon Zero Dawn oder Troy, sowie CyberPunk sind da echt gut geeignet.

Das Hauptproblem sehe ich aktuell beim Lastwechsel zwischen low / idle zu high load, denn dort steigen die meisten Kerne aus, während unter normaler Last alles ok ist.

 

[maverick80]

ERROR: 08:27:17
ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 3 (CPU 6)
ERROR MESSAGE: The Prime95 process doesn't use enough CPU power anymore (only 0% instead of the expected 8.33%)
ERROR: The error likely happened at FFT size 48K

 

[Verangry]

Hab nun noch ein wenig getestet, liegt wohl am SSE und damit dem höheren Boost.
Solange avx aktiv ist, taktet die CPU bei mir mit 4950mhz mit sse dann auf 4987mhz und wirft Fehler.

Nun stellt sich mir die Frage, was ist näher am Alltag, denn unter normalen Bedingungen kommen gar keine Fehler, kein whea, kein instant Reboot, kein Kern steigt aus usw, dabei boosten die Kerne in Games dann allcore auf 4925mhz und bei Teillast auf über 5ghz..

Auch wie gesagt unter avx steigt kein Kern aus sondern nur mit sse.

@maverick80 hattest du avx aktiviert oder auch mit SSE? (Also avx und avx 2 deaktiviert)

 

[SVΞN]

@sp00n.82 sehr coole Sache, eine Meldung zu deinem Tool ist dir sicher.

Frage: Dürfen wir dein Tool in das Download-Archiv von ComputerBase übernehmen?

Liebe Grüße
Sven

 

[maverick80]

@Verangry über .bat

 

[Verangry]

@sp00n.82
Da liegt wohl das Problem mit der Power Meldung. (gerade im Discord geposted worden, kannste da mal drüber schauen?)

Prime läuft also eigentlich auf dem zu testenden Kern weiter, aber es wird wohl nicht erkannt.

 

[sp00n.82]

Hab nun noch ein wenig getestet, liegt wohl am SSE und damit dem höheren Boost.
Solange avx aktiv ist, taktet die CPU bei mir mit 4950mhz mit sse dann auf 4987mhz und wirft Fehler.

Nun stellt sich mir die Frage, was ist näher am Alltag, denn unter normalen Bedingungen kommen gar keine Fehler, kein whea, kein instant Reboot, kein Kern steigt aus usw, dabei boosten die Kerne in Games dann allcore auf 4925mhz und bei Teillast auf über 5ghz...

Für mich ist ein Fehler ein Fehler, ich will ein möglichst 100% stabiles System haben, deswegen habe ich ja dieses Script geschrieben. Und ok bei AVX, aber Fehler bei SSE ist für mich eben nicht stabil. Ob es für dich ausreicht, musst du halt selbst entscheiden. Meiner Meinung wird es bei "nur" AVX-stable dann irgendwann auch im normalen Betrieb Fehler geben. Vermutlich keine kompletten Abstürze, da Prime95 ja in der Regel auch nur noch einen Berechnungsfehler auswirft, aber auch das will ich weitestgehend vermeiden.

Scheint aber so, als müsste ich in die Readme einen längeren Abschnitt zu SSE vs. AVX aufnehmen.

Gestern im Bett liegend 😬 habe ich auch schon über einen neuen "ROTATE" Modus nachgedacht, der einen Durchlauf mit SSE, danach einen mit AVX und dann noch einen AVX2 macht. Prime95 muss halt jedes Mal neu gestartet werden dafür, also vermutlich würde ich das nicht pro Kern, sondern pro "Iteration" machen (also nachdem alle Kerne durchgelaufen sind). Mal sehen.

Da liegt wohl das Problem mit der Power Meldung. (gerade im Discord geposted worden, kannste da mal drüber schauen?)

Prime läuft also eigentlich auf dem zu testenden Kern weiter, aber es wird wohl nicht erkannt.

Hm, ich hatte zu Anfang auf meinem Haupt-Win10 mal so ein Problem (ich hab noch eine Installation nur für Übertaktungs-Spielereien), da waren die systeminternen Windows-Counter irgendwie beschädigt. Ich muss mal suchen, ob ich die Lösung mit Google wiederfinden kann.

Wenn Prime95 mit einem Fehler den Worker Thread beendet, steht ja normalerweise dieser Fehler in der generierten results.txt und wird dann vom Script auch geparsed und ausgegeben (siehe den Screenshot im ersten Post). Prime95 kann natürlich aber auch komplett crashen und gegebenenfalls nichts mehr in die results.txt schreiben können und/oder der Check fällt genau auf den Zeitpunkt, wo Prime noch nichts geschrieben hat (es cached den Output anscheinend eine Zeit lang).
In diesem Fall wird dann nur diese generische Meldung mit "not enough CPU power" ausgegeben, wie sie auch @maverick80 oben gepostet hat. Evtl. wäre das eine Erklärung für die gehäuften Probleme bei 48k, was bei einem SSE-Durchlauf ja als zweite FFT Size an der Reihe ist und mit dem 30-sekündigem Check-Intervall für den CPU-Verbrauch zusammenfallen könnte. Da muss ich noch mal genauer Nachschauen.


@SV3N
Die Lizenz ist Creative Commons CC BY-NC-SA, also kann jeder dieses Tool weiterverbreiten, solange dafür nicht direkt Geld verlangt wird.
Ich denke also, unter diese Einschränkung fallt ihr nicht (auch wenn ihr mit der Seite an sich natürlich Geld verdient).
Wobei ich sagen muss, dass es dafür vermutlich noch etwas zu früh ist. Ich brauche erstmal etwas Feedback von den Testern hier. 🤗
Und längerfristig werde ich die Releases wohl auch nur auf der Github-Seite veröffentlichen, und vermutlich auch darum bitten, eventuelle Fehler und Probleme dort im Issue-Tracker zu hinterlegen, anstatt ein ständiges Auge auf diese Threads zu haben. Eure gehostete Datei könnte also recht schnell veraltet sein.

 

[Verangry]

Ich glaube du hattest mich falsch verstanden. Mit dem Script kommen bei sse Fehler, mit avx nicht. (Bei mir zumindest, die anderen Fehler die auftauchten sind halt diese 48k Fehler mit dem "Power-Fehler")

Liegt es nun am Script oder der Prime Version oder am instabilen OC, manuell mit älterer Prime Version gibt es halt keine Probleme.

Deswegen bleibe ich aktuell bei der normalen Variante und lote die Kerne einzeln, manuell aus ohne Script.

 

[SyntaX]

Bei mir gibt es mit dem Script bei jedem Core bei 48K einen Fehler, Manuell bei Prime per Core aber ohne Probleme.
Habe den Curve Optimizer aktuell nicht mal aktiviert, auch kein PBO.
Hab das System mit aktuellen Settings nun fast 2 Monate ohne ein Problem am laufen....komisch.

Die Idee ist Klasse, nur weiß ich nicht was ich mit dem Ergebnis anfangen soll.
Fühlt sich so an als wenn man nach Symptomen googelt und der kurzfristige Tod hervorgesagt wird.

Muss wohl ein Fix her

 

[sp00n.82]

Ich glaube du hattest mich falsch verstanden. Mit dem Script kommen bei sse Fehler, mit avx nicht. (Bei mir zumindest, die anderen Fehler die auftauchten sind halt diese 48k Fehler mit dem "Power-Fehler")

Ich vermute hier tatsächlich, dass bei den anderen mit 48k Fehler die Windows Counter Probleme machen und die Prozessorlast daher nicht korrekt ausgelesen werden kann. Bei @SyntaX wohl auch gerade wieder.

Bei dir dagegen vermute ich einen instabilen Overclock im Grenzbereich. Ich hatte auch schon Prime-Fehler bei Kernen, die zuvor 7 Runs (Nächte) durchgelaufen sind. Das ist halt das Problem, wenn man immer nur einen Core einzeln testen kann, ein 12h prime-stable Setup dauert halt 12 Stunden * die Anzahl der zu testenden Kerne.

Ergänzung (7. März 2021)

Vielleicht kann jemand mit dem 48k-Fehler mal diesen Befehl in einem PowerShell-Terminal ausführen und Rückmeldung geben, ob da eine Ausgabe erfolgt oder eine Fehlermeldung:

(Get-Counter "\Process(*)\ID Process").CounterSamples

 

[SyntaX]

Vielleicht kann jemand mit dem 48k-Fehler mal diesen Befehl in einem PowerShell-Terminal ausführen und Rückmeldung geben, ob da eine Ausgabe erfolgt oder eine Fehlermeldung:

(Get-Counter "\Process(*)\ID Process").CounterSamples

Gibt bei mir ein Fehler raus, liegt wohl daran das ich einige Counter deaktiviert habe, hätte früher drauf kommen sollen
Sollte im ersten Post erwähnt werden welche Performance Counter benötigt werden.

Get-Counter : Das angegebene Objekt wurde nicht auf dem Computer gefunden.
In Zeile:1 Zeichen:2

• (Get-Counter "\Process(*)\ID Process").CounterSamples
• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidResult: ( [Get-Counter], Exception
+ FullyQualifiedErrorId : CounterApiError,Microsoft.PowerShell.Commands.GetCounterCommand