CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[FB07]

@LuxSkywalker

Aber BBP ärgert die Kerne am meisten (zumindest bei mir)

Was bringen die 3 Tests für grobe wenn bei BBP die Kiste abschmiert, dann würde ich das auch mit in die Config reinnehmen für ein Schnelltest

 

[LuxSkywalker]

da hast du Recht

ich versuche das morgen mal nachzustellen bei mir und werde dann meinen Post editieren

 

[LehmannE]

Hallo,

ich dachte jetzt habe ich es geschafft. Ist das fall!
Es läuft die Feintuning Config durch. Nachmittag so 3 bis 4 durch Läufe und ohne Fehler. Jetzt am Wochenende Samstag früh gestartet und bis heute Sonntag. 9 Durchläufe und kein Fehler und Super!
Dann fing er mit den 10 Durchlauf an und bei Kern 6 FEHLER. Na toll! Jetzt sind wir bei 11Druchlauf.



Werde ich im Bios den Kern 6 bissel runter nehmen. Den PC mal eine Pause gönnen. Dann später nach mal laufen lassen, bis Abend.
So liegen wir erst mal jetzt und ist noch nicht fertig!

Kern​

0​

1​

2​

3​

4​

5​

6​

7​

8​

9​

10​

11​

12​

13​

14​

15​

SP​

117​

118​

119​

121​

120​

121​

121​

121​

113​

112​

113​

113​

114​

113​

114​

113​

OC​

- 5​

- 10​

- 12​

- 7​

- 7​

- 7​

- 12​

- 8​

- 25​

- 18​

- 15​

- 18​

- 25​

- 22​

- 32​

- 22​

Kann man die Config nicht so einstellen, das nur die Programme laufen. Die den CPU am meisten belasten und so 6 min lang.



Gruß Enrico

 

[sp00n]

Kann man die Config nicht so einstellen, das nur die Programme laufen. Die den CPU am meisten belasten und so 6 min lang.

Du kannst in der Config recht viel einstellen. Die ist (denke ich) recht gut kommentiert, man muss sich halt entsprechend damit beschäftigen.

 

[LuxSkywalker]

Hallo,

ich dachte jetzt habe ich es geschafft. Ist das fall!
Es läuft die Feintuning Config durch. Nachmittag so 3 bis 4 durch Läufe und ohne Fehler. Jetzt am Wochenende Samstag früh gestartet und bis heute Sonntag. 9 Durchläufe und kein Fehler und Super!
Dann fing er mit den 10 Durchlauf an und bei Kern 6 FEHLER. Na toll! Jetzt sind wir bei 11Druchlauf.

das ist leider so, hatte ich selber auch schon das ein Kern welcher eigtl. seit 6 Durchläufen stabil war dann doch noch etwas rumgezickt hat ^^

da kannst du nur Schritt für Schritt weiter reduzieren und testen

@LuxSkywalker

Aber BBP ärgert die Kerne am meisten (zumindest bei mir)

Was bringen die 3 Tests für grobe wenn bei BBP die Kiste abschmiert, dann würde ich das auch mit in die Config reinnehmen für ein Schnelltest

ich habe das gestern nochmal nachgestellt, m.e. ist das so wie es jetzt ist eigtl optimal.

Mit der Schnellconfig rantasten - diese ermöglicht die CO Werte etwas härter/höher einzustellen - um dann mit dem feintuning die CO Werte der Kerne entsprechend zu entspannen.

Wenn ich jetzt BBP mit in die Schnellkonfig reinnehme dann weiß ich beim feintunen nicht ob ich beim CO Wert weiter hoch oder runter muss ^^

Die Schnellconfig und das spätere feintunen gehört für mich "zusammen" - nur die Schnellconfig auszuloten macht so keinen Sinn.

Wem das zu Aufwendig ist kann auch gleich direkt mit dem Feintunen anfangen

 

[LehmannE]

Hallo,

ich habe mal deine Feintunig Config ein bissel verändert! Weiß nicht ob das so gut ist?

@sp00n Du kannst in der Config recht viel einstellen. Die ist (denke ich) recht gut kommentiert, man muss sich halt entsprechend damit beschäftigen.

#
# Use a comma separated list
# Default: BKT, BBP, SFT, FFT, N32, N64, HNT, VST
tests = BKT, BBP, SFT

Wenn man das CoreCycler startet, wird in ein Fester angezeigt. Das BKT, BBP, SFT mehr für den CPU ist, mit den Streichlinien.

 Debug setting to control the amount of milliseconds the stress test program would be suspended
#
# Default: 1000
suspensionTime = 200

Dann dachte ich, mit der Pausezeit zwischen den Test! Habe ich von den 1000 ms auf 200 ms gestellt.
Da sind bei mir 11 Kerne von 16 ausgefallen, bei 1 Druchlauf.
Dann war Kern 14 dran mit - 32 und System hat Neustart gemacht.

Jetzt weiß ich nicht, ob das gut ist?
Habe mal die Config mit angehangen.


Gruß Enrico

 

[Wolf87]

@LuxSkywalker wie versprochen mein VRM Setting. Hier konnte ich etwas mehr Stabilität rein bringen. Für ein CoreCycler Bild hat es leider nicht gereicht. Bitte den Load Line Wert vom Vsoc nicht 1:1 übernehmen.

sondern mit HW Info vergleichen ob es Overshooting gibt. Fahre aktuell 1,2 Volt auf den Vsoc sowie ich es verstanden habe ist bei HW Info dort der SVI3 Wert am genausten

 

[sp00n]

 Debug setting to control the amount of milliseconds the stress test program would be suspended
#
# Default: 1000
suspensionTime = 200

Dann dachte ich, mit der Pausezeit zwischen den Test! Habe ich von den 1000 ms auf 200 ms gestellt.
Da sind bei mir 11 Kerne von 16 ausgefallen, bei 1 Druchlauf.
Dann war Kern 14 dran mit - 32 und System hat Neustart gemacht.

Debug Settings bitte nur ändern, wenn man weiß, was man tut. Die suspensionTime regelt, wie lange das Stresstestprogramm regelmäßig pausiert wird (um Lastwechsel zu simulieren). Mit "Zeit zwischen den Tests" hat das nichts zu tun.
Dem am nächsten käme delayBetweenCores, was die Wartezeit zwischen zwei Kernen fest setzt (damit sich die CPU abkühlen kann, etc). Das bedingt dann natürlich restartTestProgramForEachCore = 1, also dass das Stresstestprogramm für jeden Kern neu gestartet wird.


BTW, ich werkel gerade an einer Testversion herum, die die Ausgabe von y-Cruncher lesen und so dort auftretende Fehler erkennen kann, anstatt bei y-Cruncher nur auf die CPU-Auslastung angewiesen zu sein.
Dazu muss ich natürlich wissen, welche Fehlermeldungen ausgegeben werden. Bisher weiß ich von "Error(s) on logical core X", hat da noch jemand was anderes gesehen?

 

[LuxSkywalker]

Hallo,

ich habe mal deine Feintunig Config ein bissel verändert! Weiß nicht ob das so gut ist?

#
# Use a comma separated list
# Default: BKT, BBP, SFT, FFT, N32, N64, HNT, VST
tests = BKT, BBP, SFT

Wenn man das CoreCycler startet, wird in ein Fester angezeigt. Das BKT, BBP, SFT mehr für den CPU ist, mit den Streichlinien.

 Debug setting to control the amount of milliseconds the stress test program would be suspended
#
# Default: 1000
suspensionTime = 200

Dann dachte ich, mit der Pausezeit zwischen den Test! Habe ich von den 1000 ms auf 200 ms gestellt.
Da sind bei mir 11 Kerne von 16 ausgefallen, bei 1 Druchlauf.
Dann war Kern 14 dran mit - 32 und System hat Neustart gemacht.

Jetzt weiß ich nicht, ob das gut ist?
Habe mal die Config mit angehangen.


Gruß Enrico

also die Feintuning wäre ja Teil 2 der ganzen Optimierung - ob da jetzt das Eingrenzen der einzelnen Tests sinnvoll ist möchte ich nicht beurteilen

Meiner Erfahrung nach machen die vorgegebenen Test dafür durchaus Sinn und ich würde die für das feintunen nicht weiter reduzieren - ich glaube das sich die yCruncher Entwickler schon was bei der Anzahl als auch der Reihenfolge etwas gedacht haben, kann ich doch nichtmal manuell die Reihenfolge ändern im CoreCycler. Die Reihenfolge lässt sich zwar in der CoreCycler Config anpassen allerdings wird die Reihenfolge dann unverändert im yCruncher stumpf wie vorgesehen abgearbeitet...

Ist aber nur meine Meinung 😇

Die Suspension Time würde ich - wie @sp00n schon schrieb - ebenfalls nicht ändern, wir wollen damit ja gerade unterschiedliche Belastungszustände (kurze Pausen) erreichen/simulieren 😉

btw. solange du bei einen Durchlauf vom CoreCycler (wie auch immer die Config eingestellt ist) Abbrüche oder auch BSoD oder harte Reboot's bekommst ist das System noch nicht stabil. Du musst also CO bei den entsprechenden Kernen noch weiter reduzieren!

BTW, ich werkel gerade an einer Testversion herum, die die Ausgabe von y-Cruncher lesen und so dort auftretende Fehler erkennen kann, anstatt bei y-Cruncher nur auf die CPU-Auslastung angewiesen zu sein.
Dazu muss ich natürlich wissen, welche Fehlermeldungen ausgegeben werden. Bisher weiß ich von "Error(s) on logical core X", hat da noch jemand was anderes gesehen?

ich bin dabei meine VRM Settings noch leicht anzupassen, wenn ich weitere Fehlermeldungen zu sehen bekomme melde ich mich

 

[sp00n]

@LuxSkywalker oder andere
Wer die Testversion haben möchte, der kann sich mal melden. Damit sollte es dann möglich sein, dass y-Cruncher nicht nach jedem Fehler neu gestartet werden muss, sondern einfach weiter läuft, d.h. dass die Ausgabe weiterhin sichtbar ist. Vielleicht. Wenn da eine entsprechende Meldung ausgegeben wird, die ich abfangen kann.

"Error(s) on logical core X" aus der Y-Cruncher Fehlermeldung wird dann allerdings nicht mit dem tatsächlich getestetem Kern übereinstimmen, da y-Cruncher anfangs immer mit Core 1 (bzw 1&2) initialisiert wird und es von den zwischenzeitlichen Kernwechseln nichts mitbekommt. Da muss man sich dann auf die Meldung aus dem CoreCycler-Fenster verlassen.

 

[LehmannE]

@LuxSkywalker , habe wieder dein Feintunig Config wieder drin. Werde damit weiter machen. Komme so am Tag, auf 3 bis 4 Durchgänge. Aber das Wochenende nährt sich ja wieder. Da kann man wieder länger laufen lassen.

@sp00n ,ich würde die gerne testen! Bin ja noch Mittendrin beim einstellen.

Gruß Enrico

 

[sp00n]

Hier ist die erste Alpha, die den Output von y-Cruncher auslesen kann:

Release 0.9.5.0alpha1 · sp00n/corecycler

Alpha version. Added a wrapper .exe and .dll that can grab the output from y-Cruncher. The y-Cruncher output is now saved as a log file and checked for errors.

github.com

 

[LehmannE]

Die Suspension Time würde ich - wie @sp00n schon schrieb - ebenfalls nicht ändern, wir wollen damit ja gerade unterschiedliche Belastungszustände (kurze Pausen) erreichen/simulieren 😉

Debug Settings bitte nur ändern, wenn man weiß, was man tut. Die suspensionTime regelt, wie lange das Stresstestprogramm regelmäßig pausiert wird (um Lastwechsel zu simulieren). Mit "Zeit zwischen den Tests" hat das nichts zu tun.

Der 1 Kern bekommt eine Rechnen Aufgabe, um auf 100% zubekommen. Dann wieder weg 50% und dann wieder da 100%, hoch und runter. Die Simulierte Pause ist 1000 ms! Wenn man die Pause runter nimmt. Bekommt er dann Dauerfeuer und wird mir Rechenaufgaben zugeschüttet? Kann man das so verstehen


Habe mir Alpha Version 0.9.5.0 alpha1 runter geladen und aus gepackt. Mein Norton Antivirus löscht gleich die Datei WriteConsoleToWriteFileWrapper.exe, 32.dll und 64.dll aus den Ordner.
Sind die Wichtig?


Gruß Enrico

 

[sp00n]

Der 1 Kern bekommt eine Rechnen Aufgabe, um auf 100% zubekommen. Dann wieder weg 50% und dann wieder da 100%, hoch und runter. Die Simulierte Pause ist 1000 ms! Wenn man die Pause runter nimmt. Bekommt er dann Dauerfeuer und wird mir Rechenaufgaben zugeschüttet? Kann man das so verstehen

Mmmmh. Ohne die Pause arbeitet der Kern komplett durch, so wie wenn man das Stresstestprogramm manuell ausführen würde.
Die Funktion sorgt dann dafür, dass der Kern alle x Sekunden für y Millisekunden pausiert wird (komplett, nicht 50%), d.h. gar keine Last mehr anliegt. Das kann für Spannungspitzen (und -täler) sorgen, die dann eine eventuell vorhandene Instabilität aufdecken können, die man ansonsten während des Tests nicht gefunden hätte.
Crashes im Idle waren ja bei CO-Overclocking/-Undervolting ja ein oft auftauchendes Thema, mit dieser Funktion wollte ich das so weit wie möglich abdecken.

Die Pause zu verringern kann funktionieren, ich habe dazu allerdings 0 Tests gemacht, und es bringt eigentlich auch keine Vorteile (außer einer marginal kürzeren Laufzeit des Stresstests). Deswegen ist es ja auch ein Debug-Setting, das nur verändert werden sollte, wenn man weiß man macht.

Habe mir Alpha Version 0.9.5.0 alpha1 runter geladen und aus gepackt. Mein Norton Antivirus löscht gleich die Datei WriteConsoleToWriteFileWrapper.exe, 32.dll und 64.dll aus den Ordner.
Sind die Wichtig?

Nein, ich hab die nur zum Spaß dazu gepackt. 🙃
Die sorgen dafür, dass die Ausgabe von y-Cruncher tatsächlich gelesen werden kann. Ohne die funktioniert das nicht.

Norton Antivirus beste!
Hier sind die Virustotal-Scans der entsprechenden Dateien:
Virustotal.com - WriteConsoleToWriteFileWrapper.exe
Virustotal.com - WriteConsoleToWriteFileWrapper32.dll
Virustotal.com - WriteConsoleToWriteFileWrapper64.dll

Nur Norton macht da anscheinend wieder Extrawürste.

// Edit
Hier wäre noch der Quellcode dafür (meine ersten Versuche in C++ ):

GitHub - sp00n/WriteConsoleToWriteFileWrapperExe: .exe file to wrap WriteConsoleW calls to WriteFile, using Detours

.exe file to wrap WriteConsoleW calls to WriteFile, using Detours - sp00n/WriteConsoleToWriteFileWrapperExe

github.com

GitHub - sp00n/WriteConsoleToWriteFileWrapperDll: DLL files to wrap WriteConsoleW calls to WriteFile. Uses Detours

DLL files to wrap WriteConsoleW calls to WriteFile. Uses Detours - sp00n/WriteConsoleToWriteFileWrapperDll

github.com

 

[LehmannE]

Mit den Norton habe ich hin bekommen und er löscht die jetzt nicht mehr.



Die Alpha Version läuft erstmal! Habe die Config angepasst nach @LuxSkywalker seine feintuning Config.

Gruß Enrico

 

[LuxSkywalker]

...
Die Funktion sorgt dann dafür, dass der Kern alle x Sekunden für y Millisekunden pausiert wird (komplett, nicht 50%), d.h. gar keine Last mehr anliegt. Das kann für Spannungspitzen (und -täler) sorgen, die dann eine eventuell vorhandene Instabilität aufdecken können, die man ansonsten während des Tests nicht gefunden hätte.
Crashes im Idle waren ja bei CO-Overclocking/-Undervolting ja ein oft auftauchendes Thema, mit dieser Funktion wollte ich das so weit wie möglich abdecken.

Die Pause zu verringern kann funktionieren, ich habe dazu allerdings 0 Tests gemacht, und es bringt eigentlich auch keine Vorteile (außer einer marginal kürzeren Laufzeit des Stresstests). Deswegen ist es ja auch ein Debug-Setting, das nur verändert werden sollte, wenn man weiß man macht.
...

gerade die Funktion mit den kurzen Pausen lastet die Systeme auch dementsprechend gut aus

 

[LehmannE]

Guten Morgen,

wie viele Durchgänge zählt man! Wenn der CPU stabil läuft?
Habe die Alpha Version 1 mit feintuning config und ist 35 Stunden gelaufen ohne Fehler.




Habe mal in die Config was geändert, die beiden Sachen.

runtimePerCore = 13m
restartTestProgramForEachCore = 1
delayBetweenCores = 12

Jetzt läuft yCruncher die 8 Test für ein Kern durch, plus die 3 Zusatz in 13 min. ( BKT, BBP, SFT, FFT, N32, N64, HNT, VST - plus - BKT, BBP, SFT )
Dann der nächste Kern, auch die 8 Test plus die 3.
Die CoreCycle log Datei wird weiter geschrieben.
Die yCruncher log Datei wir bei jeden neue Kern über schrieben. Weil er immer ein neues Fester auf macht. Kann man das machen, das er denkt es ist ein Fehler? Und läßt das Fester auf und fängt wieder bei Iteration 0 an.
Ich sehe gerade, das er die yCruncher log Datei werter schreibt. Schreibt doch alles da rein. Habe nach mal die yCrunder log und die CoreCycle log Angehängt.


CPU - AMD 7950X
Board - Asus STRIX X670E-E
BIOS - 1416

Kern​

0​

1​

2​

3​

4​

5​

6​

7​

8​

9​

10​

11​

12​

13​

14​

15​

SP​

117​

118​

119​

121​

120​

121​

121​

121​

113​

112​

113​

113​

114​

113​

114​

113​

OC​

- 2​

- 10​

- 10​

- 5​

- 7​

- 7​

- 12​

- 5​

- 25​

- 18​

- 15​

- 18​

- 20​

- 22​

- 28​

- 22​

Gruß Enrico

 

[LuxSkywalker]

Guten Morgen,

wie viele Durchgänge zählt man! Wenn der CPU stabil läuft?
Habe die Alpha Version 1 mit feintuning config und ist 35 Stunden gelaufen ohne Fehler.
...

35 Stunden sind definitiv mehr als ausreichend!

ich lasse nur 24h feintuning laufen - das reicht für mich aus

 

[sp00n]

35 Stunden insgesamt fände ich nicht ausreichend, das sind bei 16 Kernen nur etwas über 2 Stunden pro Kern.
Ich strebe 12-24 Stunden pro Kern an, eben so wie beim Allcore-Overclock mit 12-24h Prime-stable. Jetzt mit der Übertaktung/Undervolting pro Kern dauert das halt entsprechend länger, weil jeder Kern entsprechend einzeln auf Stabilität getestet werden möchte.
Also quasi die Zeit, mit der man bei einem Allcore-Overclock zufrieden gewesen wäre hinsichtlich der Stabilität, jetzt mit der Anzahl der Kerne multipliziert. Ja, das dauert. 😌
Aber nicht jeder stellt die gleichen Ansprüche an die Stabiltität, man kann sich auch mit weniger zufrieden geben.

 

[LehmannE]

Wenn man 12 - 24 Stunden pro Kern! Wer das ja bei 12 Stunden bei 16 Kerne 192 Stunden ( 8 Tage durch laufen ).
Kann man das Programm CoreCycler so einstellen. Das er nur ein Kern testet nach einer Zeit, dann es beendet oder ich beende.
Das dann wieder ändert und er testet den nächsten Kern, den ich aussuche?
Wenn man CoreCycler wieder neu startet, fängt er ja mit den Kern 0 wieder an.

Jetzt habe ich das so, das runtimePerCore 13 min ein Kern testet und dann zum nächsten geht.
Aber mit restartTestProgramForEachCore = 1 das yCruncher alle seine Test an ein kern macht und dann zum nächsten geht.

Habe noch mal die suspensionTime = 500 gestellt. Von 1000 auf 500!
Jetzt kommt bei einigen Kerne, Fehler ausgelöst durch Test BBP. Das hatte ich vorher nicht gehabt. Wo es noch bei 1000 ms stand.

Könnt ihr das auch mal testen? Wo ihr sagt, euer System ist Stabil! Das es was aus macht von 1000 ms auf 500 ms zu gehen.

Gruß Enrico

 

[sp00n]

Du könntest entweder coreTestOrderoder coresToIgnore in der Config entsprechend setzen.
Wenn du bei coreTestOrder nur einen Kern einträgst, dann wird auch nur der in Dauerschleife getestet. Das ist allerdings nur so semi-sinnvoll, wenn da z.B. über Nacht ein Fehler auftritt, dann hat man Zeit verschwendet, weil sich das Programm beendet hat. Als Alternative könnte man stattdessen die runtimePerCore hochsetzen. Oder man lässt das einfach so und kumuliert die Zeit hoch, so hatte ich das damals gemacht. Es muss ja nicht unbedingt am Stück getestet werden.

Bei Prime95 sorgt die "auto" Einstellung bei der runtime dafür, dass er alle FFT-Werte für einen Kern durchtestet. Jetzt wo das Abgreifen des Outputs bei y-Cruncher anscheinend funktioniert, hatte ich so eine Funktionalität auch für y-Cruncher geplant. Da war die "auto" Einstellung bisher einfach nur 10 Minuten.

 

[LuxSkywalker]

35 Stunden insgesamt fände ich nicht ausreichend, das sind bei 16 Kernen nur etwas über 2 Stunden pro Kern.
Ich strebe 12-24 Stunden pro Kern an, eben so wie beim Allcore-Overclock mit 12-24h Prime-stable. Jetzt mit der Übertaktung/Undervolting pro Kern dauert das halt entsprechend länger, weil jeder Kern entsprechend einzeln auf Stabilität getestet werden möchte.
Also quasi die Zeit, mit der man bei einem Allcore-Overclock zufrieden gewesen wäre hinsichtlich der Stabilität, jetzt mit der Anzahl der Kerne multipliziert. Ja, das dauert. 😌
Aber nicht jeder stellt die gleichen Ansprüche an die Stabiltität, man kann sich auch mit weniger zufrieden geben.

Boa, das würde bei meinem 12-Kerner mit meiner feintuning Config 12 Tage Dauerlauf bedeuten DAS ist mir dann doch etwas zuviel des guten

Bei einem 24h Dauerlauf sind es zwar netto nur 2h pro Kern - das reicht für meine Bedürfnisse aber locker aus 😇

 

[sp00n]

Die Alpha2 ist draußen, jetzt funktioniert auch bei y-Cruncher die auto Einstellung für runtimePerCore. Dabei wird dann jeder der gewählten Tests einmal durchlaufen und danach automatisch der Kern gewechselt.
Ebenso kann man jetzt mit testDuration bei y-Cruncher die Länge der einzelnen Tests festlegen. Die war bisher fest bei 60 Sekunden, jetzt kann man sie selbst bestimmen.

Release v0.9.5.0alpha2 · sp00n/corecycler

Second alpha: y-Cruncher now also supports the "auto" runtimePerCore setting, where the core is automatically switched after all selected tests have been run for a core Added a testDuration settin...

github.com

 

[LehmannE]

Hallo,

die Alpha2 ist ja super!
Die runtimePerCore = auto ist nicht schlecht. Fährt den ganzen Test durch für ein Kern. Das Festen für y-Cruncher bleibt auf.
Braucht man nicht mehr restartTestProgramForEachCore auf 1 setzen. Da ging das Fenster von y-Cruncher immer zu bei neuen durch lauf.
testDuration auch super! Voher war ja 60 s pro Test. Wenn man da auf 120 s macht. Läuft bei runtimePerCore = auto dann der ganze Test 20 min für ein Kern.


Große Fehler habe ich noch nicht gefunden. Was bei mir nur war! Wenn man die Zip Datei aus packt und die config auf y-Cruncher umstellt.
Dann Run CoreCycler.bat startet, hängt manchmal y-Cruncher Fenster und bei CoreCycler kommt Fehler und dann geht y-Cruncher Fenster auf.
Wenn man dann Run CoreCycler.bat 2 mal auf macht, dann läuft es super.


Was ist eigentlich der C17 - Code 17 Experiment für ein Test? Weil er immer deaktiviert ist?

Gruß Enrico


Update!
Wenn dann ein Fehler kommt, bei einen Kern! Geht y-Cruncher weiter mit seine Test zum nächsten Kern. Er fängt nicht bei Test BKT, wieder von vorne an!

 

[sp00n]

Wenn man die Zip Datei aus packt und die config auf y-Cruncher umstellt.
Dann Run CoreCycler.bat startet, hängt manchmal y-Cruncher Fenster und bei CoreCycler kommt Fehler und dann geht y-Cruncher Fenster auf

Das hatte ich bisher nicht, wie genau war denn da deine Vorgehensweise?

Was ist eigentlich der C17 - Code 17 Experiment für ein Test? Weil er immer deaktiviert ist?

Ich glaube ich hatte den standardmäßig deaktiviert, weil in der Readme von y-Cruncher steht, dass der Test nicht für alle Prozessoren verfügbar sei ( »The "C17" algorithm is not available on all processors«).

Wenn dann ein Fehler kommt, bei einen Kern! Geht y-Cruncher weiter mit seine Test zum nächsten Kern. Er fängt nicht bei Test BKT, wieder von vorne an!

Ja, das lässt sich leider nicht verhindern, y-Cruncher macht immer beim nächsten Test weiter und fängt nicht eine neue Iteration an. Aber so schlimm ist das nicht, der CoreCycler wechselt erst den Kern, wenn alle gewählten Tests abgearbeitet wurden, das ist beim nächsten Kern dann halt mitten während der y-Cruncher Iteration der Fall. Die beiden Durchläufe von CoreCycler und y-Cruncher sind dann also nicht mehr synchron.
Wenn man immer unbedingt die gleiche Reihenfolge haben will, dann muss man wieder restartTestProgramForEachCore auf 1 setzen.

 

[LuxSkywalker]

35 Stunden insgesamt fände ich nicht ausreichend, das sind bei 16 Kernen nur etwas über 2 Stunden pro Kern.
Ich strebe 12-24 Stunden pro Kern an, eben so wie beim Allcore-Overclock mit 12-24h Prime-stable. Jetzt mit der Übertaktung/Undervolting pro Kern dauert das halt entsprechend länger, weil jeder Kern entsprechend einzeln auf Stabilität getestet werden möchte.
Also quasi die Zeit, mit der man bei einem Allcore-Overclock zufrieden gewesen wäre hinsichtlich der Stabilität, jetzt mit der Anzahl der Kerne multipliziert. Ja, das dauert. 😌
Aber nicht jeder stellt die gleichen Ansprüche an die Stabiltität, man kann sich auch mit weniger zufrieden geben.

nachdem ich mir doch eigtl. ziemlich sicher war das 24h Laufzeit ~2h pro Kern doch völlig ausreichend ist, habe ich mal - mehr aus Interesse - den CoreCycler länger laufen lassen

Ergebnis: nach 36h also ~3h pro Kern bricht mir doch noch Kern 2 weg

ich werde jetzt doch solange weiter testen bis ich mindestens 24h pro Kern stabil habe

muss ehrlich zugeben das ich das so nicht erwartet hätte

 

[sp00n]

Ja, das sind dann die Fehler, die man entweder akzeptiert ("Ich zock eh nur!") oder eben nicht. 🙃

 

[LuxSkywalker]

@LuxSkywalker wie versprochen mein VRM Setting. Hier konnte ich etwas mehr Stabilität rein bringen. Für ein CoreCycler Bild hat es leider nicht gereicht. Bitte den Load Line Wert vom Vsoc nicht 1:1 übernehmen.

sondern mit HW Info vergleichen ob es Overshooting gibt. Fahre aktuell 1,2 Volt auf den Vsoc sowie ich es verstanden habe ist bei HW Info dort der SVI3 Wert am genausten

ich hatte wohl doch schon gleich zu Anfang entsprechende Einstellungen vorgenommen:

• CPU Load-line Calibration [Level 5:Recommended for OC]
• CPU VRM Switching Frequency [Manual]
• Fixed CPU VRM Switching Frequency(KHz) [800]
• CPU Power Duty Control [Extreme]
• CPU Power Phase Control [Extreme]
• VDDSOC Load-line Calibration [Level 1]
• VDDSOC Switching Frequency [Manual]
• Fixed VDDSOC Switching Frequency(KHz) [800]
• VDDSOC Power Duty Control [T.Probe]
• VDDSOC Power Phase Control [Extreme]

daher konnte ich dort leider doch nichts mehr optimieren ^^

sobald ich die CPU LLC nur etwas absenke taktet meine CPU AllCore nicht mehr so hoch wie Sie es mit LLC5 tut/kann - von daher lasse ich das erstmal so obwohl es mir mit LLC3 oder auch LLC1 wesentlich besser "gefallen" würde...

Ja, das sind dann die Fehler, die man entweder akzeptiert ("Ich zock eh nur!") oder eben nicht. 🙃

ja da hast du definitiv recht - wenn ich schon 24h AllCore auf Stabilität teste kann ich dann nicht hergehen und per Core das ganze auf nur 2h reduzieren ^^ der längere Test hat dies ja auch bestätigt

Mittlerweile sind mir nach weiteren 36h auch noch andere Kerne ausgestiegen welche innerhalb meines 24h Laufs stable waren

wenn das so weitergeht bin ich Weihnachten durch mit dem testen

 

[LehmannE]

Hallo,
wenn man den von 16 Uhr bis früh um 5 laufen lässt ( 7 Stunden ) und das fast jeden Tag! Zählt das auch, das man auf 24 Stunden pro Kern kommt? Oder muss der an sein, 8 Tage durch laufen und dann zählt das pro Kern 24 Stunden.
Habe mal testDuration = 90 gestellt, macht er pro Kern 15 min.
suspensionTime = 500 finde ich ein bissel Straffer den Test.
Liege jetzt mit den 500 ms noch mal ganz schön weit weg.

​

Kern​

0​

1​

2​

3​

4​

5​

6​

7​

8​

9​

10​

11​

12​

13​

14​

15​

SP​

117​

118​

119​

121​

120​

121​

121​

121​

113​

112​

113​

113​

114​

113​

114​

113​

OC 1000 ms​

- 2​

- 10​

- 10​

- 5​

- 7​

- 7​

- 12​

- 5​

- 25​

- 18​

- 15​

- 18​

- 20​

- 22​

- 28​

- 22​

OC 500 ms​

+ 0​

- 4​

- 2​

- 1​

- 3​

- 3​

- 2​

+ 2​

- 23​

- 15​

- 11​

- 14​

- 14​

- 16​

- 20​

- 16​

Gruß Enrico

 

[LuxSkywalker]

ich denke jeden Tag neu starten kannst du nicht als Dauerlauf hernehmen - würde ich zumindest so sehen

das mit der suspensionTime ist allerdings sehr interessant, das werde ich auch gleich mal umstellen und testen - lt. deiner Tabelle sind da ja pro Kern schon eklatante Unterschiede

was mir jetzt nochmal aufgefallen ist: nach Kaltstart, also System über Nacht mal aus und dann nach Windows Boot unmittelbarer Start CoreCycler ist mir jetzt schon mindestens 2x der Core 0 weggebrochen (obwohl vorher mind. 36h Dauerlauf stable) - ich glaube der boostet bei kaltem System einfach kurzfristig höher und damit wird der eigtl. stabile Core 0 dann wohl doch überlastet ^^

coreTestOrder = Alternate - werde ich dann wohl mal manuell umstellen, so das jeder Kern mal bei Kaltstart als erstes dran ist