Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
[Work-Log] Aufrüsten auf einen 5800X3D! Was ist an Leistung möglich!
- Ersteller MehlstaubtheCat
- Erstellt am
Achso egal hier ein ausführlicher aktueller Test. spiele eh in 4k da bringt ein bisschen mehr Takt bestimmt eh nichts.
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personenbezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
Ü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
Jetzt festgestellt:
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
Creekground
Lt. Commander
- Registriert
- Feb. 2019
- Beiträge
- 1.682
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
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?
Ach ja, und noch ne Erkenntnis:
Next Level Stabilitätstest Ev hab ich auch noch nicht bei BCLK 103,375 gezockt und das stürzt immer ab, denke aber nicht - halte euch am Laufenden!
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 🙈
Next Level Stabilitätstest 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:
- Registriert
- Dez. 2020
- Beiträge
- 342
Also Y-Cruncher übergibt leider gar nichts an CoreCycler, von daher ist
Falls jemand eine Ahnung hat, wie man die Ausgabe des Y-Cruncher-Terminals abgreifen kann, wenn sowas wie
Wenn sowohl
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.
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.
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
Bei
Also folgende Varianten gehen nach meinem Verständnis:
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
- Registriert
- Dez. 2020
- Beiträge
- 342
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
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).- Registriert
- Sep. 2013
- Beiträge
- 5.810
Ja, da geht die letzte!
Wäre ja Blöd wenn nicht, das zahlt mir kein Kunde!
Wäre ja Blöd wenn nicht, das zahlt mir kein Kunde!
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
Ah, und von dort hab ich die Beispiel-Konfig kopiert - das erklärt es vielleicht warum ich das auf 1 hattesp00n.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).
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.
Bam_Bam_GER
Ensign
- Registriert
- Jan. 2023
- Beiträge
- 177
Vielleicht machts dann ja Sinn, dein Ram mal auf ein JEDEC oder XMP Setting zu stellen und dafür die Cores etwas "anzuheben"?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.
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
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".
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".
Creekground
Lt. Commander
- Registriert
- Feb. 2019
- Beiträge
- 1.682
Sie bleiben im Ycruncher Fenster sichtbar. Schön das du immer noch weiter experimentierst.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?
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
@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
@sp00n.82 noch was übersehen, oder kriegt es das "-CoreCycler-Dev-Gütesiegel"?
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:
BreadPit
Lieutenant
- Registriert
- Apr. 2006
- Beiträge
- 603
Falls sich jemand fragt, wieso ich da nicht locker lasse - andere rauchen zwischendurch und entspannen sich so, ich mach halt das
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
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:
- Registriert
- Dez. 2020
- Beiträge
- 342
Müsste jetzt mit entsprechender Meldung im CoreCycler laufen.
Im nächsten Release schiebe ich
Man kann den Eintrag auch jetzt schon weglassen, dann wird der Standardwert aus der config.default.ini übernommen.
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.
Creekground
Lt. Commander
- Registriert
- Feb. 2019
- Beiträge
- 1.682
Du hattest mich mit deinem upgrade leicht angefixt. Deshalb dachte ich, moment mal, ich hab ja noch ein paar Gutscheine von meinem Geburtstag rumliegen.Bam_Bam_GER schrieb:Neue Config, neuer CPU-Kühler (von Arctic Freezer II 240 auf BeQuiet! Silent Loop 2 280 gewechselt):
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.
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:
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.
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:
- Registriert
- März 2019
- Beiträge
- 2.172
Also Linpack X lass ich mal weg zum Benchen.
Selbst der Powerplan hat Auswirkungen auf die vermeintliche "Performance"..
Windows Balanced
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).
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)!
Selbst der Powerplan hat Auswirkungen auf die vermeintliche "Performance"..
Windows Balanced
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).
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)!
Creekground
Lt. Commander
- Registriert
- Feb. 2019
- Beiträge
- 1.682
Richtig. Wollte nur mal den Unterschied WK vs. LK. darstellen. Ich nutze ja immer den gleichen Powerplan.Verangry schrieb:Selbst der Powerplan hat Auswirkungen auf die vermeintliche "Performance"..
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?