CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

Gedacht ist die Einstellung in der Config, um Instabilitäten der anderen Kerne während des Testens auszuschließen, also eventuelle "falsche" Fehler, wie Abstürze, die z.B. durch Kern 0 verursacht werden, während gerade ein anderer Kern getestet wird.

Die Einstellung ist übrigens auch nur in der neuen Ryzen.AutomaticTestMode.Start.ini auf aktiv gesetzt, standardmäßig ist die nicht an, d.h. der Automatic Test Mode setzt weiterhin bei allen Kernen gleichzeitig die CO-Werte.

Wobei ich bei meinen kurzen Tests über Nacht erstmal keine Veränderung der CO-Werte mehr feststellen konnte, wenn ich von einer Nacht mit setVoltageOnlyForTestedCore = 1 auf eine Nacht mit = 0 gewechselt bin.
Allerdings waren die CO Werte bei einigen Kernen da auch noch teilweise weit von dem entfernt, was ich damals bei der Entwicklung von CoreCycler in vermutlich wochenlangen Tests herausgefunden hatte. Andere waren aber schon relativ nah dran.

Es ist halt wieder nur ein weiteres Tool im Werkzeugkasten und kein alleinheilbringendes Wundermittel.

// Edit
Dein Edit erst jetzt gesehen.
Der 9800X3D ist natürlich ein Sonderfall, da er die gleiche Frequenz bei AllCore wie bei Single Core erreichen kann, im Unterschied zu allen anderen Ryzen-Chips.
In dem Fall ist ein AllCore Testszenario tatsächlich viel nützlicher als bei den anderen Chips, da dort bei gleicher Frequenz durch den Vdroop eine niedrigere Spannung anliegt (sofern du die gleiche Frequenz erreichst natürlich).

Des Weiteren muss man allerdings beachten, dass bei einem AllCore-Test diejenige Spannung verwendet wird, die die höchste aller belasteten Kerne ist, d.h. die einzelnen CO-Werte haben dann nur bedingt Einfluss und werden gegebenenfalls "überschrieben". Also wenn z.B. ein Kern nach 1.175v verlangt, die anderen aber nur 1.15v, dann wird trotzdem für alle 1.175v angelegt.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Um schnellstens an CO Werte (allcore) zu kommen habe ich festgestellt, dass YC VT3 für den 9800X3D gut geeignet ist.
In welchem Last- (Watt) und Frequenzbereich befindest du dich da? Ich habe eine ältere Y-Cruncher Version zum testen von allen Kernen verwendet um auch wirklich alle Last- & Frequenzbereiche abzudecken.
Bereiche sind von 4,8GHz bis 5,65GHz & 150W- 310W im Allcore. Mit neueren Versionen war ich die ganze Zeit im Temperaturlimit (aktuell nur mit 360er Aio).

Frequnezlimit ist bei 5650 (CCD0) & 5825 (CCD1). CurveOpti nur genutzt um den Rest anzupassen.
1744729416572.png
 
Mit dem YC 8.5 und 8.6 bin ich bei ca 113-120 Watt und 5200 -5250 MHz. Temperatur mit Grizzly IHS und 280er AIO bei ca 65 Grad.
 
Mit dem YC 8.5 und 8.6 bin ich bei ca 113-120 Watt und 5200 -5250 MHz. Temperatur mit Grizzly IHS und 280er AIO bei ca 65 Grad.
In allen Tests? Würde schauen das auch zumindest einer der Tests bis ins Temperaturlimit geht. So hat es Skatterbencher auch in seinen OC-Strategien beschrieben, um wirklich alles abzudecken.
 
Gedacht ist die Einstellung in der Config, um Instabilitäten der anderen Kerne während des Testens auszuschließen, also eventuelle "falsche" Fehler, wie Abstürze, die z.B. durch Kern 0 verursacht werden, während gerade ein anderer Kern getestet wird.
@sp00n siehe mein letzter Post - die Spannungen der Core beeinflussen einander, es sollten immer alle Werte in Abhängigkeit voneinander getestet werden. Alle auf 0 setzten außer den getesteten verfälscht das Bild nach meiner Erfahrung, und der einiger anderer.
 
@sp00n siehe mein letzter Post - die Spannungen der Core beeinflussen einander, es sollten immer alle Werte in Abhängigkeit voneinander getestet werden. Alle auf 0 setzten außer den getesteten verfälscht das Bild nach meiner Erfahrung, und der einiger anderer.
zumindest die direkt nebeneinander liegenden Cores des gleichen CCD beeinflussen sich gegenseitig - das ist definitiv so (y)
 
In allen Tests? Würde schauen das auch zumindest einer der Tests bis ins Temperaturlimit geht. So hat es Skatterbencher auch in seinen OC-Strategien beschrieben, um wirklich alles abzudecken.
Nein, das bezog sich -wie beschrieben- nur auf auf VT3.

Wenn ich alle Tests laufen lasse komme ich auch -je nach Test- auch auf die "NennMHz", 155 Watt und 87° (manchmal auch etwas mehr bis 91°, kommt auf die Raumtemperatur an.). Wobei die anderen Test viel weniger anfällig für "mehr" negatives CO sind. Von daher war der Tipp mit dem CS sehr gut.
Beitrag automatisch zusammengeführt:

Bei aktueller CO/CS Einstellung ist mein "schlechtester bester" Core bei FFTv4 CO-17, bei N63 CO-15 und bei VT3 CO-3
 
Zuletzt bearbeitet:
@sp00n siehe mein letzter Post - die Spannungen der Core beeinflussen einander, es sollten immer alle Werte in Abhängigkeit voneinander getestet werden. Alle auf 0 setzten außer den getesteten verfälscht das Bild nach meiner Erfahrung, und der einiger anderer.
zumindest die direkt nebeneinander liegenden Cores des gleichen CCD beeinflussen sich gegenseitig - das ist definitiv so (y)
Ich kenne diese Hypothese, allerdings konnte ich dafür nie eine konkrete Erklärung finden, warum das so sein sollte. Das "Curve" im Curve Optimizer bezieht sich ja auf die Voltage/Frequency Kurve, d.h. die Spannung wird nicht immer um den gleichen Wert abgesenkt, sondern abhängig davon, wo man sich auf dieser V/F Kurve befindet (siehe auch diese beiden Slides hier: 1, 2).

Damit will ich nicht sagen, dass es nicht so ist, nur dass mir keine Erklärung bekannt ist, warum es so sein sollte. Und die Vorteile der Testmethode bleiben davon ja auch unberührt, dass man damit sehr instabile Settings erstmal auf eine halbwegs stabile Basis stellen kann, bevor man dann an die weitere Optimierung geht, ohne dass einem katastrophal instabile Kerne dazwischen funken.
 
Ich hab auch nicht behauptet, einen theoretischen Beweis dafür zu haben in Form von schlüssigen Beschreibungen der Aufteilung der voltage rails auf die Cores innerhalb eines CCD. Sehr wohl habe ich, wie auch andere, einen empirischen Beweis in Form von Tests, die das zeigen ;) Beides ist wissenschaftlich, oft gibt es zuerst eine Theorie, die dann bewiesen wird. In dem Fall gibt es einen Beweis, es fehlt aber die Theorie dazu, weil die Hersteller-Specs dazu (wie auch bei RAM-OC) eine Blackbox sind. Es interessieren sich wohl zu wenig Leute in dieser Tiefe dafür, dass die wenigen die es verstehen und designen, sich nicht mit der Öffentlichkeit abgeben.
 
Zuletzt bearbeitet:
Jetzt muss ich nur noch herausfinden und gezielt reproduzieren können warum nach Last, wie z.B. Prime und HWinfo offen ein gewollter WindowsNeustart! der PC dann in der CPU Erkennung (rote LED) hängen bleibt. Hätte ich ein herunterfahren! gemacht und danach wieder eingeschaltet, passiert das nicht.
Also Warmstart vs Kaltstart.
Ob da die CO Werte irgendwie Hineinfunken.
Manchmal hängt er auch bei der gelben LED (RAM).
Aber auch bei Default Settings hatte ich das schon. Manchmal hilft dann nur Clear CMos.

Werde noch nicht ganz schlau daraus. Irgendwas ist da noch im argen.

Kann HWinfo da irgendwas mit zu tun haben?
Einen wunderschönen!!! :-)

Einfach nur ne INFO!

war ja lange nicht mehr aktiv und halt auch sehr frustriert das ich den PC so gut wie nie neu starten konnten.
Letztendlich hatte ich mich damit "arrangiert/abgefunden" ---- naja nicht wirklich :devilish:

Dann hab ich durch Zufall mal die Software von meinen LIAN LI Lüftern aktualisiert und der Changelog ließ mich grübeln

"L3 v2.0.26​

Verfasst am: 04-01-2025
  • CPUID SDK wurde durch HWiNFO SDK ersetzt, um die Kompatibilität auf AMD-Plattformen zu verbessern und ein Problem zu beheben, bei dem das System „0d“ anzeigte und nach einem Neustart oder Aufwachen aus dem Ruhezustand nicht booten konnte."
Das hat tatsächlich schon Verbesserung gebracht und ich googelte weiter.
Es gibt bei ASUS tatsächlich eine Einstellung im UEFI
andersc_0-1730126710829.jpeg

Diese ist total an mir vorbei gegangen und ich hab es beim wochenlangen Suchen nie gefunden.
Keine Ahnung was der Schalter genau macht aber es scheint ja ein bekanntest Problem mit Monitoring Softwares in bestimmten Hardwarekonfigurationen zu geben, sonst gäbe es den Knopft ja nicht :ROFLMAO:

Also wer da auch Probleme haben sollte, das war bei mir die Lösung ---> ENABLED
das da irgendeine Software was mit zu tun haben könnte, würde ich mal pauschal ausschließen. Schließlich ist die Software da mal überhaupt noch nicht geladen
Diese Antwort hatte ich damals auch erwartet, aber du siehst man lernt nie aus wie so ne (doofe) Software tatsächlich nen "Hardware Reboot" beeinflussen kann.

***sry für OffTopic aber ich dachte ich poste die Lösung auch hier da ich euch damals auch hier um Hilfe gebeten hatte. ✌️
 
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