[Work-Log] Aufrüsten auf einen 5800X3D! Was ist an Leistung möglich!

[Creekground]

heißt das nicht einfach, dass die neue Version nicht mehr so stressig ist für die Cores

sieht so aus. Beim alten Test wurde die Last gleichzeitig auf z.B. Kern 0 und 1 gelegt. Jetzt toggled er die Last auf z.B. Kern 0 und 1. Jedenfalls bringt er keine Fehler mehr wenn man die CO wieder tiefer setzt. Weiß jetzt auch nicht welcher Test sinnvoller ist, bzw. der Realität am besten entspricht. Ich setze meinen schlechtesten Kern wieder auf -14. Somit habe ich wieder eine gleichmäßigere CO Kurve und weniger VCore. Incl. weniger. Watt.

So wie ich das gesehen habe, fängt der Y-Cruncher wieder von vorne an wenn er einen Fehler erkannt hat.

 

[Verangry]

Testet das mit dem ycrunsher in der standalone doch mal quer, ob nun der CC dafür verantwortlich ist oder ob es am Test liegt.

Ich hab mein aller erstes CO setting auch mit Prime standalone getestet, dann gab es erst den CC und damit kamen Fehler auf, ob das heute gefixed ist weiß ich nicht.

Deswegen nutze ich fast immer nur die Programme ohne die Scripts vom CC.

 

[BreadPit]

Ich finde ja es sollte der Test Standard sein, der die meisten Fehler provoziert - nicht die wenigsten? Ein Stresstest, der mehr Fehler liefert als ein anderer, muss nicht gefixed werden - sondern preisgekrönt?

Sonst kann ich ja gleich auf Game-stable gehen = schauen ob Games abstürzen, wenn nicht = stabil? Passiert bei mir übrigens kaum, bei mir war immer eher Idle Reboot das Problem, ähnlich wie bei @Adonay mit Teillast.

CoreCycler 0.9.3 provoziert bei mir die meisten Fehler, und die Settings laufen dann auch ewig im Idle und beim RAM-OC. Das find ich sinnvoll.

Wenn jetzt die neue Version +10 CO erlaubt, dann ist das doch einfach "verschlimmbessert", aber nicht gefixed? Oder der Autor hat es irgendwie in 0.9.3 geschafft, die CPU völlig jenseits jeglicher jemals in Realität auftretenden Lastzenarien zu betreiben - und das in der aktuellen Version entschärft. Ich bin halt der Meinung eine CPU muss jede Software ohne Absturz schaffen, die man auf sie wirft - sofern im Temp- und Stromfenster.

 

[sp00n.82]

@Verangry
Die Fehler kamen damals von der verwendeten Prime95-Version, die selbst ein Problem hatte.


@Creekground (und alle anderen)
Das neue assignBothVirtualCoresForSingleThread Setting ersetzt NICHT einen Test mit 2 Threads! Bitte genau lesen! Damit werden einem Thread zwei virtuelle Kerne zur Verfügung gestellt, damit der Windows Scheduler dann die Last zwischen den beiden Kernen hin- und herwechseln kann, was unter Umständen(!) Probleme beim Lastwechsel aufdecken könnte.
Es ersetzt keinen der anderen Tests, sondern ist nur eine weitere Möglichkeit, Probleme zu entdecken!
Deswegen ist die Einstellung standardmäßig ja auch nicht aktiviert.


@BreadPit
In der nächsten Version bleibt das Fenster vom Stresstest (y-Cruncher) offen, wenn stopOnError = 1 gesetzt wird. Bisher wird es auch mit der Einstellung geschlossen, ja.
Wenn der Wert nicht gesetzt ist, dann wird der Stresstest bei einem Fehler immer geschlossen und neu gestartet, ansonsten könnte das Testen nicht fortgeführt werden.

 

[BreadPit]

OK, dann hab ich korrekt in der default.ini gelesen (0 ist Standard und macht restart), und auch getestet (1 macht das gleiche wie 0).

Vorschlag: stopOnError = 0 wäre naheliegender. 0 heisst ja digitales "Aus", 1 = "Ein". Und wir wollen ja nicht, dass der Stresstest ein Stop macht und das Fenster offen bleibt, also müsste es stopOnError = 0 heissen?

 

[sp00n.82]

1 ist schon richtig so, da die Einstellung, dass der gesamte Stresstest bei einem Fehler anhält, damit aktiviert wird.

 

[Creekground]

Es ersetzt keinen der anderen Tests, sondern ist nur eine weitere Möglichkeit, Probleme zu entdecken!

Danke nochmal für die Erklärung. Dann setzt ich das mal wieder zurück.

 

[BreadPit]

In der nächsten Version bleibt das Fenster vom Stresstest (y-Cruncher) offen, wenn stopOnError = 1 gesetzt wird. Bisher wird es auch mit der Einstellung geschlossen, ja.

1 ist schon richtig so, da die Einstellung, dass der gesamte Stresstest bei einem Fehler anhält, damit aktiviert wird.

Wenn der Wert nicht gesetzt ist, dann wird der Stresstest bei einem Fehler immer geschlossen und neu gestartet, ansonsten könnte das Testen nicht fortgeführt werden.

Ach so funktioniert das! Dh stopOnError = 1 gilt für CoreCycler, nicht für den Stresstest, deshalb
2 Szenarien bei Fehler:

• stopOnError = 1: Stresstest stop / CoreCycler stop
  • Stresstestfenster bleibt --> Fehler sichtbar
  • CoreCycler läuft aber nicht weiter weil er auf Stresstest wartet
• stopOnError = 1: Stresstest stop / CoreCycler rennt weiter
  • CoreCycler merkt den Fehler durch CpuUtilCheck
  • ... und läuft weiter, indem er den Stresst einfach neu startet

Dieses Szenario hier wäre mein Wunschszenario bei Error:

• Stresst läuft trotz Error weiter / CoreCycler läuft auch trotzdem weiter
  • Dann sieht man in beiden Fenstern die Fehler, im Stresstest den Test & im CC den Core
  • Müsste doch gehen mit dem Stresstest = Y-Cruncher Setting "Stop on Error Disabled"?
  • Siehe Screenshot unten - auf Disabled?

 

[Verangry]

@sp00n.82

Okay, dann war das die fehlerhafte Prime Version, dennoch lohnt es sich halt ab und an mal ohne Scripte ein Programm laufen zu lassen und sei es nur für die Fehler Analyse.

Ich wusste nun nicht mehr wie das damals war, ist ja auch ein bisschen her

 

[sp00n.82]

Dieses Szenario hier wäre mein Wunschszenario bei Error:

• Stresst läuft trotz Error weiter / CoreCycler läuft auch trotzdem weiter
  • Dann sieht man in beiden Fenstern die Fehler, im Stresstest den Test & im CC den Core
  • Müsste doch gehen mit dem Stresstest = Y-Cruncher Setting "Stop on Error Disabled"?
  • Siehe Screenshot unten - auf Disabled?

Anhang anzeigen 1357676

Schau ich mir mal an, das könnte gehen. Das wäre dann eine neue y-Cruncher spezifische Einstellung, die mit dem stopOnError Setting in der [General]-Sektion nichts mehr zu tun hätte, weil das ja generell für CoreCycler gilt.
Vermutlich dann sowas wie [yCruncher]continueDespiteError, um es unterscheidbar zu machen.

// Edit
Hmmm, vermutlich geht das nicht, weil dann die CPU-Last nicht heruntergeht und CoreCycler keine Möglichkeit hat, den Fehler zu erkennen.


Alles wäre so viel einfacher, wenn y-Cruncher einfach eine Logfile anlegen würde bzw. man die Ausgabe umleiten könnte.

Mir kam vorhin ein verrückter Gedanke, bei einem Fehler einen Screenshot des Fensters anlegen zu lassen, da lese ich mich gerade ein wenig ein. Allerdings blicke ich da noch nicht durch, ob das überhaupt möglich ist für ein Fenster im Hintergrund.

 

[BreadPit]

Schau ich mir mal an, das könnte gehen. Das wäre dann eine neue y-Cruncher spezifische Einstellung, die mit dem stopOnError Setting in der [General]-Sektion nichts mehr zu tun hätte, weil das ja generell für CoreCycler gilt.
Vermutlich dann sowas wie [yCruncher]continueDespiteError, um es unterscheidbar zu machen.

// Edit
Hmmm, vermutlich geht das nicht, weil dann die CPU-Last nicht heruntergeht und CoreCycler keine Möglichkeit hat, den Fehler zu erkennen.

Hmmm... verstehe. Die Möglichkeit, nur den gerade laufenden Test zu beenden, aber nicht die folgenden, hat Y-Cruncher nicht? Dann würde ja auch die CPU Last temporär runter gehen (außer der Fehler tritt ganz am Ende von zB N64 1min Zyklus auf).

 

[sp00n.82]

y-Cruncher macht entweder Pause nach einem Fehler oder einfach weiter:

    pause:1     Always pause at the end of a computation.
    pause:0     Default behavior - automatically decide whether to pause.
    pause:-1    Never pause at the end of a computation. Will pause on errors.
    pause:-2    Never pause at all, not even on errors.

Bei keiner Pause hat CoreCycler keine Chance, den Fehler zu erkennen, da die Zeit ohne Last zu kurz ist. Falls es überhaupt eine gibt.

 

[BreadPit]

Allerdings blicke ich da noch nicht durch, ob das überhaupt möglich ist für ein Fenster im Hintergrund.

Apropos Hintergrund - ich hätte das eh gern beim Start im Vordergrund, geht das?
Würde auch das Screenshot-Thema lösen

Ergänzung (15. Mai 2023)

@sp00n.82 Noch was: die Core-Numerierung passt nicht ganz, siehe hier:

Core 0 = CPU 0, 1
Core 1 = CPU 2, 3
Core 2 = CPU 4, 5
Core 3 = CPU 6, 7

Core 3 (CPU 3 or 4) passt da nicht, oder?

Ergänzung (15. Mai 2023)

Und JA, CoreCycler nervt mich schon - immer findet der noch was. Zwischenstand:

• Bei vCore Offset -0,1000 - -0,1250 mit BCLK OC ist N64, VST, C17 kein Problem. Dafür HNT - alle heiligen Zeiten immer wieder ein anderer Core mit HNT Reboot.
• Mit BCLK Auto = 100MHz ohne Offset war HNT erst einmal ein Problem, dafür findet er immer wieder mal noch nen Core mit Error bei einem der anderen Tests.

Jetzt hab ich den Grund warum bei mir nur HNT angeschlagen hat - der reagiert wohl am meisten auf zu niedrige Spannungen, die anderen eher bei grenzwertig zu hohen?

 

[sp00n.82]

Apropos Hintergrund - ich hätte das eh gern beim Start im Vordergrund, geht das?
Würde auch das Screenshot-Thema lösen

Seit Version 9.4.0 ja, mit stressTestProgramWindowToForeground = 1 in der [Debug] Sektion.
Das löst das Screenshot Problem allerdings nicht wirklich, das Setting als Voraussetzung dafür zu haben, möchte ich nicht.

@sp00n.82 Noch was: die Core-Numerierung passt nicht ganz

Ja, das hat tatsächlich heute schon jemand anders bemerkt, und ist glaube ich bereits von Anfang an so falsch bei einer Fehlermeldung bei 2 Threads. Ist nur keinem aufgefallen bisher. 🫣
Die Nummer des Kerns stimmt, bis zur nächsten Version kann man die Nummern der CPUs einfach ignorieren.

 

[Adonay]

Ich bin halt der Meinung eine CPU muss jede Software ohne Absturz schaffen, die man auf sie wirft - sofern im Temp- und Stromfenster.

Genau so sehe ich das auch, deshalb war es für mich keine Option die CPU mit -30 Allcore laufen zu lassen obwohl ja "nur" SotTR nicht stabil läuft.
Nein, die CPU ist nicht stabil, Punkt.

Gleiches übrigens im Fall meiner GPU, alles Games laufen auch mit -100mV aber Timespy schmiert ab und läuft erst ab -50mV also belasse ich es dabei!

Am Ende sind die Unterschiede der Temperatur meist so marginal, die Differenz zwischen -30 Allcore und meinem aktuellen Setting beträgt nur 1 Kelvin bei der GPU sind es nur 4, wohlgemerkt Hot Spot.

 

[Verangry]

Gebe ich euch Recht.
Problem ist nur, wenn das Programm an sich schon Fehler enthält (wie die Prime Version damals - siehe Aussage von sp00n).

Man testet sich dumm und dämlich und am Ende liegt es eben nicht an der CPU..

Ist wie beim RAM OC... nur ein Stabilitätstest ausführen bringt auch nix, lieber mit vielen Tests quer testen, natürlich auch gaming...

 

[Adonay]

Das ist richtig aber es ist ja, zumindest in meinem Fall, sowohl bei CPU und GPU offensichtlich zu viel UV wenn man die Fehler mit weniger bzw. mehr Spannung abstellen kann.

Mein Gedanke ist da auch der an die Zukunft, nun läuft alles außer Timespy aber demnächst kommt ein neues Game und dann geht der Spaß evtl. erst los, so setze ich mich nach der Installation entspannt hin und bleibe auch entspannt

 

[BreadPit]

Ja genau, so seh ich das auch. Einmal etwas Zeit in das finden / definieren eines gutes Testverfahren gesteckt, in Zukunft dann den Rechner damit durchgetestet, fertig.

Bei GPUs find ich das allerdings noch etwas schwieriger. Da ist bei mit Timespy & Firestrike durchgelaufen mit Vega & 5700 XT, aber Witcher 3 hat die Graka dann in die Knie gezwungen

 

[Creekground]

Ich bin natürlich bei euch. Bringt ja nix wenn der PC mit ein paar mV weniger abstürzt. Ich hatte mit der neuen Corecycler Version auch nur einen Quertest der Lastwechsel durchgeführt.
Heute dann nochmal den 256S N64, HNT, VST und C17 Test angeschmissen. Musste den schlechten Kern wieder etwas angepassen.

 

[4BitDitherBayer]

Gebe ich euch Recht.
Problem ist nur, wenn das Programm an sich schon Fehler enthält (wie die Prime Version damals - siehe Aussage von sp00n).

Man testet sich dumm und dämlich und am Ende liegt es eben nicht an der CPU..

Ist wie beim RAM OC... nur ein Stabilitätstest ausführen bringt auch nix, lieber mit vielen Tests quer testen, natürlich auch gaming...

Im Prinzip ist das dann wie eine Schadsoftware die man nutzen könnte damit der Rechner neu startet u. dabei den Schad Code dann ausführt.

Was ich mich auch noch frage ob es nicht vielleicht auch "teil defekte" CPU´s gibt die AMD noch für gut befindet die aber anfällig in unserem kleinen Test Parkour hier sind.
Sowas würde sich dann wohl zeigen wenn 1 Kern extrem aus der Reihe tanzt wenn z.B. alle kerne unter -20 liegen aber einer bei -5.