News AMD Ryzen 5000: CoreCycler aus der Community optimiert den Curve Optimizer

[Dreamcatcher3]

Edit:

ich habe jetzt den CO und PBO abgeschaltet und wie auch @--Q-- und @Dreamcatcher3 das Phänomen, dass CC trotzdem Fehler wirft!

Ich habe jetzt mal das BIOS auf Default setzen lassen (da ich auch meinen RAM-OC ausschließen will) und lasse gerade nochmal durchlaufen.

Irgendwas scheint da nicht zu stimmen...

Bei mir ist der Fehler weg nachdem ich im BIOS AMD CBS noch deaktiviert habe.

CPU läuft jetzt auf 3GHz und 3.8GHz Boost. ^^

 

[DannyA4]

Erst nachdem ich das BIOS auf Default gesetzt habe, lief der Test komplett sauber durch. Ich schätze es wird an meinem RAM-OC gelegen haben.
Also nochmal von vorne...

 

[Wan900]

Evtl. auch mal PCIe4.0 auf 3.0 runterstellen. Das lief mit einigen Beta-Bios Versionen manchmal ebenfalls nicht stabil.

 

[--Q--]

Erst nachdem ich das BIOS auf Default gesetzt habe, lief der Test komplett sauber durch. Ich schätze es wird an meinem RAM-OC gelegen haben.
Also nochmal von vorne...

Ich muss wohl heute noch mal testen. Hatte gestern schon defaults im BIOS geladen und trotzdem noch Fehler. Evtl wurde nicht alles sauber zurückgesetzt.

 

[Javeran]

Der hohe IF bei RAM OC beeinflusst die Kerne doch auch oder nicht? Wäre nicht erst stabiles RAM OC und dann die Kerne sinnvoller also ohne RAM OC zu testen?

 

[DannyA4]

Hier stand Mist

 

[sp00n.82]

Der hohe IF bei RAM OC beeinflusst die Kerne doch auch oder nicht? Wäre nicht erst stabiles RAM OC und dann die Kerne sinnvoller also ohne RAM OC zu testen?

Prinzipiell sollte man RAM OC und CPU OC getrennt voneinander auf Stabilität testen, ansonsten weiß man nie genau, woher der Fehler eigentlich kam. Und erst wenn beides stabil läuft, das ganze dann zusammen testen.

Und noch eine Anmerkung zur Dauer des Tests: ein Durchlauf á 6 Minuten reicht keinesfalls aus, um sich selbst das "stable"-Logo zu verpassen. Lasst das Teil mindestens über Nacht laufen. Eher mehr. Viel mehr. Viel viel mehr. Und wechselt dann auch die FFT Größen und den Testmodus durch.
Ich experimentiere gerade mit FFT Größen, die bei den Standardtests von Prime95 gar nicht angeboten werden (>8192) und meine beiden besten Kerne haben da wieder Fehler geworfen.

 

[--Q--]

Also ich bekomme nach wie vor selbst nach BIOS reset/optimized defaults und danach noch explizit PBO off trotzdem Fehler geworfen.
CPU defekt?

Prime manuell mit den selben Einstellungen, zB zugewiesen auf Core7, welcher zuvor einen Fehler warf, läuft nun aber schon seit 20 Minuten.
Edit: Läuft über Nacht einwandfrei durch.

 

[Dreamcatcher3]

@--Q--
Ich hab bei meinen beiden fehlerhaften Cores den Fehler bis jetzt wegbekommen.
Ich habe ein positiven Offset von 6 im CurveOptimizer gesetzt.

 

[--Q--]

Probiere ich mal @Dreamcatcher3 . Kann aber ja eigentlich nicht die Lösung sein. @stock sollte er fehlerfrei laufen. Ansonsten wäre das eine ab Werk falsch kalibrierte Curve.

@sp00n.82 müssen noch weitere Einstellungen manuell gemacht werden, außer die in Deinem Post eine Seite zuvor?
“Meine“ Prime Installation verhält sich nur mit diesen Einstellungen anders, als die des CoreCyclers. Da laufen die einzelnen Tests mit den verschiedenen Größen öfters durch.

 

[Rodger]

Ob nun -4 oder -28 instabil ist. Instabil ist instabil und ich verstehe da einige nicht, die da unbedingt 5er Schritte einstellen wollen. Ist für mich sinnbefreit.

Ich bekam letztens gegen Ende des Testens wieder Reboots....nochmal ALLE durchlaufen lassen, da gabs wieder bei 5 Kernen Meldungen. Jeweils 1 runter und keine Fehler mehr und keine Reboots.
Es kann wirklich der Wert 1 sein, der hier über Sieg oder Niederlage entscheidet oder halt auch den einen Kern stabil sein lässt und den anderen nicht. Also 5er Schritte machen da absolut keinen Sinn.

Ich würde eher empfehlen, wenn ihr den ersten Fehler bekommt, dann 3 zurückrudern.
DAS wäre bei mir immer richtig gewesen. Eigentlich 2 zurück, aber nehmt halt 3. In jedem Fall bin ich maximal 3 zurück und die Kerne waren stabil. Das würde ich mit meiner bisherigen Erfahrung mit dem Tool sagen.

Hatte Bock erstmal was mit der Kiste zu machen....habe daher bei den drei verbliebenen Kernen bei -25 aufgehört. Hat aber überhaupt nix mit der Zahl zu tun, sondern weil mir erstmal die Lust/Zeit dazu fehlt.
Um genau zu sein, habe ich hierdurch die Lust gefunden mich mit meiner 6900XT nochmal zu beschäftigen und habe herausgefunden, das die Karte vor ne Mhz-Wall fährt. Ich schaffe dort das Maximum 2631Mhz auch mit 55mv weniger!!! Ergebnis....auch die Karte boostet jetz klar höher in vielen Szenarien oder spart Strom.
Ingame boostet die Karte jetz eigentlich ständig über 2,5Ghz. Irre!!!

Also! Ich würds euch echt empfehlen....sucht den Wert, der so gerade Fehler wirft und kurbelt um 3 zurück.
Das sollte ohne mega viel Nachtesten dann schon passen.

Spoiler: Aktuelle Werte

Core 0 (-25)
Core 1 -18
Core 2 -08
Core 3 (-25)
Core 4 -22
Core 5 -11
------------bis hier ist eigentlich das gute CCD (perf#) in HWinfo
Core 6 -16
Core 7 -20
Core 8 -21
Core 9 (-25)
Core 10 -15
Core 11 -22

Unsere ermittelten Werte hier zu Posten ist bestimmt auch sinnbefreit, weils jeweils die Kombi CPU+Board ist und eine andere Kombi andere Werte bringen wird. Aber vielleicht spornt es ja noch Leute an
Cinebench 23249/1666 mit Spitze 218W
4,575 bis 4,6Ghz auf allen Pötten in Cinebench.

 

[Wan900]

Ob nun -4 oder -28 instabil ist. Instabil ist instabil und ich verstehe da einige nicht, die da unbedingt 5er Schritte einstellen wollen. Ist für mich sinnbefreit.

Ich bekam letztens gegen Ende des Testens wieder Reboots....nochmal ALLE durchlaufen lassen, da gabs wieder bei 5 Kernen Meldungen. Jeweils 1 runter und keine Fehler mehr und keine Reboots.

Dass mit den 5er-Werten ist halt bei mir einfach aufgrund der Stabilität geschuldet.

Ich habe bei mir zunächst ebenfalls das Maximum ausgelotet, welches knapp 6 Stunden ohne Probleme durchläuft.
Dabei liefen auch Kerne z.T. bis -27 ohne Probleme.

Ich habe mir dennoch anschließend ein oberes Limit von -20 gesetzt, d.h. alle Werte auf maximal diesen Wert abgerundet.
Dann habe ich auch die unteren Kerne auf den nächst kleineren 5er Wert gesetzt. Beispielsweise lief mein bester Kern auch mit -7 noch 6 Stunden stabil, habe dort dann aber -5 eingestellt, bei -13 habe ich -10 genommen, etc).

Dann gestern Nacht nochmal 10 Stunden mit größeren FFTs durchlaufen lassen, wieder ohne Probleme.

So kann man denke ich ein sehr sehr stabiles System bekommen, ohne wochenlang Testen zu müssen.

 

[SVΞN]

Artikel-Update: CoreCycler 0.7.8.9 erschienen
In der Zwischenzeit hat „sp00n.82“ die Versionen 0.7.8.5, 0.7.8.6 sowie aktuell 0.7.8.9 veröffentlicht und erneut zahlreiche Verbesserungen in das CPU-Tool einfließen lassen.

• v0.7.8.5
  
  • Added a "verbosityMode" setting which displays additional information either in the log file or also in the terminal.
  • Added a "delayBetweenCycles" setting, which will set the CPU to idle for the specified time during core tests. Only works in conjunction with "restartPrimeForEachCore = 1".
  • Improved the detection of the correct Prime95 window instance if more than one window with the same name ("Prime95") is open (e.g. an Explorer window within a folder labeled "Prime95").
  • Reworked how the error decetion works. The check interval is now 10 seconds, and the script checks the results.txt file for an error in the last 3 lines. Only if it finds no error it will proceed to check the CPU usage. Also increased the delay between the first CPU power check and the second one to 2000ms instead of 1000.
  • Fixed an FFT size detection error when the results.txt had no "passed" entry yet.
• v0.7.8.6
  
  • Fixed a bug with the numberOfThreads setting not working.
• v0.7.8.9
  
  • Hopefully fixed the Performance Counter detection for good now.
  • Added a new "Huge" FFT size preset, which is now the default (8192K to max).

Der Autor und die Redaktion bedanken sich für den Support der Community aus dem ComputerBase-Forum und freuen sich nach wie vor über weitere Tester und deren Feedback.

 

[sp00n.82]

Mit der Verion 0.7.8.9 wurde (wie beim Post von @SV3N auch zu sehen) auf die "Huge" FFTs umgestellt, also die Werte oberhalb von 8192K. Damit sind bei mir in den letzten Tagen 3 weitere Kerne dazugekommen, die einen Fehler geworfen haben, unter anderem auch heute Nacht Kern 9, der zuvor seit dem 21. Februar(!) ohne Fehler durchgelaufen ist (mit Testläufen jeweils über Nacht oder länger).
Also ja, das Testen verschlingt weiterhin viel Zeit, wenn man eine sehr hohe Stabilität erreichen möchte.

Zusätzlich werde ich demnächst versuchen, noch andere Testprogramme einzubinden, kann da aber noch nicht sagen, ob das sinnvoll umzusetzen ist. Ich dachte da an AIDA64 (Portable Engineer Trail) und Y-Cruncher.
Das Problem ist halt, dass man die Tests von der Kommandozeile aus starten können muss, möglichst ohne Benutzerinteraktion. Und am besten noch mit Logdateien, die ich im Falle eines Fehlers auslesen könnte.
Die Portable Engineer Version von AIDA64 scheint zuminest Punkt 1 zu unterstützen und beim Y-Cruncher kann ich auch die einzelnen Binaries per Kommandozeile aufrufen.

Weitere Kandidaten sind gerne gesehen.

 

[SVΞN]

Ich halte AIDA64 und Y-Cruncher auch für die zwei besten Kandidaten.

Das Problem ist halt, dass man die Tests von der Kommandozeile aus starten können muss, möglichst ohne Benutzerinteraktion.

Vielleicht findet sich ja ein fähiger GUI-Entwickler in der Community, der eine einfache GUI für den CoreCycler realisieren möchte!?

Liebe Grüße
Sven

 

[sp00n.82]

Vielleicht findet sich ja ein fähiger GUI-Entwickler in der Community, der eine einfache GUI für den CoreCycler realisieren möchte!?

Das war eigentlich (erstmal) eher auf die Binaries der Stresstest-Programme an sich bezogen. Bei AIDA64 z.B. unterstützt nur die Engineer (und die Business sowie Network Audit)-Version Programmstarts per Kommandozeile direkt in den Stresstest, die "normale" Extreme-Version dagegen nicht.

 

[sebbolein]

@SV3N verlinkt doch die neueste Version in der News und nicht 7.2

 

[SVΞN]

@SV3N verlinkt doch die neueste Version in der News und nicht 7.2

Unter der News ist doch die neueste Version verlinkt, aber ich passe gerne auch den Fließtext an. Gute Idee! Danke sehr!

 

[SuperSabo]

Schon mal den CoreCycler auf Stock laufen lassen? Wirft bei mir ebenfalls Fehler... Ich glaube jetzt nicht dass du noch einen Fehler hast, da sich das Ergebnis auch mit Prime Stand Alone und Zuweisung des Kerns über den Taskmanager reproduzieren lässt... Frage mich aber gerade ob es hier noch weitere Personen gibt, die auch auf Stock Settings Fehler gemeldet bekommen. Im RAM OC Discord gibts da den ein oder anderen... AGESA Problem? Defekte CPU bzw. Kerne? Mainboard defekt? Hm...

 

[Schmarsen]

Also bei mir wirft er keine Fehler wenn ich Cure Opti deaktiviere aber PBO auf +200mhz belasse. Mit CO wirft er bei mir bei den Kernen die zu niedrig angesetzt sind immer nur Fehler bei FFT length 40K , nie bei den anderen Größen. Ich befürchte es könnte auch von zu wenig SoC Spannung kommen da der Speicher auf 3800 und der IF auf 1900 läuft (Speicher XMP 3600, CPU 5600x). AIDA64 läuft allerdings 1,5h ohne Probleme und Karhu meldete bei einem Run über Nacht auch keine Fehler... hmmm

Mal sehen wie es mit den Huge Größen läuft (8960K - 32768K)