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

[Creekground]

CO stabil zu haben ist essentielle Grundvoraussetzung

Finde ich auch. Gerade in Kombi mit dem S3 Bug. Bei meiner CPU ist CO -30 unmöglich, da ein Kern ziemlich zickig ist. Jeden einzelnen Kern einstellen klinkt ja auch nerdiger.

Mit der von @BreadPit ausklügelnder Testmethode geht das recht schnell. Ich hatte keinen Absturz seit dem.

 

[BreadPit]

Da wir uns hier so nett über PRD / Power Reporting Deviation unterhalten, und mein Setup auch nicht unfehlbar ist, genau wie ich : seit ich die 6900XTX hab, hab ich selten einzelne WHEA, wenn ich die massiv übertakte (400-500W).

Wenn ich mir die CPU-Logs in HWinfo ansehe, fällt mir das hier auf:

Spoiler: CPU Package Power & PRD nach 50h Logging

Normal sieht das nach einem HWinfo-Reset so aus, nach einem TimeSpy Durchlauf:

Spoiler: CPU Package Power & PRD nach HWinfo Reset & TimeSpy Durchlauf

PRD hat ja nur unter Vollast Relevanz, daher auch während eines Cinebench Laufes gemessen:

Spoiler: CPU Package Power & PRD unter Vollast CB23

Das passt ja perfekt.

Ideen? Btw Ryzen Master hab ich natürlich aus dem Adrenalin entfernt, da ich den Treiber mit Radeon Software Slimmer aufs Minimum verschlanke.

 

[SeniorY]

die min max Werte von PRD sind irrelevant. Bei Vollauslastung aller Kerne (CB23 z.b) sollte PRD möglichst nahe an 100% liegen. Für einen Gaming PC dann aber auch wieder zu vernachlässigen.

 

[BreadPit]

Genau - und das ist der Fall, unter CB23 und während des TS Durchlaufes passt alles bei ~96-106%. Am merkwürdigsten find ich die unmöglich hohe CPU Package Power mit 176W, könnte das ggf der WHEA19 Auslöser sein?

 

[SeniorY]

CPU Package Power mit 176W, könnte das ggf der WHEA19 Auslöser sein?

da bin ich überfragt

 

[sp00n.82]

Wäre natürlich hilfreich zu wissen, wann das aufgetreten ist bei den 50 Stunden.
Bei HWINFO kann man ja Alerts bei Erreichen eines bestimmten Wertes setzen, evtl. kannst du das damit eingrenzen (und/oder mitloggen lassen).

 

[BreadPit]

Da hier ja einige meine mehrstufige CoreCycler Methode + Konfig zum CO & Stabilität ausloten nutzen: @sp00n.82 hat nun endlich CoreCycler 0.9.5.0 released (danke!!), der u.a. ein Update auf den aktuellen Y-Cruncher 0.8.4.9538 mit sich bringt.

Das wiederum bedeutet, dass meine Konfig nur noch mit dem Modus YCRUNCHER_OLD funktioniert, weil HNT, N64, VST & C17 ersetzt wurden, und zwar mit N63 und VT3:

• The HNT, N32, N64, VST, and C17 algorithms are now obsolete. (...)
• The replacements are N63 and VT3, which are rewrites of the N64 and VST respectively using the new FFT design.

Bei mir war ja ausgerechnet HNT der Test, der idR den Rechner in die Knie bzw zum Reset gezwungen hat. Dh ich hab jetzt 2 Varianten

• die alte Konfig übertragen auf die neue CoreCycler Version mittels YCRUNCHER_OLD mit HNT, N64, VST, C17
• die neue Konfig mit N63 und VT3, was den Prozess vereinfacht / verkürzt, wo mir aber Erfahrungswerte fehlen.

Hat jemand von euch schon Erfahrung gesammelt mit N63 und VT3? Ich würde ja auf @MehlstaubtheCat wetten

Hier mein Konfigs:

Spoiler: CoreCycler 0.9.5.0 YCRUNCHER Config

[General]
# General settings
stressTestProgram = YCRUNCHER
stopOnError = 0
skipCoreOnError = 1
numberOfThreads = 2

coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
runtimePerCore = 128s
# runtimePerCore = 32s --> Quick check N63
# runtimePerCore = 128s --> Medium check N63 + VT3
# runtimePerCore = 256s --> Full Final Check overnight N63 + VT3
restartTestProgramForEachCore = 0
# restartTestProgramForEachCore = 0 is default, and leaves the Y-Cruncher window open so you can scroll thru to check for errors; 1=enabled leads to not seeing errors in the Y-Cruncher test window as it restarts with each core
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
beepOnError = 1
flashOnError = 1
lookForWheaErrors = 1

[yCruncher]
# y-Cruncher specific settings
mode = 19-ZN2 ~ Kagari
tests = N63, VT3
# tests = N63 --> Quick check N63
# tests = N63, VT3 --> Medium check N63 + VT3
# tests = N63, VT3 --> Full Final Check overnight N63 + VT3
# tests = BKT, BBP, SFT, SNT, SVT, FFT, N63, VT3 --> all tests

[Logging]
name = CoreCycler
logLevel = 2
useWindowsEventLog = 1

[Debug]
delayFirstErrorCheck = 5
# With this setting you can define a wait time before the first error check happens for each core
stressTestProgramWindowToForeground = 0
# 1 throws an error "window cannot be found" in 0.9.4.2

Spoiler: CoreCycler 0.9.5.0 YCRUNCHER_OLD Config

[General]
# General settings
stressTestProgram = YCRUNCHER_OLD
stopOnError = 0
skipCoreOnError = 1
numberOfThreads = 2

coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
runtimePerCore = 192s
# runtimePerCore = 32s --> Quick check HNT
# runtimePerCore = 128s --> Medium check HNT + C17
# runtimePerCore = 192s --> Medium check HNT + VST + C17
# runtimePerCore = 256s --> Full Final Check overnight N64, HNT, VST, C17
restartTestProgramForEachCore = 0
# restartTestProgramForEachCore = 0 is default, and leaves the Y-Cruncher window open so you can scroll thru to check for errors; 1=enabled leads to not seeing errors in the Y-Cruncher test window as it restarts with each core
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
beepOnError = 1
flashOnError = 1
lookForWheaErrors = 1

[yCruncher]
# y-Cruncher specific settings
mode = 19-ZN2 ~ Kagari
tests = HNT, VST, C17
# tests = HNT --> Quick check HNT
# tests = HNT, C17 --> Medium check HNT + C17
# tests = HNT, VST, C17 --> Medium check HNT + VST + C17
# tests = N64, HNT, VST, C17 --> Full Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17 --> all tests

[Logging]
name = CoreCycler
logLevel = 2
useWindowsEventLog = 1

[Debug]
delayFirstErrorCheck = 5
# With this setting you can define a wait time before the first error check happens for each core
stressTestProgramWindowToForeground = 0
# 1 throws an error "window cannot be found" in 0.9.4.2

 

[Creekground]

Hat jemand von euch schon Erfahrung gesammelt mit N63 und VT3?

Ich habe denn ycruncher mal in einen neuen Ordner kopiert. Deine Config mit reingenommen.
Bei Gelegenheit (Nachtschicht) lasse ich das mal laufen. Da bin ich mal gespannt ob sich bei N63 und VT3 die CO´s noch nach unten ändern lassen.

 

[BreadPit]

Beachte meine "Anlaufschwierigkeiten", die ich im verlinkten Release-Thread dokumentiert habe. Hab es zuerst mit Benutzerrechten gestartet, geht nicht. Dann mit Adminrechten für die einmalige Einrichtung der Windows Eventlog Source (offenbar geht es auch ohne, hab kein Fenster für die einmalige Einrichtung bemerkt), lief. Dann mit Benutzerrechten gestartet, da gabs nen Hänger im Testfenster beim ersten Test, aber der lief über alle Cores weiter. Dann wieder mit Adminrechten, lief. Dann wieder mit Benutzerrechten, läuft jetzt während ich am See sitze - bin gespannt wie lange 😉

 

[BreadPit]

Update: alles schon gefixed in 0.9.5.2 Derweil laufen die bisher stabilen CO Werte von 0.9.4.2 schon mal 4h durch, stay tuned

 

[Creekground]

Mein Test mit 128s VT3 und N63 ist mit um -4 verringerten CO als normal jetzt 5 Stunden ohne Fehler gelaufen. Das Teste ich jetzt mal so im Alltag.

 

[BreadPit]

Bei mir 5h ohne Fehler mit demselben CO wie bisher.

Dh das läuft bei Dir mit mehr CO = weniger vCore?

 

[Creekground]

Ja genau.

 

[Fas7play]

Guten Morgen, hab jetzt mal über eine Stunde den "overnighter" laufen lassen..

Tauche jetzt aber wieder in "Days Gone" ab, sofern ich es nicht vergesse liefere ich einen richtigen "overnighter" nach. Schönen Sonntag noch.

 

[sp00n.82]

Es gibt mittlerweile sogar nochmal eine neue y-Cruncher Version, mit nochmal leicht anderen Tests.
Aber ich glaube ich warte, bis die finale Version für Zen5 rauskommt, das sollte eigentlich nicht mehr so lange dauern.

Und falls jemand mal mit Linpack Xtreme testen möchte, ich hab das versuchsweise mal hinzugefügt:
https://github.com/sp00n/corecycler/archive/refs/heads/linpack.zip

Wobei Linpack Xtreme auf der Intel MKL Bibliothek basiert, und AMD nur per undokumentierter Umgebungsvariable richtig genutzt werden kann.

Ich kopiere jetzt einfach mal den englischen Text dazu:

You can enable it by setting stressTestProgram = LINPACKXTREME

And in the [LinpackXtreme] section you can choose between various modes: SLOWEST, SLOW, MEDIUM, FAST & FASTEST
These modes define which instruction sets are being used by Linpack, FASTEST should be AVX2, FAST should be AVX, and the rest something else, probably SSE (resp. newer or older ones, like SSE2, SSE3, FMA3).
It's not entirely clear which instructions are used exactly, since Linpack Xtreme uses Intel's MKL library, which was not designed for AMD processors, and so you have to use an undocumented debug setting (the MKL_DEBUG_CPU_TYPE environment variable), for which only the 4 and 5 value are known what they're doing (they enable the usage of AVX and AVX2 respectively). At least I think so, as mentioned, this setting is undocumented. But I noticed that values lower than 4 also change the GFlops and testing time, so I assume they use different older instructions.
The setting defaults to MEDIUM (so neither AVX nor AVX2).

You can also choose how much memory to test, it's defaulting to 2GB, which is the lowest value you can choose in the standalone version of Linpack Xtreme.
The amount of memory directly influences how long one test takes, the 2GB took around 100 seconds with MEDIUM (and 40 on FASTEST) for me, while 30GB already ran over an hour before I aborted.

 

[Creekground]

Jedenfalls ist N63 und VT3 mal weniger scharf. Konnte jetzt alle Cores um -6 verringern.

 

[BreadPit]

OK, das ist nicht die Idee eines Stresstests 😉 Dann bleib ich bei der YCRUNCHER_OLD Config mit HNT, VST, C17 und N64. @sp00n.82 bitte supporte die auch weiterhin!

 

[Fas7play]

.. dann spare ich mir das über nacht laufen lassen.

ist jetzt 0.9.4.2 zu "hart" oder 0.9.5.2 doch zu "weich"?

 

[BreadPit]

Ich würde 0.9.5.2 mit YCRUNCHER_OLD nutzen, also HNT etc. Die Vorteile wie Windows Eventlog etc bleiben ja trotzdem. Die Frage ist ob HNT, N64, VST, C17 zu hart, oder N63/VT3 zu weich ist 😉

Das ist wohl eine Glaubensfrage 😉 Was glaubt ihr?

 

[MehlstaubtheCat]

Also ich bleibe beim alten "harten" ich weiß gerade nicht die Versionsnummer, die ich als Letztes nutze.
Aber mir sind die "neuen" Versionen zu lasch/schwach.
Würde mich freuen, wenn da N64 wieder am Start ist, oder noch etwas Härteres.
Es gibt kein zu hart! Es kann nie hart genug sein!

Gruß
Mehlstaub