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

Achso egal hier ein ausführlicher aktueller Test. :smokin: spiele eh in 4k da bringt ein bisschen mehr Takt bestimmt eh nichts.

 
Übrigens, noch ein Learning - euretwegen habe ich mich ja mit PRD gespielt @Creekground & @fas7play , davor nie davon gehört - und die BIOS Option war mir bis dahin unheimlich :D

Jetzt festgestellt:
  • von ~110% PRD (Auto) auf ~100 - 105% bringt ca +1%+ CPU-Z Score, CB23 kaum Unterschied
  • bei PRD <100% ist CPU-Z auch ca +1%, CB23 sogar ein wenig besser, ABER in AIDA64 ist L3 Cache Write Performance halbiert (~350) und Latenz fast verdoppelt (~20ns) bei BCLK OC 103,375!f
Wieder PRD auf ~104% --> alles gut. CPU austricksen auf Geek-Niveau... ;)
 
  • Gefällt mir
Reaktionen: Erpel und Creekground
@BreadPit mit PRD hatten die Boardhersteller getrickst um bessere Scores zu erreichen. Nach dem es bemerkt wurde, haben sie es angepasst.
 
  • Gefällt mir
Reaktionen: Fas7play und BreadPit
Ein weiteres Update: Y-Cruncher Config sollte lauten auf disableCpuUtilizationCheck = 0 laut Autor @sp00n.82 Sonst kann der Y-Cruncher keine Fehlerinfos zurückliefern. Das löst ev das Thema mit "Fehlerübergabe Y-Cruncher --> CoreCycler" ?

Keine Ahnung warum das auf 0 steht, hab das von irgendwem kopiert ursprünglich...

@Creekground Du hast ja festgestellt, dass mit restartTestProgramForEachCore = 0 sehr wohl die Fehler von Y-Cruncher zu CoreCycler übergeben werden, wenn man das Skript abbricht? Oder das eben nicht, sondern sie bleiben halt im Y-Cruncher Fenster sichtbar?
Ergänzung ()

Ach ja, und noch ne Erkenntnis:
  • {Game-stable} bedeutet nicht {Y-Cruncher stable}!
  • {Y-Cruncher stable} bedeutet nicht {Y-Cruncher + Game}-stable 🙈
Ein 16h lang Y-Cruncher stabiles Setting mit N64+HNT+VST+C17, das logischerweise auch Gamestable ist, macht binnen weniger Minuten einen sudden Reboot, wenn ich dabei Overwatch 2 zocke.

Next Level Stabilitätstest :D Ev hab ich auch noch nicht bei BCLK 103,375 gezockt und das stürzt immer ab, denke aber nicht - halte euch am Laufenden!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Creekground
Also Y-Cruncher übergibt leider gar nichts an CoreCycler, von daher ist disableCpuUtilizationCheck = 0 die einzige Möglichkeit, wie das Script erkennen kann, dass da irgendwo ein Fehler aufgetreten ist.
Falls jemand eine Ahnung hat, wie man die Ausgabe des Y-Cruncher-Terminals abgreifen kann, wenn sowas wie > logfile.txt 2>&1 nicht funktioniert, dann immer her damit. 🧐

Wenn sowohl restartTestProgramForEachCore = 0 als auch disableCpuUtilizationCheck = 1 gesetzt ist, dann läuft CoreCycler bei einem Fehler in Y-Cruncher einfach weiter, ohne dass es je etwas von dem Fehler mitbekommen wird.
Zusätzlich wird Y-Cruncher immer mit Core 2 (und 3 bei zwei Threads) initialisiert, sodass man dann keinerlei Anhaltspunkte hat, bei welchem Kern der Fehler eigentlich aufgetreten ist. Im CoreCycler taucht ja nichts auf, da es kein Feedback erhält, und im Fenster von Y-Cruncher wird dann immer Core 2 (und gegebenfalls 3) stehen.
 
Bei restartTestProgramForEachCore = 1 und disableCpuUtilizationCheck = 1 aber genau so, oder?

Also folgende Varianten gehen nach meinem Verständnis:
  • restartTestProgramForEachCore = 0 + disableCpuUtilizationCheck = 0
    • Sicherste Variante, weil Y-Cruncher Fenster offen bleibt und man händisch scrollen und nach Fehlern suchen kann
  • restartTestProgramForEachCore = 1 + disableCpuUtilizationCheck = 0
    • Fehler werden von Y-Cruncher an CoreCycler nicht übergeben, aber über Näherungsverfahren via CPU-Util-Berechnung angenommen und in CoreCycler gelistet
Richtig verstanden? Danke!
 
Wenn beide Settings auf 1 stehen, dann erhält man gar keine Rückmeldung bei einem Fehler, weil CoreCycler nichts erkennen kann und das Fenster von Y-Cruncher vermutlich bereits geschlossen und neu gestartet wurde.
Es sieht so aus, als wäre alles in Ordnung (es sei denn, man bemerkt zufällig den Fehler bei Y-Cruncher).

Wenn beides auf 0 steht (die Standardeinstellung), erkennt CoreCycler den Fehler beim getesteten Kern (meistens) und gibt eine entsprechende Meldung aus. Y-Cruncher wird dann ohnehin neu gestartet für den nächsten Kern, um mit dem Stresstest fortzufahren.

Bei restartTestProgramForEachCore = 1 + disableCpuUtilizationCheck = 0 passiert im Grunde das gleiche, nur dass Y-Cruncher immer neu gestartet wird bei einem Wechsel auf einen neuen Kern.

disableCpuUtilizationCheck sollte eigentlich nie auf 1 gesetzt werden, wenn man mit der Erkennung keine Probleme hat (auf overclock.net hab ich da grad so einen Fall, den ich untersuche).
 
  • Gefällt mir
Reaktionen: BreadPit
Mal ne Frage wenn ich ein Bios update machen möchte und es gibt jetzt nach der Version die momentan läuft noch 3-4 weitere kann ich da die letzte nehmen oder muss ich die nach und nach aufspielen?
 
sp00n.82 schrieb:
disableCpuUtilizationCheck sollte eigentlich nie auf 1 gesetzt werden, wenn man mit der Erkennung keine Probleme hat (auf overclock.net hab ich da grad so einen Fall, den ich untersuche).
Ah, und von dort hab ich die Beispiel-Konfig kopiert - das erklärt es vielleicht warum ich das auf 1 hatte ;)
Danke - sehr cooles Test-Proggi!

Aber ein wenig ernüchtert bin ich schon von den synthetischen Stabilitätstests. Es scheint nix zu geben, das wirklich auf Stabilität = "hau drauf was geht" testen kann?

Hier das Setting: 4600MHz AllCore Boost / BCLK 103,3750MHz / Offset -0,1250V + S3UV (auto-undervolt after S3)

Hier der Stabilitäts- / CO-Test, der über Nacht gelaufen ist:
16h CoreCycler Y-Cruncher N64, HNT, VST, C17 je 1min ohne Fehler:
Code:
 -06 -10 -08 -10 -08 -20 -10 -08 (~114X mV)

Hier die finalen? Settings, die zumindest 30min überstehen mit
CoreCycler Y-Cruncher HNT 30s + Overwatch 2 zocken:
Code:
-04 -04 -04 -04 -00 -14 -04 -00 (~116X mV)

Da sind ~6 CO Schritte = ~30mV = ~1% CPU-Z Score Unterschied! Wow. Ev liegt das ja bei mir am BCLK OC, ich denke aber das wird bei jedem im Grenzbereich ähnlich sein. Am Ende haben wohl sogar 80% von den Geeks (wie ich) eben doch keinen so "100% super-stabilen PC", wie die Stresstests uns glauben lassen. Eine gute Hilfe sind sie dennoch, und synthetischer Test kombiniert mit produktivem Gaming-Test sollte dann schon ne gute Absicherung gegen unerwünschte Abstürze sein. Hab ich ja mit Prime95 + Gaming auch immer gemacht früher, mit CoreCycler gehts nur effektiver. ("produktiver Gaming-Test liest sich schon merkwürdig ;))

@Bam_Bam_GER ich denke übrigens, dass bei mir der IMC sich mit den 2x 32GB DR plagt. Du hast 2x 16GB SR, das ist ja super easy. Deshalb reagiert Deine Kiste wohl anders auf die Tests.
 
  • Gefällt mir
Reaktionen: Bam_Bam_GER
BreadPit schrieb:
@Bam_Bam_GER ich denke übrigens, dass bei mir der IMC sich mit den 2x 32GB DR plagt. Du hast 2x 16GB SR, das ist ja super easy. Deshalb reagiert Deine Kiste wohl anders auf die Tests.
Vielleicht machts dann ja Sinn, dein Ram mal auf ein JEDEC oder XMP Setting zu stellen und dafür die Cores etwas "anzuheben"?
 
Also das Getriebe (IF + RAM) auf den dritten Gang limitieren, damit ich den Motor (Core) höher drehen kann? Na ich weiß nicht ;)

Läuft eh schon auf 4600 AllCore je nach Last (stock ist 4550), was recht ordentlich ist. Aber ich versuche nochmal weniger BLCK = weniger CPU & RAM Takt, und schau ob der effektive CPU Takt dadurch höher wird.

Ich denke nicht, dass das im Ergebnis viel Unterschied macht. Es könnte einfach erklären, warum HNT bei Dir keinerlei Probleme macht, bei den meisten hier aber schon - 2x 16GB DR ist "Quasi-Standard".
 
BreadPit schrieb:
Du hast ja festgestellt, dass mit restartTestProgramForEachCore = 0 sehr wohl die Fehler von Y-Cruncher zu CoreCycler übergeben werden, wenn man das Skript abbricht? Oder das eben nicht, sondern sie bleiben halt im Y-Cruncher Fenster sichtbar?
Sie bleiben im Ycruncher Fenster sichtbar. Schön das du immer noch weiter experimentierst.
 
  • Gefällt mir
Reaktionen: BreadPit
@Creekground danke, auch an @sp00n.82 für die Klarstellung. Jetzt ist das Bild komplett.

Liebe Leute, in aller Deutlichkeit ein "sorry" dass ich ein falsches Setting von irgendwo übernommen hatte. Das fällt nicht auf bei HNT Cycles, weil idR einfach der Rechner plötzlich neu startet - und da sieht man ja im Windows- + Y-Cruncher Log, welcher Core zuletzt dran war. Fällt auch kaum auf, wenn restartTestProgramForEachCore = 0 gesetzt ist, weil man hier einfach das Y-Cruncher Fenster nach Fehlern durchscrollen kann. Wie auch immer, hier jetzt die saubere, für mich finale Test-Konfig, mit der durch disableCpuUtilizationCheck = 0 auch im CoreCycler-Fenster die Fehler erkannt werden durch die "Auslastungs-Annäherung". Ev hilft es ja euch, schneller und einfacher zu einem Ergebnis zu kommen mit N64 / C17.

@MehlstaubtheCat @Creekground @fas7play

Code:
# General settings
[General]
stressTestProgram = YCRUNCHER
runtimePerCore = 256s
# runtimePerCore = 30s --> HNT only Quick Check Cycles
# runtimePerCore = 256s --> N64, HNT, VST, C17 Final Check overnight
delayBetweenCores = 5
# delayBetweenCores = 15 is dfault, 5 simply accelerates the test
disableCpuUtilizationCheck = 0
# disableCpuUtilizationCheck = 0 is default; 1=enabled does not allow error detection in Y-Cruncher . Y-Cruncher gives no feedback except for its Terminal-Ouptut. It has no log file, and does not allow access the terminal ouput. The only possibility for error detection is thru CPU utilization check calculation.
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
coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
# coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7
skipCoreOnError = 1
numberOfThreads = 2

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

@sp00n.82 noch was übersehen, oder kriegt es das "-CoreCycler-Dev-Gütesiegel"? ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Fas7play und Creekground
Falls sich jemand fragt, wieso ich da nicht locker lasse - andere rauchen zwischendurch und entspannen sich so, ich mach halt das :D

Und vor allem, jetzt bin ich noch geistig drin und will das ja auch für mich selber zu einem guten Ende bringen, damit ich beim nächsten Hardware-Upgrade ein gut dokumentiertes, einfaches und effektives Vorgehen habe, um zu einem optimierten, stabilen Setting zu kommen. Da ist die Lernkurve anfangs steil, dafür bleibts dann danach auf hohem Niveau ;)
 
Zuletzt bearbeitet:
Müsste jetzt mit entsprechender Meldung im CoreCycler laufen.
Im nächsten Release schiebe ich disableCpuUtilizationCheck denke ich in eine neue [Debug] Untersektion, um das nochmal deutlicher zu machen, dass man das in der Regel nicht umstellen sollte.

Man kann den Eintrag auch jetzt schon weglassen, dann wird der Standardwert aus der config.default.ini übernommen.
 
  • Gefällt mir
Reaktionen: BreadPit
Bam_Bam_GER schrieb:
Neue Config, neuer CPU-Kühler (von Arctic Freezer II 240 auf BeQuiet! Silent Loop 2 280 gewechselt):
Du hattest mich mit deinem upgrade leicht angefixt. Deshalb dachte ich, moment mal, ich hab ja noch ein paar Gutscheine von meinem Geburtstag rumliegen.
Hab mir dann auch mal die Silent Loop 2 240mm (280mm nicht möglich) B&W Edition besorgt. RGB Anschluss habe ich weg gelassen, da ich das sowieso nicht sehen kann. Hätte niemals gedacht, das der Impact so krass ist. Ich bin gerade ganz leicht begeistert. :D
Natürlich nach eigener Vorstellung eingebaut und gemerkt das es nicht viel besser, bzw. die Pumpe sich etwas komisch anhört. Ich hatte ja bisher nur Luftkühler und gedacht das man die WK einfach einbauen kann und fertig. Falsch gedacht. Nochmal im Internet etwas schlau gemacht. Der Radiator ist in der Seitenwand befestigt. Die Lüfter habe ich von out take auf in take gedreht. Siehe da, ein Unterschied wie Sonnenaufgang zu Sonnenuntergang. Spiele gerade noch an den Bioseinstellungen rum. Aktuell Pumpe auf Silent Mode und DC Mode.
Das coole ist, das die framespikes mehr oder weniger weg sind:

MEEE_Vergleich_WK_3533vs3200.png

linepack_3534_wk2.png

aida_wk_3533.png

Oder liegt das an HAGS?

Ich denke der große Luftkühler hat für einen Temperaturstau bei den VRM´s und RAM-Riegel gesorgt. Jetzt hab ich ca. 45°C beim zocken.:o

BTW. Process Lasso hat ein neues Beta veröfentlich. Da lässt sich die System Timer Resolution einstellen. Diese wird auch nach einem PC Neustart wieder eingestellt. Hab keine Ahnung ob das was bringt?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bam_Bam_GER
Also Linpack X lass ich mal weg zum Benchen.

Selbst der Powerplan hat Auswirkungen auf die vermeintliche "Performance"..

Windows Balanced
1683800060539.jpeg


Mein eigener den ich gerade am testen bin..
ZT Spielt auch mal wieder verrückt... sind weiterhin die 4000MHz bzw 2000MHz Sync, nicht wie angezeigt 3977MHz (BCLK OC ist auch nicht vorhanden).

1683800040623.png


Dabei hab ich das Programm nicht mal neu gestartet, sondern einfach den Powerplan geändert...
Hauptsache die Games laufen wie sie sollen... Rest ist mir nun egal (und wenn ich drölfzig millionen CB Punkte bekomme, ich zocke und da muss die Leistung her)!
 
  • Gefällt mir
Reaktionen: Bam_Bam_GER, Guphoff, Creekground und eine weitere Person
Verangry schrieb:
Selbst der Powerplan hat Auswirkungen auf die vermeintliche "Performance"..
Richtig. Wollte nur mal den Unterschied WK vs. LK. darstellen. Ich nutze ja immer den gleichen Powerplan.

Im Metrobench sieht man den Unterschied besser.

Wie sieht den dein eigener Powerplan aus? Geht er in Richtung Höchstleistung oder Ausbalanciert bzw Ryzen 7000HP?
Ich finde das die Höchstleistung, Ultimative und Bitsum High Power nicht so gut sind als Ausbalanciert und 7000HP.

Noch eine Frage. Gibt es die Möglichkeit die Bioseinstellungen als z.B. TXT Datei zu speichern, oder muss ich alles über Screenshots machen?
 
Zurück
Oben