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

[MehlstaubtheCat]

Ne, sorry!
Hmm, warum denn gerade diese Settings?

 

[Creekground]

Bei mir wird nach dem Aufwachen eine Aufgabe ausgeführt, den CO Wert (-30) um 10 (-20) zu verändern um wieder auf die gleiche Spannung bei den Kernen zu kommen.

Nutzt du nur den PBO2Tuner, oder stellst du auch Werte im Bios ein?

 

[SeniorY]

Hmm, warum denn gerade diese Settings?

CPU Limit

 

[ColdGlow]

TPU meint 18475 / 1817 daher grats an @ColdGlow

eyyyyyy ich komme gerade ausm Urlaub zurück und denke nach... und nach.... "warte was meinen die gerade....." und dann machte es Klick

Das ihr die Einschätzungen von uns noch auf dem Schirm hattet ne, boa krass DD die hatte ich ja mal so ganzzzz vergessen @fas7play & @MehlstaubtheCat

 

[SyntaX]

Nutzt du nur den PBO2Tuner, oder stellst du auch Werte im Bios ein?

per BIOS, PBO2Tuner nur für diese Aufgabe.

 

[Creekground]

PBO2Tuner nur für diese Aufgabe.

Ich möchte das gerne mal testen. Hast du zufällig einen Screenshot der Aufgabe für mich?

 

[SyntaX]

Eine Anleitung gibt es hier.
Musste es nur beim Trigger anders einstellen:

 

[BreadPit]

Die Danksagungen gehen weiter: @SeniorY @fas7play danke für euren Tip zur CO Auslotung (VID / alles am schlechtesten orientieren), und danke @MehlstaubtheCat für den Hinweis mit Excel. Hab jetzt binnen eines Osterabends meine CO für BCLK 102,25 = +100MHz ausgelotet. Eigentlich gar ned so schwer find ich. Ich versuch mal kurz für Experten in 3 Punkten:

• Wenn S3 = Sleep verwendet wird, unbedingt vor dem Testen den Rechner in S3 und aufwecken!
• CO = 0 mit PBO2Tuner, CoreCycler mit 30s HNT (Config unten), VIDs per Core via PBO2Tuner Monitor auslesen
• 2 schlechteste Kerne (= höchste VID) mit CoreCycler austesten, als Basis-VID für alle anderen Cores
• CO für alle Cores auf diese Basis-VID setzen, Schritt für Schritt CO absenken und mit CoreCycler austesten, im Y-Cruncher Log schauen welcher Core abgeschmiert ist --> CO wieder erhöhen.

Und nun die ausführliche Variante

• Tools
  • CoreCycler -> Y-Cruncher HNT 30s Config (s.u.)
  • PBO2Tuner Monitor um für jeden Core die VID zu erfassen, also nacheinander notieren.
    • PBO2Tuner VID Monitoring geht in der neuesten Beta geht auch, und empfehle ich auch.
    • Mit PBO2Tuner kann man auch bequem die CO während der Tests umstellen
    • Pro-Tip: Autostart via Windows Task nach Boot und nach S3.
• Weiteres Vorgehen & Interpretation
  • Wenn S3 = Sleep verwendet wird, unbedingt vor dem Testen den Rechner in S3 und aufwecken! Nachher sind alle VID ca 37mV niedriger, dh man schöpft das volle UV-Potential aus. Auch bekannt als S3 Bug, oder ich es es gern nenne S3UV.
  • VID erfassen: CPPC im BIOS einschalten, in Windows mit PBO2Tuner alle CO auf 0 setzen
    • CoreCycler Y-Cruncher HNT 32s QuickCheck (s.u.) anwerfen
    • VID per Core aus PBO2Tuner Monitor notieren ( Voltage / CPU_TELEM )
    • Zuerst die schlechtesten Cores = die mit höchster # in Klammer in HWinfo64
    • Dann die besten Cores = niedrigste # in HWInfo64. Für Neugierige optional:
      • die besten Cores einmal mit CO 0, dann mit CO -30 testen, VID notieren. Die Differenz durch 30 dividieren = 1 CO Schritt in mV
    • Rückblick: VID war nicht entscheidend, verkürzt den Prozess aber etwas und ist aufschlussreich. Hat vor allem die Erkenntnis gebracht, dass AMD die Güte der Cores offenbar nicht besonders granular auslotet. Die krassesten Unterschiede sind #5 = #0 (best) in Wahrheit, #7 = #4, #2 = #5, #1 = #3. "Best" bedeutet niedrigste VID nötig.
  • CoreCycler Test für Baseline = die zwei 2 schlechtesten Cores: Zunächst mit den 2 schlechtesten Kernen als Basis, beginnend mit zB CO -15
    • CoreCycler mit folgender Config anwerfen - die liefert bei mir am schnellsten und zuverlässigsten Reboots & Fehler:

      • [General]
        # General settings
        stressTestProgram = YCRUNCHER_OLD
        numberOfThreads = 2
        
        stopOnError = 0
        skipCoreOnError = 1
        beepOnError = 1
        flashOnError = 1
        lookForWheaErrors = 1
        
        coreTestOrder = sequential
        runtimePerCore = auto
        #                                                        # runtimePerCore auto executes all the tests listed in the stressTestProgramgram section with the defined testDuration
        suspendPeriodically = 1
        #                                                        # Periodically suspend the stress test program to simulate load changes / switches to idle and back
        restartTestProgramForEachCore = 0
        #                                                        # restartTestProgramForEachCore 0 is default, and leaves the stressTestProgramgram window open so you can scroll thru to double-check for errors
        delayBetweenCores = 5
        #                                                        # delayBetweenCores 15 is default, 5 simply accelerates the test. If "restartTestProgramForEachCore" is 0, this setting has no effect
        
        [yCruncher]
        # y-Cruncher specific settings
        mode = 19-ZN2 ~ Kagari
        tests = N64, HNT, VST, C17
        # testDuration = 30                                        # 30 to do a quick check only, 60 is default
        # 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 "could not find the correct stress test window"
        
        [AutomaticTestMode]
        # enableAutomaticAdjustment = 1
        # startValues = -25       # Set all cores to Curve Optimizer value of  -25 on startup
        # maxValue = 0            # Do not go above Curve Optimizer value of 0
        # incrementBy = 1         # Adjust the Curve Optimizer value by 1 after an error
        
        # Try to automatically resume after a crash / hard reboot
        # For this to work properly, Auto Logon should be activated
        # Otherwise the computer will just idle at the logon screen after a crash
        # enableResumeAfterUnexpectedExit = 1

    • Läuft ohne Fehler? Mit PBO2Tuner CO für die beiden Kerne -2 / erhöhen
    • Fehler? Mit PBO2Tuner CO +2 / senken für den Kern mit Fehler im Y-Cruncher Log
    • Und wieder von vorn
  • CoreCycler Baseline für alle anderen Cores: hier kommt dann das Excel ins Spiel
    • Dieser Schritt ist nicht unbedingt notwendig, aber verkürzt den Prozess. Warum? Es stellt sich bei mir heraus (und bei etlichen anderen offenbar auch), dass alle Kerne (außer die 2 schlechtesten) etwa gleich viel effektive Spannung brauchen, also zB ~1120mV bei 4450MHz. AMD setzt aber die VID recht "wild", siehe mein VID Rückblick oben. Da haben dann Kerne, die eigentlich gut sind, eine viel zu hohe VID, und Kerne die schlecht sind eine recht niedrige. Mit dieser Baseline sind wir einfach mit hoher Wahrscheinlichkeit näher am Ergebnis.
    • Wir erinnern uns: es gibt 30 CO Schritte, jeder davon hat ~3,9mV (siehe VID Sektion).
    • Wir nehmen also die schlechtesten 2 Kerne als Basis, und messen, oder einfacher rechnen aus, wie viel Spannung die bekommen. VID bei CO 0 + CO offset, das wir eben ausgelotet haben = effektive Spannung.
    • Auf diese Spannung rechnen wir nun die anderen Kerne hin; also wir nehmen deren VID, die Ziel-VID der beiden schlechtesten Kerne, und "füllen" die Differenz mit CO, heisst: wie dividieren die Differenz zu 3,90 und wissen dann, wie viele CO Schritte wir brauchen um auf dieselbe VID zu kommen. Ich gebe zu, der Teil liest sich wohl nicht so intuitiv, ev hilft ein Excel Screenshot ja
  • CoreCycler kompletter Test
    • Nun haben wir eine solide rechnerische Baseline, und von der ausgehend lassen wir CoreCycler auf allen Kernen durchlaufen. Bei Fehler oder Reset können wir um CoreCycler Y-Cruncher Log nachlesen welcher Kern abgeschmiert ist, und senken den negativen CO Offset entsprechend. Kein Fehler? CO Offset erhöhen bis ein Fehler auftritt
    • Nicht vergessen im CoreCycler Config-File mit den Kernen beginnen, die noch nicht getestet wurden, um Zeit zu sparen, bis keine Fehler mehr auftreten --> fertig.
    • Am Schluss dann den "Full Final Check" machen, also N64, HNT, VST, C17 mit 256s Dauer.

Generell plädiere ich dafür, nur noch in absoluten Spannungen = VID zu kommunizieren. Die CO Werte sind relativ zu einer ja nach Hersteller unterschiedlichen VID-Baseline, dadurch ist das alles nicht vergleichbar. VID Werte sind 1:1 vergleichbar, daher imho viel nützlicher um schnell zu soliden Referenzwerten zu kommen - macht leider fast niemand, alle unterhalten sich in CO statt in VID.

Hoffe das hilft! Ich habe mit diesem brutalen Test festgestellt, dass ich weit weniger CO fahren kann als ich für stabil hielt Aber für +100MHz ) 4650 / 4550 bei DDR 3750 schon OK denk ich.

Natürlich kann und sollte man dann noch ausführlicher / länger testen. Beim 5. Durchlauf zB ist mir jetzt Kern 6 doch wieder abgeschmiert. Aber dieser Test findet in sehr kurzer Zeit die wesentlichen Schrauben.

So sieht das Excel aus, ev hilft ja die Visualisierung zum Verständnis:

 

[Creekground]

@BreadPit Respekt für die Anleitung. Danke. Deswegen denke ich das bei einigen die einfach -30 einstellen das ganze nicht 100% stabil ist. Es boosten auch die schlechteren Kerne über 4450MHz.

 

[MehlstaubtheCat]

Ja das der Fall @Creekground!

-30 ist zu allgemein, wird aber oft für Gamestabil ausreichen.
Wenn es aber wirklich "Stabil" sein sollte, muss man schon die Kerne einzeln einstellen.

Da ich ja Garantie auf das ganze geben muss.

Durchläuft jeder Rechner den ich baue, Y-Cruncher mit N64 für 12h+
und TM5 und Karhu ebenso je 12h+.
Ist viel Arbeit aber, ich kann halt schlecht Rechner auf meine kosten wieder zu mir zurück schicken lassen,
oder das ich zu dem Rechner hin fahre.

Ich hab es bis heute immer erreicht,
das keine Hardware, für den Kunden durch mich "Ums Leben gekommen ist"! 😁
Wo ist das Holz, Holz? Hier ist Holz, klopft klopf! 😉

Ich sag nur Kunde und Katze, ist ne schlechte Kombi! 🐈

 

[BreadPit]

Bin ich bei Dir. Würd ich an Deiner Stelle genau so machen, ist einfach ein Riesen-Unterschied ob ich als "verrückter Professor" an meinem eigenen Rechner, aus schierer Neugier und Experimentierfreude, mich auf die Suche nach dem Limit mache, oder ob ich etwas ausliefern muss, das einfach funktioniert. An jemanden, der sich mangels Expertenwissen nicht so zu helfen weiß.

Und wie immer "liegt die Wahrheit dazwischen". Der Y-Cruncher Test, den ich hier fahre ist, ist offenbar gaaanz weit weg von "ausreichend game- und anwendungsstabil". Da liegen CO -20 Abstand zwischen Y-Cruncher SingleCore HNT und stundenlang Witcher 3 NextGen zocken mit Prime95 LargeFFT AllCore im Hintergrund.

Spannend finde ich, dass ich dem N64 so "entgegengezittert" habe weil viele von dem schreiben - aber der lief immer ganz easy durch. Meine CPU wird durch HNT / C17 / HNT / C17 so brutal eines Besseren belehrt, dass ich kaum Errors kenne, sondern fast nur "sudden reboots".

Ergänzung (10. April 2023)

Ergänze / verfeinere: da liegen CO -20 Abstand zwischen Y-Cruncher SingleCore HNT und stundenlang Witcher 3 NextGen zocken mit Prime95 LargeFFT AllCore im Hintergrund.

Das unterstreicht ja auch meine Theorie, dass eben nur Core 1+2 SingleCore Boost-stabil sein müssen, und der Rest auf 100MHz weniger getrimmt gehört weil für die nur MC Boost angewendet wird. Aber da gibt´s zu unterschiedliche Definitionen von "100% stabil"...

Ich würde es wirklich interessant finden, wenn ihr mal meine Y-Cruncher Testvariante ausprobiert. Bin gespannt wer dann doch nicht stabil ist mit seinen 15xxx Punkten - ich bin nach diesen Tests stabil, aber mit deutlich weniger Boost weil höhere VID...

 

[4BitDitherBayer]

Hat vor allem die Erkenntnis gebracht, dass AMD die Güte der Cores offenbar nicht besonders granular auslotet. Die krassesten Unterschiede sind #5 = #0 (best) in Wahrheit, #7 = #4, #2 = #5, #1 = #3. "Best" bedeutet niedrigste VID nötig.

An was erinnert mich das hmm . . . ach ja an meinen Beitrag vom 31. Januar 2023

Wie man auf den Bildern deutlich erkennt scheint die Kern-Priorisierung nicht sonderlich gut zu funktionieren.
Sollte es nicht so sein das die Kerne, die dem Max-Boost mit der geringsten Spannung erreichen die "Best Cores" sind ?

Bei mir wären das Core 1 & Core 0
Laut HWiNFO stimmt das bei Core 1 überein Core 0 sollte aber eigentlich nur Nr. 4 sein.
Schlimmer noch Core 7 der eigentlich der Zweit beste sein sollte ist richtig . . richtig schlecht er taktet zwar mit wenig Spannung weit hoch schmiert aber auch super schnell dabei ab. ich musste in auf -26 korrigieren um ihn zu stabilisieren. Damit Liegt er nur noch auf Platz 4 bei den Spannungen also genau da wo eigentlich Core 0 liegen sollte. Man könnte daraus Schlussfolgern das bei der Kern-Priorisierung Core 0 u. Core 7 vertauscht wurden. Die beiden anderen Kerne die ich noch Stabilisiert habe ergeben wieder sin Core 4 & Core 6 sind in der Kern-Priorisierung auf den beiden Letzten Plätzen also alles ok.
Was noch auffällt ist das der Hintere Teil des Siliciums der schlechtere zu sein scheint alle kerne die ich stabilisieren musste liegen dort.

Darum Freunde solltet ihr auch wirklich einstellen.

CPPC - ON
CPPC Preferred Cores - On

Bei mir hat das dafür gesorgt das mein Kern 7 der ja gerne mal abgeschmiert ist nicht mehr so häufig genutzt wurde der hat quasi mit Kern 3 Plätze getauscht.

kleiner Ansatz bevor man gleich mit dem Y-Cruncher mit N64 los legt weil das doch recht lange dauert.
Lasst die Kiste erst mal den AIDA64 (CPU-SHA3) u. den (FPU-Mandel) so 5 bis 10 mal hintereinander Durchstehen. Die Test dauern nur ca. 15 sec. sollte der Rechner die überstehen ist er schon mal Game fest.

Danach kann man dann zum Feinschliff übergehen mit Y-Cruncher mit N64.
Mir dieser Methode kann man sich einen Haufen Zeit ersparen

 

[Creekground]

Muss ich mir mal in Ruhe reinziehen. Wie sind deine CO Werte mit BLK 100? Oder ich übersehe diese.

 

[BreadPit]

Wenn ich gemeint bin: hab ich noch gar nicht ausgelotet, direkt mit 102,25 = 4650 Boost gestartet. Mein Plan ist, einfach eine "Parallelverschiebung" hinunter zu machen 😂

Ergänzung (10. April 2023)

@4BitDitherBayer das mag sein, meine Aussage war nur eben dass N64 (so lang braucht der auch nicht?) meine Kiste nicht wirklich fordert vs HNT und C17 (die einzigen "mixed" Tests).

 

[P4-Freak]

Geht nicht mehr als 102 bclk?

 

[Creekground]

@BreadPit ja, ich hatte dich gemeint. WO hast du die neuste PBO2Tuner Version gefunden? Hast du den Link bitte.
Am Anfang nach dem wir das mit dem Sleepbug gecheckt hatten, hatten @fas7play und ich versucht die CO Werte gleich auf die nach Sleepbug V einzustellen. Wenn ich mich nicht irre. Sleepbug zu normal sind zwischen 30mV und 40mV.

 

[BreadPit]

@Creekground ich weiß dass PBO2Tuner Versionen schwer zu finden sind - deshalb hab ich´s ja extra oben verlinkt Ich achte immer drauf zu bieten, was ich mir wünschen würde als Leser

@P4-Freak Doch, aber nur mit deutlich mehr vSOC / IOD / CCD und dennoch WHEA 19.
Und ich hab bei 102,25 schon einen Core der +2 braucht. Find die Reise spannend, aber Leistung wird am Ende womöglich bei BCLK 100 mit mehr CO-Offset besser sein kann ich mir vorstellen.

 

[P4-Freak]

Okay na dann bin ich schon fast froh dass mein PC eh nicht mit bclk oc geht

 

[ColdGlow]

Iwo stand doch beim overclock.net 5800X3D Owner Thread das es wohl am meisten Sinn macht, die BCLK einfach auf 101,5 zu belassen, halt 45,5 x 101,5 = max. ~4618 und das gilt eher als stabil, weil einige NVMEs oder SSDs wohl mit höherem BCLK schneller kaputt gehen, iwo stand da was dazu, hab ich aber leider nicht in meinen Bookmarks Oder irre ich mich da?

 

[MehlstaubtheCat]

Ich bezweifle sehr stark, das NVMEs durch das BLCK OC, früher,
oder generell sich öfter verabschieden, als bei "normaler" Anwendung!

Die 1-2% oder lass es 4% mehr Takt auf dem Bus,
ist alles noch vom NVME Hersteller mit "eingeplant" oder "Toleranz".

Ich habe 32 Systeme mit einem Intel Core i5-11400F gebaut.
Alle davon werden mit 102,9MHz betrieben,
da Intel ab 103MHz das System aktiv sperrt,
damit man nicht zu viel Leistung generieren kann.
Der Speicher läuft dann mit rund 3700MHz Gear 1.

Nicht ein System das ich gebaut habe, ist bisher defekt oder hat Anzeichen davon.
Manche davon haben zwei NVMEs verbaut.

Und die 11te Gen von Intel war nicht das gelbe vom Ei wie wir alle wissen.

Es wird viel zu viel schlecht geredet, über BCLK-OC etc,
was am Ende einfach nur ausprobieren ist wie PBO, oder RAM-OC auch.
Mann kann auch bei BCLK-OC herausfinden ob es sauber läuft,
durch testen wie bei PBO oder RAM-OC auch.
Da ist nichts gefährlicher als andere OC "Dinge", das totaler Blödsinn!
RAM-OC kann genau so, wenn man nicht aufpasst, das Betriebssystem zerstören,
wie BCLK-OC auch, da ist kein Unterschied.

Ich bin mir jeder Sekunde der "Gefahr" aktiv bewusst
und bin bei OC etc immer mit vollem Hirn dabei.

Bei allem was man außerhalb der vom Hersteller gesetzten Speccs betreibt,
muss man vorsichtig sein und man darf sich nicht wundern wenn was kaputt geht.

Wenn man das von Anfang an scheut,
muss man eben alles auf Standard laufen lassen
und damit glücklich werden,
ich könnte sowas aber unter keinen Umständen,
ich habe die Sucht in mir, alles besser machen zu wollen,
mein innerer Monk möchte das so!

Schönen Abend!