CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

@LuxSkywalker bin mal gespannt auf dein Ergebnis! Wenn du die suspensionTime runter nimmst und welche ms du ein gestellt hast.

Am Wochenende läuft er auch mal länger, als 14 Stunden in der Woche. :-)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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.
Für mich zählt schon die kumulierte Zeit.
Wichtig ist halt, dass der Ablauf nicht dafür sorgt, dass irgendwelche Tests bei einigen Kernen gar nicht drankommen. Deswegen ist die auto Einstellung für runtimePerCore bei den längeren Tests so hilfreich, weil damit dann garantiert ist, dass jeder Test bei jedem Kern zumindest ein Mal durchgelaufen ist.

Seid bei der suspensionTime etwas vorsichtig, ich hab das nicht getestet, wie sich kürzere Werte auswirken. Wenn das Fehler sind, die tatsächlich direkt von Prime95 oder y-Cruncher stammen, dann wird wohl alles so funktionieren wie vorgesehen, aber wenn das "nur" Fehler bei der CPU-Auslastung sind, dann könnte da etwas schief gelaufen sein.
Es ist und bleibt weiterhin erstmal eine Debug-Einstellung.
 
Die neue Funktion runtimePerCore - auto, wo er den ganzen Test macht und dann zu nächste geht. Super

Bei suspensionTime - 500 kam immer Fehler ausgelöst durch BBP Test beim y-Cruncher.
Bei Beitrag #144 ist ein Bind von den Fehler. Der bis jetzt immer gekommen ist. Andere Fehler hatte ich bis jetzt noch nicht.

Seit gestern 14: 15 Uhr ( 25.491 Stunden) ist mein PC wieder unter Wegs. :-)
 
Zuletzt bearbeitet:
...
Seid bei der suspensionTime etwas vorsichtig, ich hab das nicht getestet, wie sich kürzere Werte auswirken. Wenn das Fehler sind, die tatsächlich direkt von Prime95 oder y-Cruncher stammen, dann wird wohl alles so funktionieren wie vorgesehen, aber wenn das "nur" Fehler bei der CPU-Auslastung sind, dann könnte da etwas schief gelaufen sein.
Es ist und bleibt weiterhin erstmal eine Debug-Einstellung.
...
Bei suspensionTime - 500 kam immer Fehler ausgelöst durch BBP Test beim y-Cruncher.
...
also bei mir ändert sich mit Reduzierung der suspensionTime von (default) 1000 runter auf 500 mal so gar nix...

Hab jetzt zwei (2) Durchläufe damit gemacht und kein Kern wird augenscheinlich mehr belastet ^^

kein Plan ob das mit meinen unterschiedlichen Einstellungen unter AiTweaker VRM zu tun hat?!? Oder mit der Spannungsversorgung meines Boards allgemein oder meine PBO CO Einstellungen schon zuweit optimiert sind... :confused:
 
@LuxSkywalker wie hast du die Einstellung ermittelt?
AiTweaker VRM mit Prime95 und eingestellt Small FFT und Haken bei Disable AVX-512 rein.
 
naja ermittelt... einfach mal alles soweit mir logisch erschien hochgeschraubt ^^

die Einstellungen waren/sind ja zu meinem gut 10 Jahren alten Z97-Pro fasst identisch und da habe ich ähnliche Einstellungen gefahren
 
Da kann ich sie mir ja mal abschreiben! :-)
Der Wolf87 hat ja auch seine Infos gegeben dazu.
Und mal google ob man noch was zu mein 7950X findet.
Oder ob die auch gut passen dazu.
 
Zuletzt bearbeitet:
Da ich meine config.ini sowieso neu machen wollte und meine Corecycler Version noch alt war, bin ich hergegangen und habe die neueste Alpha 2 installiert und den alten Ordner komplett gelöscht.

Mir ist da eine Sache aufgefallen, undzwar ist die config..ini mit einem Punkt zuviel falsch benannt.
Kein Problem, denn beim ersten Aufruf leitet die Batchfile sowieso die Einstellungen von config.default.ini ab und erstellt eine neue config.ini.
Aber eventuell ist es ja von Interesse @sp00n :)

1688631300904.png
 
Derp.
Ich schiebs auf die Alpha! 😜
 
Interesting, thank you!

Habs just thrown on, while the PC crashed immediately.

The idea is good, but it doesn't seem to be fully developed yet, does it?
cps test camzap
edit:

Can the tool also show what the current Curve Optimizer setting is?
This is just the usual behavior of the Prime95 test with disabled AVX/AVX2. The actual content has nothing to do with the computer chip, it just maps everything to Prime95.
 
Hallo,

ich habe mal den Fehler ihr!

Fehler-Y.jpg

Ich glaube das kommt nur, wenn yCruncher ein kleines bissel zu langsam ist. Bei Starten
Kann man bei Run CoreCycler ein Timer rein machen. Was runter läuft, dann sein Test Startet?
Und da durch yCruncher geöffnet wird.

Kann dir das weiter helfen?


Gruß Enrico
 
Da ist @sp00n gefragt

ich hatte diesen Fehler noch nicht 🧐
 
Hallo,

ich habe mal den Fehler ihr!

Anhang anzeigen 904206

Ich glaube das kommt nur, wenn yCruncher ein kleines bissel zu langsam ist. Bei Starten
Kann man bei Run CoreCycler ein Timer rein machen. Was runter läuft, dann sein Test Startet?
Und da durch yCruncher geöffnet wird.

Kann dir das weiter helfen?
Gut möglich, allerdings braucht y-Cruncher dann ziemlich lange, um zu starten. Bzw. Windows, um den Prozess aufzurufen.
Bisher hat auch noch niemand diesen Fehler gemeldet.

Was sagt denn die Logdatei dazu?

In Zeile 3382 in der script-corecycler.ps1 könntest du die Wartezeit bis zum Abfragen des Fensters von y-Cruncher verändern, momentan steht das auf 500ms:
Code:
# This might be necessary to correctly read the process. Or not
Start-Sleep -Milliseconds 500
 
Den Fehler habe ich glaube 3 oder 4 mal erst gehabt. Seit ich damit teste und das sind schon ein paar Stunden. :-)

Welche Logdatei meinst du?
Diese ihr!
 

Anhänge

  • yCruncher_2023-07-19_10-11-53_mode_19-ZN2 ~ KAGARI.txt
    1,7 KB · Aufrufe: 51
  • CoreCycler_2023-07-19_10-11-53_YCRUNCHER_19-ZN2 ~ KAGARI.txt
    6,1 KB · Aufrufe: 58
Zuletzt bearbeitet:
@sp00n der Parameter
Code:
delayFirstErrorCheck = 0
funktioniert nicht. Ich stelle 0, ein, 5 ein - immer schreibt CoreCycler 30 hin, und 30 Sekunden Tests werden sofort beendet.
Verwende die aktuellste Version, ein Fix wäre toll :)
 
@sp00n der Parameter
Code:
delayFirstErrorCheck = 0
funktioniert nicht. Ich stelle 0, ein, 5 ein - immer schreibt CoreCycler 30 hin, und 30 Sekunden Tests werden sofort beendet.
Verwende die aktuellste Version, ein Fix wäre toll :)
Stell den Wert in der config.default.ini mal auf 0. Das hab ich da leider mit 30 falsch eingetragen.
In der nächsten Version sollte es auch mit kurzen Testzeiträumen + delayFirstErrorCheck klappen, bislang kommen sich die beiden Werte in die Quere, wenn die Zeit pro Kern gleich oder kürzer als das Delay ist.
 
Config.default.ini sollte ja wurscht sein wenn der Wert in der Config.ini gesetzt ist, oder nicht?
 
Hallo,
ich glaube jetzt sind der Wehrte gut! Kam nach langen Testen, kein Fehler mehr. :-)

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

Kern0123456789101112131415
SP117118119121120121121121113112113113114113114113
OC+ 0- 4- 2+ 1- 2- 4- 3+ 2- 23- 15- 11- 15- 14- 16- 19- 15

Gruß Enrico
 
Config.default.ini sollte ja wurscht sein wenn der Wert in der Config.ini gesetzt ist, oder nicht?
Für bestimmte Sachen (eben Default-Werte, Vergleiche, etc) wird die config.default.ini herangezogen. Wenn da ein Wert falsch gesetzt ist, dann kann das durchaus Auswirkungen haben.
 
Verstehe ich - aber der Wert in der config.ini muss den doch immer überschreiben, wenn er gesetzt wird?
 
Häng mal deine Config und ein zugehöriges Logfile an
 
Anbei!
 

Anhänge

  • ConfigLogs.zip
    9,6 KB · Aufrufe: 62
Ah, Top - danke!
 
Meine CPU hat nun wirklich etliche Stunden Corecycler auf dem Buckel, ich ging davon aus das die Settings bis zum erbrechen stabil wären.
Gestern Abend dann im Menü von World of Tanks nach knapp 3 Stunden zocken:

Blackscreen, Soundloop, Reboot

*seufz* es war nicht warm in der Wohnung, es war ganz angenehm, die GPU langweilte sich, die Temperaturen waren weit von denen unter Vollast entfernt.
Nach einem Reboot zwei WHEA Einträge, die ich so noch nicht hatte im Windowslog:

Code:
Schwerwiegender Hardwarefehler.

Gemeldet von Komponente: Prozessorkern
Fehlerquelle: Machine Check Exception
Fehlertyp: Cache Hierarchy Error
Prozessor-APIC-ID: 2

Analog dazu nochmal APIC-ID 24

Da musste ich erstmal googlen wie man die APIC-IDs ausseinander dröselt, bin dann über CPU-Z und den dort generierbaren .txt Report gegangen.
Parallel dazu habe ich mich hieran gehalten:


Also Core 1 und Core 10 angepasst, den Curve Offset für beide Kerne um 5 entschärft.

Schien zu laufen, PC ausgeschaltet.

Heute morgen eingeschaltet --> Drei lange Pieptöne / RAM Probleme, WTF?
PC ausgeschaltet, neu eingeschaltet, bootet als ob nichts gewesen wäre.
Ins BIOS, die EInstellungen kontrolliert, alles in Ordnung.
Drücke auf Speichern und beenden --> Drei lange Pieptöne.
Erneuter Neustart, alles in Ordnung, ins BIOS --> alle Settings passen, diesmal das BIOS über nicht speichern verlassen, bootet durch.
Aha, scheint wohl am "speichern und beenden" zu liegen, PC heruntergefahren, neu eingeschaltet ins BIOS, speichern und beenden, alles bootet durch, wie die letzten Monate.

Was hat sich da verschluckt gehabt?
Das hatte ich so noch nie.

Gibt es irgendwo eine offizielle Übersicht von AMD wie die APIC IDs den Cores zuzuordnen sind?
 
Im Taskmanager bei Details bei einem Programm Rechtsklick und Zugehörigkeit festlegen. CPU 0 und CPU 1 sind Kern 0, CPU 2 und CPU 3 sind Kern 1... usw.
 
@Zyxx Übersicht ist mir nicht bekannt, und die Formel ist eigentlich einfach:

Physical Core = Virtual Core (APIC) / 2 , abgerundet auf Ganzzahl.

Warum? Weil die virtuellen Cores einfach so raufgezählt werden:

1693295040280.png


Also bei Dir Core 1 (2 / 2 = 1), und Core 12 (24/2 = 12).

Ich hatte das nicht so extrem, aber mit AGESA 1.2.0.A hat bei mir dazu geführt, dass ich etliche Cores anpassen musste, tw um einige Schritte:
1693295367339.png


Ev liegt es auch an den gestiegenen Temperaturen, an "Silicon Degradation" möchte ich nicht glauben...
 
Zuletzt bearbeitet:
Ich muss da auf jeden Fall noch einmal suchen.
Nach dem BIOS Update vor einigen Wochen habe ich TAGE lang den Corecycler ohne Fehler laufen lassen.
Jetzt grade vor 5 Minuten den Corecycler angeworfen parallel zum Homeoffice.
Nach nichtmals 5 Minuten:

1693295941380.png


@Bread und @RotAs743
Die APIC IDs die Windows im Log angibt werden anders gezählt.
Augenscheinlich werden für die "kleinen" CCD, wie mein 5900x zwei hat, beim Übergang von CCD 0 auf 1 die APIC-IDs so behandelt als ob es ein "8er" CCD wäre und kein "6er".

Die Annahme APIC ID /2 gilt also nur für den ersten CCD.
Danach... half mir der CPU-Z Report den ich erstellt habe:

Code:
Socket 0 
    -- Node 0 
        -- CCD 0     
            -- CCX 0     
                -- Core 0 (ID 0) 
                    -- Thread 0    0
                    -- Thread 1    1
                -- Core 1 (ID 1) 
                    -- Thread 2    2
                    -- Thread 3    3
                -- Core 2 (ID 2) 
                    -- Thread 4    4
                    -- Thread 5    5
                -- Core 3 (ID 3) 
                    -- Thread 6    6
                    -- Thread 7    7
                -- Core 4 (ID 4) 
                    -- Thread 8    8
                    -- Thread 9    9
                -- Core 5 (ID 5) 
                    -- Thread 10    10
                    -- Thread 11    11
        -- CCD 1     
            -- CCX 0     
                -- Core 6 (ID 8) 
                    -- Thread 12    16
                    -- Thread 13    17
                -- Core 7 (ID 9) 
                    -- Thread 14    18
                    -- Thread 15    19
                -- Core 8 (ID 10) 
                    -- Thread 16    20
                    -- Thread 17    21
                -- Core 9 (ID 11) 
                    -- Thread 18    22
                    -- Thread 19    23
                -- Core 10 (ID 12) 
                    -- Thread 20    24
                    -- Thread 21    25
                -- Core 11 (ID 13) 
                    -- Thread 22    26
                    -- Thread 23    27

Die APIC-IDs von Core 5 auf dem ersten CCD mit Thread 10/11 und APIC 10/11 ändern sich beim Wechsel auf Core 6 im nächsten CCD mit Thread 12/13 zu APIC ID 16/17.
APIC-ID 24 war also Core 10 Thread 20.

Edit sagt, WAS ZUM HENKER NOCHMAL:
1693297235679.png


Frust -.-:

1693297529405.png
 
Zuletzt bearbeitet:
Machst Du RAM-OC? Schick mal zur Sicherheit ZenTimings Screenshot.
 
@Bread das ist der Stand wie ich ihn vor einigen Monaten im OC Zen Sammler hier mit den Kollegen rausgeknobelt und OK getestet hatte.
Auch nach dem BIOS Update beinahe 24h stable getestet ohne Fehler, Screenshot von vor wenigen Augenblicken:

1693297787257.png


und der nächste:
1693297810676.png


Was passiert hier? Schreiben wir doch einfach mal alle CO Werte kaputt in einem Run:
1693299083825.png


So ich höre mal mitm editieren auf nach dem hier:
1693299699352.png


*aufreg* Normal ist das nicht, zumal der Kasten die letzten drei Wochen (Urlaub) rund um die Uhr absolut stabil lief in jedem Game und mit meinen VMs, seit gestern Abend nicht mehr.
1693300142784.png


1693300512350.png


1693302425404.png

Ich geh dann mal im BIOS gegen die CO Werte treten.
 
Zuletzt bearbeitet:
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