Sammelthread AMD Ryzen

Sammelthread
BCLK einfach so hoch, bis es instabil wird. Natürlich erst danach die Curve tunen. Es wäre natürlich super, wenn du im Vorfeld wüsstest, was deine "besten" und "schlechtesten" Kerne verkraften. Der eine kann -30 ab, der andere braucht +5 usw.
Schon 1 MHz Unterschied kann das jedoch verändern. Beim Büro-7800X3D konnte ich -22 oder -23 fahren (müsste ich noch mal nachschauen) bei 103 MHz BCLK. Also da geht schon was.
 
Das hat eben Einfluss darauf. Du kannst die Curve ja auch ins Positive ziehen und damit den BCLK weiter in die Höhe treiben. ;-)
Ich denke aber, dass es da auch so eine Art "Sweetspot" geben wird, weil wenn man mit dem BCLK zu hoch geht, sodass man deutlich mehr Spannung benötigt, dann kommt man ja erstens schneller ins Temperaturlimit und zweitens klaut man der CPU noch mehr Headroom zum Boosten (das ist ja mit RAM-OC bei 6400 MT/s und der höheren VSoC eh schon gegeben).

Buildzoid sagt auch in diesem Video hier, dass dann noch andere Problematiken mit hinzukommen, wie beispielsweise, dass bei ST-Lasten oder generell niedrigeren Lasten Instabilitäten auftreten, die bei Volllast gar nicht zum Vorschein kommen (z.B. Geekbench). Auch muss man dann wohl mit dem "Boost Clock Override (−) rumspielen.
Video

Ich strebe irgendwas zwischen 103-105 MHz BCLK an. Das wäre ja schon fein.
 
Der Boost Clock Override hat bei mir noch nie funktioniert, mit dem 7800X3D. Schau einfach, dass du nicht direkt mit 106 MHz oder so einsteigst. Mit 103 MHz solltest du Erfolge haben und kannst auch die Curve tunen. Alles andere ist Glückssache. Den Aufwand habe ich mir bei meinem übrigens gespart, weil ich keinen eCLK habe.
 
Ja, das war der Plan, so bei 103 MHz anzufangen. :)

Bei mir funktioniert der Boost Clock Override, habe ich schon getestet.

eCLK-Boards scheint es auch gar nicht so viel zu geben. Ich habe richtig Glück gehabt, dass ich bei meinem "günstigen" Board einen dabei habe. Ich habe mich darüber im Vorfeld nämlich gar nicht informiert.
 
Das meine ich:
Aber ich habe damit, wie gesagt, keine guten Erfahrungen gemacht. Volle Lotte Prime und dann Kern für Kern.
Hattest du die Configs manuell umgeschrieben damit auch wirklich alle FFT Größen in SSE und AVX(2) Durchlaufen?
Denn 99% aller CC unzufriedenen Nutzer haben genau das nicht getan. Serienmäßig laufen da nur ne ganz kleine Auswahl an FFT Größen in einem Befehlssatz. Das kann man natürlich komplett knicken
So langsam nimmt das alles Form an. Dabei war per CO noch folgendes eingestellt:
-30 -30 -30 -30 -30 -30 -30 -30 -10 -40 -40 -40 -40 -40 -40 -20
Das sieht aber nicht nach ordentlichem per Core CO aus ^^
Bei mir ist es -7 -28 -16 -13 -30 -30 -20 -25 -27 -26 -28 -24
Und wie macht man das dann beim "Per Core" UV? Fängt man beim ersten Core an und arbeitet sich nach unten bis es in y-Cruncher crasht oder zieht man alle Kerne gleichzeitig immer um einen Wert nach unten bis es crasht?
Pauschal beim x3D einfach mal alle kerne auf -15 setzen, testen, dann -20, testen, usw.
CoreCycler wirft dir bei Fehlern den Kern aus der Probleme verursacht.
Den entsprechenden Kern dann um 2 hochsetzen, mit dem rest wieder 5 tiefer
 
Bei mir funktioniert der Boost Clock Override, habe ich schon getestet.
Boost Clock Override sollte bei x3Ds nicht funktionieren.
Wenn du dort 200Mhz einträgst muss dein x3D dann auf 5250Mhz statt 5050Mhz takten. Und das dürfte er eigentlich nicht tun.

Also 45min per Core bei SSE, 70min bei AVX und 90min bei AVX2 und das ganze nochmal mit SMT enabled und der doppelten Zeit? Also sprich 48std CC laufen lassen (1 Iteration!) alleine für AVX2+SMT bei 4k FFT bis 512k FFT?
 
Also 45min per Core bei SSE, 70min bei AVX und 90min bei AVX2 und das ganze nochmal mit SMT enabled und der doppelten Zeit? Also sprich 48std CC laufen lassen (1 Iteration!) für AVX2+SMT?
Puuh, so genau weiß ich das nicht mehr, das ist mittlerweile 10 Monate her :D
Ich meine aber dass der Anfangs zum ausloten nur kurz lief, aber nachdem ich dann mit Allcore Last verlässlichere Ergebnisse bekommen habe bin ich darauf umgestiegen.

Am Ende habe ich aber auch nur eine Sample Size von 1. Das sind einfach nur meine Erfahrungen ^^
 
Boost Clock Override sollte bei x3Ds nicht funktionieren.
Wenn du dort 200Mhz einträgst muss dein x3D dann auf 5250Mhz statt 5050Mhz takten. Und das dürfte er eigentlich nicht tun.
Genau meine Erfahrung. Zumindest nach "oben". Wie es nach "unten" aussieht, habe ich nie getestet. War beim 5800X3D auch schon so, liegt also nicht an Zen 4 direkt, sondern am fehlenden offenen Multiplikator, denke ich.
 
@Dr1val es gibt übrigens eine Curve Optimizer Anleitung von @Darkearth27
Kannst du im Discord unter "Anleitungen" finden ^^
Steht zwar Ryzen5000 dabei, aber funktioniert bei Zen4 genauso

Puuh, so genau weiß ich das nicht mehr, das ist mittlerweile 10 Monate her :D
Ich meine aber dass der Anfangs zum ausloten nur kurz lief, aber nachdem ich dann mit Allcore Last verlässlichere Ergebnisse bekommen habe bin ich darauf umgestiegen.
Genau, wie du sagst, der läuft serienmäßig eben nur kurz und nicht so lange. Dass der dann eben nicht die Fehler findet, liegt auf der Hand-

Am Ende habe ich aber auch nur eine Sample Size von 1. Das sind einfach nur meine Erfahrungen ^^
Meine selbst umgeschriebenen Configs haben mittlerweile dutzende Leute genutzt, keiner hatte sich bisher beschwert, dass es danach noch instabil gewesen wäre. Daher vermute ich eben, dass der falsch bedient wurde. Ist aber auch blöd gemacht, da gibts keine vernünftige Anleitung und wenn einem das niemand sagt, dann sind die standarteinstellungen halt total sinnlos. Selbst wenn du die runtime per core massiv erhöhst, durchläuft er nicht alle FFT größen, da es bei wenigen FFT größen gecappt ist. Dann läuft er halt von 16K bis 52k einfach ein paar mal bei erhöhter runtime per core anstatt von 4k bis 512k wie es eigentlich sein sollte.


Genau meine Erfahrung. Zumindest nach "oben". Wie es nach "unten" aussieht, habe ich nie getestet. War beim 5800X3D auch schon so, liegt also nicht an Zen 4 direkt, sondern am fehlenden offenen Multiplikator, denke ich.
Jup, geht beim 5800x3D auch nicht, das hat AMD gesperrt.
"Nach unten" weiß ich tatsächlich auch nicht, hatte bisher keinen x3D :heul:
 
OCCT findet schnell Fehler, wenn man es mit dem CO übertreibt. Das ist gut geeignet, wenn man z.B mit -30 all Core anfängt. Den OCCT CPU Test (Large - Extreme - variable - AUTO (AVX2)extreme) laufen lassen und dann hagelt es recht schnell WHEAs. In der Ereignisanzeige den entsprechenden Core (ApicID) herausfinden und dann in 5er Schritten den Core anpassen.

Im BIOS auch checken, ob das Pcie Advanced Error Reporting enabled ist (sonst werden eventuell keine Wheas geloogt).

Wenn man damit durch ist, kann man dem CC weitermachen. Ich verlinke mal einen Beitrag, der auf zwei gute Configs dafür liefert.


Mit eCLK macht man wieder ein ganz neues Fass auf :)
Zum Spaß an der Freude ist das schon ok aber das gut einzustellen ist schon sehr aufwendig.

Viel Spaß beim ausloten :)
 
Genau, wie du sagst, der läuft serienmäßig eben nur kurz und nicht so lange. Dass der dann eben nicht die Fehler findet, liegt auf der Hand-
Meine selbst umgeschriebenen Configs haben mittlerweile dutzende Leute genutzt, keiner hatte sich bisher beschwert, dass es danach noch instabil gewesen wäre. Daher vermute ich eben, dass der falsch bedient wurde. Ist aber auch blöd gemacht, da gibts keine vernünftige Anleitung und wenn einem das niemand sagt, dann sind die standarteinstellungen halt total sinnlos. Selbst wenn du die runtime per core massiv erhöhst, durchläuft er nicht alle FFT größen, da es bei wenigen FFT größen gecappt ist. Dann läuft er halt von 16K bis 52k einfach ein paar mal bei erhöhter runtime per core anstatt von 4k bis 512k wie es eigentlich sein sollte.
Das kann sehr gut sein. So extrem lange lief der bei mir auf jeden Fall nie. Ich habe das über Nacht und den Arbeitstag laufen lassen. Also maximal 24h. In der Zeit gab es keinen Fehler und bei Prime95 Allcore Last ist er dann instant abgeschmiert ^^

Vllt war es auch nur ein dummer Zufall, wer weiß.
 
hatte bisher keinen x3D :heul:
1705915891661.png
 
Pauschal beim x3D einfach mal alle kerne auf -15 setzen, testen, dann -20, testen, usw.
CoreCycler wirft dir bei Fehlern den Kern aus der Probleme verursacht.
Den entsprechenden Kern dann um 2 hochsetzen, mit dem rest wieder 5 tiefer
Ich habe jetzt meinen BCLK auf 104 MHz gestellt (105 MHz bootet nicht) und fange mit -5 auf allen Kernen an (wegen BCLK-Erhöhung).

Ich habe in 5er Schritten getestet, alles andere war mir zu blöd bei 16 Kernen.
Das ist verständlich. Da hätte ich auch keinen Bock drauf. Bei 8 Kernen ist das ja doch überschaubarer.

Boost Clock Override sollte bei x3Ds nicht funktionieren.
Wenn du dort 200Mhz einträgst muss dein x3D dann auf 5250Mhz statt 5050Mhz takten. Und das dürfte er eigentlich nicht tun.
Doch, es funktioniert. Aber: nur nach unten, also negativ. Takterhöhung funktioniert dadurch nicht.

Genau meine Erfahrung. Zumindest nach "oben". Wie es nach "unten" aussieht, habe ich nie getestet.
Funktioniert nur nach "unten" bei mir. Check.

@Dr1val es gibt übrigens eine Curve Optimizer Anleitung von @Darkearth27
Kannst du im Discord unter "Anleitungen" finden ^^
Steht zwar Ryzen5000 dabei, aber funktioniert bei Zen4 genauso
@Darkearth27 hat mir schon einmal Configs geschickt. Mit diesen arbeite ich von nun an.
1705916042071.png


Meine selbst umgeschriebenen Configs haben mittlerweile dutzende Leute genutzt, keiner hatte sich bisher beschwert, dass es danach noch instabil gewesen wäre. Daher vermute ich eben, dass der falsch bedient wurde. Ist aber auch blöd gemacht, da gibts keine vernünftige Anleitung und wenn einem das niemand sagt, dann sind die standarteinstellungen halt total sinnlos. Selbst wenn du die runtime per core massiv erhöhst, durchläuft er nicht alle FFT größen, da es bei wenigen FFT größen gecappt ist. Dann läuft er halt von 16K bis 52k einfach ein paar mal bei erhöhter runtime per core anstatt von 4k bis 512k wie es eigentlich sein sollte.
Kannst Du mir auch gerne noch einmal schicken. Wäre Dir sehr verbunden. :D

edit:
SotTR lief damit schon einmal stock durch (BCLK = 104 MHz; CO = 0):
1705916212558.png
 
OCCT findet schnell Fehler, wenn man es mit dem CO übertreibt. Das ist gut geeignet, wenn man z.B mit -30 all Core anfängt. Den OCCT CPU Test (Large - Extreme - variable - AUTO (AVX2)extreme) laufen lassen und dann hagelt es recht schnell WHEAs. In der Ereignisanzeige den entsprechenden Core (ApicID) herausfinden und dann in 5er Schritten den Core anpassen.

Im BIOS auch checken, ob das Pcie Advanced Error Reporting enabled ist (sonst werden eventuell keine Wheas geloogt).
Im prinzip ist es egal ob man OCCT oder CC mit Prime/Y-Cruncher für das initiale schauen wann es "abkackt" benutzt.
Wichtig ist nur, dass man es nicht direkt übertreibt mit dem CO.
Würde daher mit -15 anfangen und mich dann auf -20 runter arbeiten, dann -25 usw.

Wenn man damit durch ist, kann man dem CC weitermachen. Ich verlinke mal einen Beitrag, der auf zwei gute Configs dafür liefert.
Sehe die runtime mit 10min per Core sehr kritisch.

Das kann sehr gut sein. So extrem lange lief der bei mir auf jeden Fall nie. Ich habe das über Nacht und den Arbeitstag laufen lassen. Also maximal 24h. In der Zeit gab es keinen Fehler und bei Prime95 Allcore Last ist er dann instant abgeschmiert ^^

Vllt war es auch nur ein dummer Zufall, wer weiß.
Möglich. Bei der nächsten AMD Cpu weißt du bescheid, dann kann ich dir angepasste Configs zukommen lassen ^^

Kauf dir einen 7950X3D wenn du leiden willst :D
Nene, ich will nicht auf AMDs sheduling angewiesen sein. Wenn dann ein 7800x3D ^^
Und abgesehen davon bin ich armer Student, kann mir sowas nicht leisten :ugly:

Naja jetzt steht erstmal ein MoRa aufm Plan und die internen Radis fliegen raus. Mal sehen was Zen5 bringt und ob es dann ein 7800x3D oder 9800x3D wird ^^

Doch, es funktioniert. Aber: nur nach unten, also negativ. Takterhöhung funktioniert dadurch nicht.
Ja gut, wieso sollte man das tun? :ugly:

@Darkearth27 hat mir schon einmal Configs geschickt. Mit diesen arbeite ich von nun an.
Anhang anzeigen 1449760
Kannst Du mir auch gerne noch einmal schicken. Wäre Dir sehr verbunden. :D
Muss ich garnicht, das sind nämlich meine CC configs *pfeif :lol:


edit:
Im prinzip reicht es wenn du SSE und AVX Schnelltest verwendest bis die Kerne abkacken.
Also wie du sagst bei -5 auf allen anfangen, beide tests laufen lassen, dann weiter zu -10 usw.
Wenn kerne abkacken, kannst du die wieder um +2 erhöhen.
Sobald dann alle Kerne einmal instabil waren, also deine CO werte hast, kannst du die Abschlusstests durchlaufen lassen.
Kann gut sein, dass da dann wieder instabilitäten auftauchen, entsprechend wieder +2 auf den Kern.

Und wenn du richtig bock hast, stellst du "Number of Threads" noch auf 2 und verdoppelts bei den Tests die Runtime per Core. Aber das dauert dann richtig richtig lange und ist nur empfehlenswert wenn du 99,9% stabilität willst, ansonsten musst du mit 99% leben.
Wäre aber auch kein Beinbruch, denn falls etwas abstürzen solltest, kannst du über die Ereignisanzeige die APIC ID rausfinden und den entsprechenden Kern +2 geben.

Sieht dann so aus und wird als WHEA ID18 gelistet:
1705916770025.png

APIC ID: 4 = Kern 3 (aka Core 2)
ID0 = Core 0, Thread 0
ID1 = Core 0, Thread 1
ID2 = Core 1, Thread 0
usw

Interessanter Sidefakt dazu:
Wenn man einen 12 Kerner hat, hört es bei Core 5 (Kern6) mit APIC ID 11 auf (=Core 5, Thread 1).
APIC ID 12-15 sind NICHT BELEGT, da diese bei den 16 Kernern eben Kern7+8 (Core6+7) von CCD0 sind.
APIC ID 16+ sind dann die Kerne auf dem zweiten CCD.
Wenn man also einen APIC ID16 auf einem 12 Kerner bekommt, dann ist damit Kern 7 (Core6, also der erste Kern von CCD1) gemeint und nicht wie man eigentlich denken würde kern9 (Core8), welcher nach Zählweise eigentlich der Fehlerhafte Kern sein sollte.
Das hat mich damals beim CO einstellen echt nerven gekostet^^
 
Zuletzt bearbeitet:
Ja gut, wieso sollte man das tun? :ugly:
Damit man den BCLK höher fahren kann. :D
Ist halt sinnlos, ich weiß. ^^

Wenn 104 MHz stabil sein sollte, bin ich schon happy. Schauen wir mal.

PS: Lachsmiley auf den letzten Satz bezogen. xD

edit:
Soll ich mit dem AVX - Schnelltest anfangen und den einfach mal über Nacht durchlaufen lassen?
 
Zurück