CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

sp00n

Enthusiast
Thread Starter
Mitglied seit
04.09.2012
Beiträge
432
Ü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


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:
screenshot.start.6min.small.pngscreenshot.error.png


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 ;)):
summary.example.png



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.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Interessant, vielen Dank!

Habs eben mal angeschmissen, dabei ist der PC sofort abgestürzt.

Die Idee ist gut, scheint aber noch nicht ganz ausgreift zu sein, oder?

Edit:

Kann das tool auch anzeigen, wie die aktuelle Curve Optimizer Einstellung ist?
 
Zuletzt bearbeitet:
Interessant, vielen Dank!

Habs eben mal angeschmissen, dabei ist der PC sofort abgestürzt.

Die Idee ist gut, scheint aber noch nicht ganz ausgreift zu sein, oder?

Edit:

Kann das tool auch anzeigen, wie die aktuelle Curve Optimizer Einstellung ist?
Wenn der PC direkt abstürzt, dann ist dein Setting wohl recht instabil vermute ich. 😬
Du kannst ja mal gegentesten, indem du Prime95 manuell auf einen Worker Thread setzt und mit dem Taskmanager dann die Affinity von Prime95 auch nur auf den ersten Core setzt (bzw. auf die erste CPU, wenn Hyperthreading aktiviert ist). Genau das macht das Script ja, halt automatisiert. Eventuell muss man dann auch noch die beiden AVX und AVX2-Checkboxen abwählen, da das Tool standardmäßig ohne AVX und AVX2 testet, aus dem einfachen Grund, dass damit etwas weniger Last = Hitze auf einem Kern produziert wird (bei weiterhin 100% Auslastung), wodurch der Boost Takt höher gehen kann. Dadurch werden eventuelle Instabilitäten im Grenzbereich besser erkannt.


Die Curve Optimizer Einstellungen auslesen oder gar ändern kann es leider nicht. Hätte ich mir auch gewünscht, dass das irgendwie geht.


// Edit
Bilder zur Verdeutlichung.
1615072134129.png1615072138214.png
 
Zuletzt bearbeitet:
Hi

Nette Idee.

Aber die Spannung geht nicht mit hoch !

5Ghz an Core 0 ...und die Spannung bleibt bei 1,4 ~ 1,43 Volt. DAs geht natürlich nicht lange gut.......so fallen alle cores der Reihe nach aus. :fresse2:

Habe HW Info daneben laufen lassen um das zu überprüfen.

In Cinebench z.b. geht die Vcore auf 1,45~1,5 V hoch. So soll es ja auch sein.

Gruß Bernd
 
Zuletzt bearbeitet:
Hi

Nette Idee.

Aber die Spannung geht nicht mit hoch !

5Ghz an Core 0 ...und die Spannung bleibt bei 1,4 ~ 1,43 Volt. DAs geht natürlich nicht lange gut.......so fallen alle cores der Reihe nach aus. :fresse2:

Habe HW Info daneben laufen lassen um das zu überprüfen.

In Cinebench z.b. geht die Vcore auf 1,45~1,5 V hoch. So soll es ja auch sein.

Gruß Bernd
Das ist eben das normale Verhalten von dem Prime95-Test mit deaktiviertem AVX/AVX2. Das Script an sich macht ja nichts hinsichtlich der CPU, es delegiert alles nur weiter an Prime95.
 
Hallo,
ich finde die Idee vom Skript super und hoffe, dass es auch bald gut nutzbar wird fürs CO ausloten.
Aktuell scheitert es immer an ein paar Dingen, die sich meist schnell fixen lassen (bzw. schon gefixt worden sind).
Letztes Problem, was aufgetaucht ist:
"FATAL ERROR: Could not set the affinity to Core 15 (CPU 30 and 31)!"
Da fehlt es noch an Robustness im Skript - es kann vorkommen, dass Windows verweigerrt die Affinity (aus welchem Grund auch immer) im ersten Versuch zu setzen. Manchmal sind 2 Versuche nötig (öfters war es bei mir bisher nie der Fall). Selbiges Verhalten auch manchmal im Taskmanager, dass man zwei mal Bestätigen muss, bis die Affinity geändert ist.
Wäre es möglich hier mehrere Versuche einzubauen die Affinity zu setzen und nicht nach dem ersten Versuch gleich abzubrechen?
 
(nein, die Auswertung wird nicht automatisch angelegt, das müsst ihr selbst machen ;)):
das wäre doch ne super Idee. Ich hab zwar keine Ahnung vom Skripten, aber wenn man automatisiert ne Exceltabelle rauswerfen könnte, wäre das doch ne super Sache. Ansonsten ist es sehr interessant zu sehen, das sich die gemeldete "Qualität" deiner Kerne nicht mit dem CO Setting deckt. Kern 0 und 2 haben ne 174, aber Kern 1 den größten CO Offset.

Danke fürs veröffentlichen des Tools, das wird vielen Leuten eine Menge Arbeit sparen - und kann im Gegensatz zu gewissen anderen Tools auch keine gefährlichen Settings setzen.
 
es kann vorkommen, dass Windows verweigerrt die Affinity (aus welchem Grund auch immer) im ersten Versuch zu setzen. Manchmal sind 2 Versuche nötig (öfters war es bei mir bisher nie der Fall). Selbiges Verhalten auch manchmal im Taskmanager, dass man zwei mal Bestätigen muss, bis die Affinity geändert ist.
Wäre es möglich hier mehrere Versuche einzubauen die Affinity zu setzen und nicht nach dem ersten Versuch gleich abzubrechen?
Interessant, das habe ich bisher noch nie beobachtet. Aber ein zweiter Versuch ist recht trivial umzusetzen, kommt ins nächste Release.


das wäre doch ne super Idee. Ich hab zwar keine Ahnung vom Skripten, aber wenn man automatisiert ne Exceltabelle rauswerfen könnte, wäre das doch ne super Sache. Ansonsten ist es sehr interessant zu sehen, das sich die gemeldete "Qualität" deiner Kerne nicht mit dem CO Setting deckt. Kern 0 und 2 haben ne 174, aber Kern 1 den größten CO Offset.
In der Exceltabelle (eher eine .csv-Datei) würde dann allerdings maximal stehen, welcher Kern durch lief und welcher Kern einen Fehler geworfen hat. Für sämtliche weiteren Infos wäre deutlich mehr Aufwand nötig, und die Info aus der .csv-Datei wird ja auch jetzt schon im Terminal angezeigt, deswegen steht das ziemlich weit unten auf meiner Todo-Liste.

Bezüglich der Einstufung meiner Kerne habe ich mich auch etwas gewundert. Kern 1 überholt jetzt dadurch minimal die beiden anderen Kerne beim Boost Takt, obwohl er nur an dritter Stelle eingeordnet wurde.
 
Moin,

theoretisch müsste man sich doch mit dem CoreCycler + CTR quasi sein eigenes PBO bauen können, oder? Mein Gedanke wäre folgender:
- Schönes MT Setting raus fahren und als Allcore Profil im CTR speichern.
- Mit entsprechend höherer "ST Voltage"* per CoreCycler schönes Setting suchen und als ST Porfil im CTR speichern.

*Nach meinem Verständis darf die Voltage bei ST ja deutlich höher liegen als bei MT (macht PBO ja auch so), daher der Gedanke.

Bzgl. CTR Profile:
 
Frohe Ostern!

Version 0.8.0.0 ist jetzt verfügbar.
Aida64 und Y-Cruncher werden nun unterstützt!


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


Changelog:
  • Prime95 auf Version 30.5 Build 2 upgedatet
  • Aida64 und Y-Cruncher werden jetzt unterstützt! Man kann jetzt festlegen, welches Stresstest-Programm verwendet werden soll (Achtung: lest den entsprechenden Abschnitt zu Aida64 in der readme.txt)
  • Die config.ini wurde restrukturiert, um Aida64 und Y-Cruncher zu unterstützen. Alte Config-Dateien funktionieren nun nicht mehr!
  • Eine Einstellung "suspendPeriodically" hinzugefügt, die standardmäßig aktiv ist. Mit dieser Einstellung wird das Stresstest-Programm in regelmäßigen Abständen pausiert und wieder fortgesetzt, um Lastwechsel zu simulieren
  • Eine Einstellung "coreTestOrder" hinzugefügt, die standardmäßig "Alternate" (für CPUs mit mehr als 8 Kernen/2 CCDs) bzw. "Random" (für max. 8 Kerne/1 CCD) gesetzt ist. Man kann aber auch eine komplett benutzerdefinierte Reihenfolge eingeben, in der die Kerne getestet werden sollen (z.B. "5, 7, 5, 1, 0, 7, 4")
  • Mehrere neue Presets für Prime95 hinzugefügt: "Moderate", "Heavy" & "HeavyShort". In der Config-Datei stehen mehr Infos zu diesen Presets
  • Die Priorität des Stresstest-Programms wird jetzt auf "Hoch" gesetzt, damit ihm andere Prozesse nicht Prozessorzeit "klauen" können, was anderenfalls zu Fehlalarmen bei der Erkennung der Prozessorauslastung führen könnte
  • Der Start eines Stresstest-Programms stiehlt nun nicht mehr den Fokus des gerade offenen Fensters (bzw. gibt ihn sofort wieder zurück)
  • Beim Drücken von STRG+C versucht das Script nun, das laufende Stresstest-Programm ebenfalls zu beenden (sofern es noch CPU-Auslastung verursacht)
  • Der Titel des Fenster wird nun auf "CoreCycler" gesetzt
  • Die ungefähre Prozessorgeschwindigkeit wird nun in den Verbose-Logs ausgegeben (leider ist der Wert nicht so genau wie z.B. HWInfo64 oder Ryzen Master, weswegen er auch nicht in der normalen Ausgabe erscheint)
  • Alle Logdateien landen nun im /logs Ordner, nicht mehr verteilt über mehrere Ordner
  • Im /tools Ordner gibt es nun eine "analyze_prime95_logfile.ps1"-Datei, mit der man ermitteln kann, wie lange Prime95 für einen kompletten Durchlauf aller FFT-Größen gebraucht hat
  • "CoreTunerX" befindet sich nun im /tools Ordner. Mehr Infos zu CoreTuneX und für was es gut ist finden sich hier: https://github.com/CXWorld/CoreTunerX
 
@sp00n Danke für das Tool. Ich benutze es zum ersten Mal. Was sind deine Erfahrungen bezüglich Y-Cruncher 00-x86 vs. Prime95 SSE, wenn es rein darum geht, auf "Idle"-Stabilität zu prüfen? Hast du eine Präferenz?
 
@sp00n Danke für das Tool. Ich benutze es zum ersten Mal. Was sind deine Erfahrungen bezüglich Y-Cruncher 00-x86 vs. Prime95 SSE, wenn es rein darum geht, auf "Idle"-Stabilität zu prüfen? Hast du eine Präferenz?
Y-Cruncher lief bei mir entweder durch oder verursachte direkt einen kompletten Neustart des Rechners. 😅
Allerdings habe ich auch bei weitem nicht so viel Testzeit in Y-Cruncher reinstecken können wie mit Prime95 bisher. Als zusätzliche Testoption finde ich es nützlich, mein Primärtest bleibt aber weiterhin Prime95.
 
Als Rückmeldung von mir, Prime95 SSE ist deutlich besser darin Instabilität zu erkennen als Y-Cruncher.
Die beste Kombination, die ich durch Zufall gefunden habe, ist Corecycler mit Prime95 SSE und zeitgleich einen HD Stream über die Best Player & IPTV App (erhältlich im Microsoft Store) laufen zu lassen. Die App lässt über die GPU rendern, aber irgendetwas führt dazu, dass sich mit CoreCycler/Prime95 SSE Fehler schneller finden lassen, wenn ich einen HD Stream gleichzeitig laufen lasse.
 
Version 0.8.1.0 ist jetzt verfügbar.

Download:


Changelog:
  • 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
 
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!




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
 
Zuletzt bearbeitet:
Infected file detected
18 minutes ago
Feature:Antivirus
Bitdefender moved a threat to quarantine. File name: C:\Users\xxx\CoreCycle\CoreCycler-v0.8.2.0\test_programs\p95\prime95.exe. It is recommended that you run a System Scan to make sure your system is clean.
Restore


Bitdefender meist nach dem 3ten Lauf... :(
 
Infected file detected
18 minutes ago
Feature:Antivirus
Bitdefender moved a threat to quarantine. File name: C:\Users\xxx\CoreCycle\CoreCycler-v0.8.2.0\test_programs\p95\prime95.exe. It is recommended that you run a System Scan to make sure your system is clean.
Restore


Bitdefender meist nach dem 3ten Lauf... :(
:coffee2:
Ist die offizielle Version von Prime95, von hier:

VirusTotal zeigt da auch nichts an, auch nicht beim BitDefender:


Du kannst Prime95 aber auch gegen eine einigermaßen aktuelle Version deiner Wahl austauschen, indem du es in das \test_programs\p95\ Verzeichnis kopierst.

Im Notfall müsste man eine Ausnahme hinzufügen. Evtl. springt die Heuristik auf die wiederholte CPU-Auslastung an. 🤷‍♂️
 
Jupps, hab beides kombiniert, läuft nun seit 4 Stunden.

Edit: Hm, oder auch nicht...

Feature:Advanced Threat Defense
Bitdefender detected potentially malicious behavior and blocked all applications involved. Detection ID: SuspiciousBehavior.B9B2AD1255D172AA

Irgendne Powershell.exe mit ExecutionPolicy Bypass ausgelöst durch script-corecycler.ps1...

Bin nun unsicher, obs tatsächlich am Bitdefender liegt oder an instabilität, kann leider bei der Advanced Threat Defense keine Ausnahme für die Datei, oder das Script einfügen, der Button ist ausgegraut.
 
Zuletzt bearbeitet:
Irgendne Powershell.exe mit ExecutionPolicy Bypass ausgelöst durch script-corecycler.ps1...
Das kann natürlich auch sein.
Standardmäßig blockiert Windows die Ausführung jeglicher PowerShell-Scripte (Einstellung "Restricted"), mit Get-ExecutionPolicy -List kann man sich die momentane Einstellung anzeigen lassen, mit Set-ExecutionPolicy -ExecutionPolicy WERT kann man sie ändern.
Das Script, bzw. die Batch-Datei nutzt nun die ExecutionPolicy "Bypass", um das Script starten zu können, ohne dass diese Standardeinstellung vom Benutzer verändert werden muss, d.h. seine ursprüngliche Einstellung bleibt bestehen und wird nur beim Aufruf dieses Scripts übergangen (eben ein "Bypass").
Kann also schon sein, dass ein paranoid eingestelltes Virenprogramm da Alarm schlägt, wobei das der erste derartige Bericht ist, den ich zu hören bekommen habe. Allzu weit verbreitet scheint es also nicht zu sein.

Mehr Infos:
 
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)

 
Der CoreCycler ändert aber nicht das offset, oder? Es muss manuell das Offset mit dem Curve Optimizer eingestellt werden?
 
Der CoreCycler ist ein reines Testprogramm. Version 0.9.1.0 ist mittlerweile übrigens verfügbar.

PJVol von overclockers.net hat aber ein Tool geschrieben, bei dem man die CO Settings direkt aus Windows verändern kann:
PBO2 Tuner
 
Gibt es eine Möglichkeit zu prüfen, ob die Curve Werte von PBO2 tuner übernommen wurden?
 
Mittels eine Cinebench vorher/nacher Vergleich siehst du das.
 
Ich habe nun mit CoreCycler Prime auf Auto >22h laufen lassen. Ist das die Einstellung um max. Stabilität zu testen? Oder gibt es eine bessere Option? Und wie lange sollte man es damit laufen lassen je Kern 24h?! Prime sollte man früher min. 24h laufen lassen, auf allen Kernen.
Was mir aufgefallen ist, dass die CMD Ausgabe inzwischen recht schnell sich nicht mehr aktualisiert, wenn man CoreCycler ein zweites mal oder mehrmals startet. In den Logs wird weiter geschrieben, mit "pass" :-)

EDIT:
Durch die Curve Parameter wird nicht der Stromverbrauch reduziert sondern nur die max Freqeunz erhöht, oder? Dazu müsste man die TDP/PPT reduzieren.
Beitrag automatisch zusammengeführt:

Gibt es so etwas wie PBO2 Tuner auch für die RAM Timings? Damit man die DRAM Calculator for Ryzen übernehmen kann?
 
Zuletzt bearbeitet:
Prime lasse ich nie solange laufen. Höchsten ein bis zwei Durchgänge und dann noch ein anderes Tool.
 
Ich habe es mit CPU-z Bench überprüft, 635 Punkte ohne und 659 Punkte mit Curve Wertoptimierung, macht ~3,7% mehr Perf.
 
Ich habe nun mit CoreCycler Prime auf Auto >22h laufen lassen. Ist das die Einstellung um max. Stabilität zu testen? Oder gibt es eine bessere Option? Und wie lange sollte man es damit laufen lassen je Kern 24h?! Prime sollte man früher min. 24h laufen lassen, auf allen Kernen.
Was mir aufgefallen ist, dass die CMD Ausgabe inzwischen recht schnell sich nicht mehr aktualisiert, wenn man CoreCycler ein zweites mal oder mehrmals startet. In den Logs wird weiter geschrieben, mit "pass" :-)
Es kommt darauf an, wie du "stable" definierst. Für mich wären das in der Tat ~24h pro Kern. Für andere, die vielleicht nur zocken wollen, können das dann aber auch weniger sein.
Im Prinzip solltest du auch alle Settings mal durchtesten, also SSE, AVX und AVX2 jeweils mit allen FFT Größen. Und dann natürlich auch noch andere Stresstestprogramme verwenden (Y-Cruncher wird ja zb auch mitgeliefert).


Den zweiten Abschnitt verstehe ich nicht ganz, inwiefern mehrmals starten? Das Fenster sollte sich immer aktualisieren, wenn es das nicht tut, dann hat man evtl. unbeabsichtigt etwas im Fenster markiert, was die Skriptausführung stoppt.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh