CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[svigo]

mal ganz doof gefragt, hatte den jetzt 9 h laufen bei nem 5900x (Iteration 8)

der Test würde automatisch enden, aber dann 144h dauern oder verstehe ich was falsch

lese leider nicht so richtig wann bzw ob er automatisch endet

 

[Ragnador]

@vvoid
Bei +150 mhz sind leider nur geringere curve optimizer werte möglich, als bei 100 mhz.

Wenn einzelne kerne höher takten können wird mehr hitze produziert, dadurch können mehrere kerne nicht mehr so hoch takten.

Bei geringerer curve optimizer werten ist auch die wärme entwicklung höher = geringerer multicore takt durch hitze.

Wenn man jetzt z.b ein spiel hätte das alle kernd nutzt bekommt man mehr performance mit +0 mhz und hohen negativen curve optimizer Werten.
Bei anderen Spielen hat man mehr performance durch singlecore boost.

Du musst leider ausprobieren was für deine Hauptspiele am besten ist. Ob jetzt popelige 50, 100, 150 Mhz in neueren Spielen gravierende fps schübe bringt ist eher selten gegeben.

 

[sp00n.82]

mal ganz doof gefragt, hatte den jetzt 9 h laufen bei nem 5900x (Iteration 8)

der Test würde automatisch enden, aber dann 144h dauern oder verstehe ich was falsch

Wenn du die Standardeinstellung der config.ini verwendet hast, dann läuft er quasi unendlich lange (6 Minuten pro Kern * Anzahl der Kerne * 10000).

Die von dir erwähnten 144 Stunden wären praktisch die Entsprechung eines Stresstests mit Prime95, der auf einem 12-Kerner wie dem 5900x mit allen seinen Kernen gleichzeitig für 12 Stunden gelaufen ist. Also so ein Stresstest wie damals, als es noch keinen Single-Core-Boost gab. So ein 12 Stunden Stresstest waren da zumindest ein ganz guter Wert, um als einigermaßen stabil angesehen zu werden (wobei ich persönlich da eher 24h anstrebe).
Die jetzigen 9 Stunden entsprechen dagegen gerade mal 9/12 = 45 Minuten Stresstest (pro Kern). Ob man damit zufrieden ist, muss jeder für sich selber entscheiden.

Ja, Single-Core Overclocking/Stabilitätstests sind sehr zeitaufwändig. Je mehr Kerne, desto länger.

 

[5hred]

Kann jemand grob sagen, welche max. - also sicheren - Werte für meine 5600X mit Stock-AMD-Kühler wären (W, A, A)? Dazu noch die Werte, wenn ein deutlich besserer Thermalright-Kühler mit 2x140mm benutzt wird (auf Noctua D14-Niveau)? Aktuell fahre ich Standard-Werte für die 5600X, also 76W....etc.

 

[Low]

@sp00n.82

Funktioniert das Tool in Richtung Intel Alder Lake?

 

[sp00n.82]

Funktioniert das Tool in Richtung Intel Alder Lake?

Ich selbst kann das mangels Intel nicht testen, irgendjemand meinte aber, dass er dass bei seiner Intel-CPU verwendet hätte. Für was genau weiß ich aber auch nicht, mein letzter Chip von Intel war vor der ganzen Boost-Geschichte.

Prinzipiell sollte es eigentlich CPU-unabhängig sein, und in der Config könnte man auch die E-Cores vom Testen ausnehmen lassen, indem man sie entweder bei coresToIgnore einträgt oder andersherum man nur die P-Cores bei coreTestOrder angibt.

 

[Scindero]

Ich habe das Tool nun schon 2 Tage in Benutzung (Version 0.8.2.4) und finde es echt gut. Erleichtert einiges. Seit gestern bekomme ich auf einmal den folgenden Fehler:

Da es bis dahin ohne Probleme lief war ich doch etwas verwundert. Habe mich dann mal auf die Fehlersuche gemacht:

Soweit sollte das doch so ok sein?

Im Log ist folgendes ersichtlich:

Habe auch schon in der Registry geguckt, aber nichts gefunden. So gut kenne ich mich dort leider nicht aus. Kann auch nicht sagen warum es auf einmal so gar nicht mehr will.

Vielen Dank schon mal.

 

[Ragnador]

Kannst du einmal Windows "Neu starten" drücken? Also nicht Herunterfahren und dann wieder starten.
Und Testweise einmal den corecycler mit rechtsclick "Als Administrator ausführen" starten ?

 

[Scindero]

Habe ich gemacht, ändert leider gar nichts.

 

[sp00n.82]

Evtl. hat's die Performance Counter zerschossen, ich hab dafür in der Readme eine extra Sektion, weil das bei Windows anscheinend gerne mal vorkommt.

 

[Scindero]

Vielen Dank, das brachte die Lösung.

 

[MGFirewater]

Deskmodder bloggt über seine ersten Erfahrung mit agesa 1.2.0.6b. nachdem 1.2.0.5 so scharf kritisiert wurde. nachdem mein Systemmit der neusten agesa nicht stabil lief bin ich zurück auf 1.2.0.3c. nach einem Tipp bei den Kommentaren, konnte ich jetzt mein ram oc setting als Ursache definitiv ausschließen. Es liegt am pbo. Hatte bisher +75mhz und ein negativen Offset von 0 bis-14 auf einzelnen cores. Mit 1.2.0.3c lief das super. Aber für 6b ist es zu krass.

Hat jemand schon ermittelt, was bei 6b anders ist und wo die Limits im Vergleich zu vorher sind um ein stabiles 24/7 setting zu bekommen?

 

[Ragnador]

Das Limit kann mit jedem Agesa update wechseln, da sie A) die Kurve ändern können oder B) es durch "geringere Temperaturen" zu höheren (dadurch instabileren) boosts kommen kann., daher muss bei jedem Agesa update erneut getestet werden (vor allem, da Leute von Besseren benchmark ergebnissen mit 1.2.0.6b berichten). Das gleiche ist zu beobachten wenn du von normaler Wärmeleitpaste auf Flüssigmetall wechselst.

Auch Ram OC kann instabil werden wenn man viele "Auto" Werte verwendet, da die "Tabelle" sich bei jedem Bios Update ändern kann. Wenn man jeden Wert manuell einstellt, nach einem Bios update, kann man häufig Probleme umgehen vor allem wenn man höher als XMP unterwegs ist. Zur not mit Zentimings ein Foto machen vor einem Bios update und nach dem Bios Update vergleichen und "geänderte Werte" manuell zurücksetzen.

 

[sp00n.82]

Weil es öfter mal gewünscht wurde, in Version 0.9.0.0 unterstützt der CoreCycler jetzt auch die neueren Prime Versionen 30.7 und 30.8. Mitgeliefert wird jetzt auch gleich 30.8b15.

https://github.com/sp00n/corecycler/releases/tag/v0.9.0.0

 

[N4poleo]

Hatte jemand schonmal den Fall, dass der CoreCycler nicht zum nächsten Core gegangen ist, obwohl die definierte Testzeit abgelaufen war? Ist das als Instabilität der CPU einzuordnen oder einfach nur ein Bug?
Sobald ich dann CTRL+C drücke, läuft das Tool dann nämlich ohne Problem weiter.

 

[sp00n.82]

Wie lange war denn die eingestellte Testzeit?
Zu 100% trifft er die Zeit nie, weil die nur periodisch gecheckt wird. Und es hängt teilweise auch an der Ausgabe der Logdatei von Prime95, die wird auch nur periodisch von Prime geschrieben, und wenn es Zeit ist zu wechseln, dann wartet der CoreCycler erst auf einen neuen Eintrag dort, damit nicht versehentlich ein Fehler einem falschen Kern zugeordnet wird.

 

[foxio]

Ist mir auch schonmal aufgefallen. Dabei habe ich aber gesehen, dass Prime weiterläuft. Eine Vermutung: Hast du die Logdatei mit einem anderen Programm geöffnet? Evtl verhindert das, dass das Skript die Logdatei auswerten kann oder auch ein Schreiben von neuen Einträgen durch Prime.

 

[N4poleo]

Testzeit war 2 Stunden mit Heavy SSE auf der CoreCycler Version 0.8.2.4.. Ich habe es dann erstmal weiter laufen lassen (noch ca. eine Stunde) und dann habe ich manuell weiter gedrückt. Log Datei hatte ich parallel nicht geöffnet. Ich habe jetzt auf Version 0.9.0.0 geupdatet und nochmal laufen lassen. Bisher läuft es alles unauffällig durch.

 

[sp00n.82]

Wenn du die Logdateien von dem Run noch hast, kannst du sie hier mal anhängen (bitte nicht direkt posten, das wird zu lang 😬), vielleicht finde ich irgendwo einen Bug.

 

[N4poleo]

Ich hatte heute nochmal einen Run gestartet und das Problem ist wieder aufgetreten. Anbei die beiden Logs. Mir ist jetzt nichts Ungewöhnliches aufgefallen außer den Zeitsprung durchs manuelle Eingreifen.