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

Creekground schrieb:
Muss ich mir mal in Ruhe reinziehen. Wie sind deine CO Werte mit BLK 100? Oder ich übersehe diese.
So, hab hier in meiner Anleitung den Screenshot aktualisiert, da findest Du die finalen Werte - auch für BCLK 100, denn das Geile ist: die "Parallelverschiebung" nach unten funktioniert tatsächlich :D Dh bei BCLK 100 kann ich alle CO um -16 verringern vs BCLK 102,25 , und es läuft genauso durch! Sprich das ganze skaliert sogar nicht-linear. Wird natürlich noch weiter ausgelotet auf BCLK 100. Wie komme ich auf -16 im ersten Schritt? Weil ich damit beim schlechtesten Core auf -30 lande bei BCLK 100 (vs eben -14 bei BCLK 102,25).
BreadPit schrieb:
So sieht das Excel aus, ev hilft ja die Visualisierung zum Verständnis:

Anhang anzeigen 1345281
Ergänzung ()

Damit ist übrigens auch geklärt, dass ich jedenfalls bei meinem Prozessor der BLCK OC um 100Mhz ( 4550 --> 4650 Boost) nicht auszahlt, weil das nur mit deutlich mehr Spannung funktioniert - und damit läuft der Prozessor schneller ins Power-Limit (EDC konkret) und ist langsamer als mit BCLK 100 !
P4-Freak schrieb:
Okay na dann bin ich schon fast froh dass mein PC eh nicht mit bclk oc geht
Wieso fast? Sei froh, Du betreibst ihn innerhalb der Spec und bist schneller auch noch dabei, kühler und problemloser sowieso ;) Das Ganze wäre anders wenn AMD die Limits aufheben würde - tun sie aber nicht. Btw bei meinem MSI 1.2.0.8 BIOS lässt sich PPT/TDC/EDC alles ändern, aber EDC nur senken unter 130 - nicht mehr auf 140 erhöhen, auch mit POBtuner nicht! Schade, aber... egal :)
 
Zuletzt bearbeitet:
Ich habe mal meine mit Boosttester auf den schlechtesten Core angepassten Werte auf den SleepMode Bug übertragen. Unterschied normal vs. Sleepmode ist ca. 35mv. Von meinen Werten habe ich 10 pro Kern abgezogen und Y-Cruncher mit n64 gestartet. Nach 20 Min. Reboot Whea Kern 4. Das ist mein schlechtester Kern. Dann alle Kerne nochmal um 1 verringert. Y-Cruncher lief danach 100 Minuten ohne Fehler. Danach den Sleepmode aktiviert, PC schlafen gelegt und wieder aufgeweckt. Zwei Stunden ohne Absturz gezockt.
Jetzt habe ich erstmal einen Hybridmodus. Nach dem PC Start ist er Stabil, nach dem SleepMode ist er gamestable. Hoffe ich zumindest mal.
Aktuelle Werte: -8, -8, -19, -14, -16, -17, -16, -14.
 
  • Gefällt mir
Reaktionen: 4BitDitherBayer und BreadPit
Das sind im Moment meine allgemein Gültigen Werte. Mir ist aufgefallen das ich mit den alten Werten schon Clockstretching hatte. Wenn ich mit diesen Werten CPU Z starte, ist der Singlecore score konstanter und besser.

Zum Thema mit AMD und besten Kernen. Ich denke das stimmt schon was AMD ermittelt. In Stock brauchen die besten Kerne die niedrigste Spannung. AMD testet nicht mit dem CO. Der CO wurde erst später durch einen BIOS update nachgereicht. Am Anfang von Vermeer gab es keinen CO.
 
Zuletzt bearbeitet:
@BreadPit ich habe mal deinen Test angeschmissen. Wie lange lässt du den laufen? Wie schnell findet er Fehler?
 
BreadPit schrieb:
aber EDC nur senken unter 130 - nicht mehr auf 140 erhöhen, auch mit POBtuner nicht! Schade, aber... egal :)
was fürs Gaming aber eh irrelevant ist oder?

Ich hatte das 1.2.0.8 Mod Bios laufen, was auch einwanfrei lief. Allerdings hat sich wohl ASPM Auto nicht so gut mit meinem GPU UV vertragen. Hab die GPU auf 0.875v festgenagelt, mit dem Mod Bios ging es dann aber plötzlich rauf bis 1.045v. Allerdings müsste ich das noch mal genauer beobachten, denn auch mit dem normalen Bios geht die GPU Spannung über 0.875v aber nur bis die GPU 40 Grad C erreicht hat.
 
Der Erkenntnisgewinn geht weiter: Hatte ne Idee einfach ausprobiert, und endlich ist mir klar warum das "Kombo Strike" heißt:
  • "Kombo Strike" ist die Kombo aus EDC 140A und CO
  • PBO Advanced mit CO ist Per-Core Offset mit EDC 130A
Aber ehrlich, wie sinnlos ist das bitte? Warum macht man so was?
Also es gibt eine EDC Lösung für CPUs, die CO -30 können. Wenn die CPU nur -25 kann, muss man Kombo Strike 2 nehmen, läuft damit auch eher ins EDC Limit, ist also wieder unbrauchbar.

Beweis - Screenshots von Kombo Strike 3 :

1681207435579.png

1681207469328.png

Ergänzung ()

Creekground schrieb:
@BreadPit ich habe mal deinen Test angeschmissen. Wie lange lässt du den laufen? Wie schnell findet er Fehler?
Tatsächlich binnen 5-60 Sekunden wenn CO zu niedrig, deshalb find ich den so toll. Da ist N64 viel problemloser durchgelaufen. Wenns an der Stabilitätsgrenze ist kanns auch mal 2-3 Durchläufe brauchen, was bei 4min dennoch schnell geht.

Übrigens, echt arg - um meinen Test stabil zu überstehen, braucht:
  • BLCK 102,25 = 4650 MHz Boost = +100: -2/+2/-2/-2/-0/-14/-12/-2 - läuft MulitCore früher ins Limit
  • BLCK 100,00 = 4550 MHz Boost = Stock: -30 All Core!!! - läuft MultiCore nicht ins Limit
Damit ist der BCLK Overclock um 3% langsamer als Stock mit maximalem stable CO -30, weil die CPU bei BCLK 102,25 früher ins PPT/TDC/EDC Limit läuft! Bei meinem Prozessor jedenfalls, der scheint ein brauchbares Sample zu sein.

SeniorY schrieb:
was fürs Gaming aber eh irrelevant ist oder?
Für´s Gaming ist das alles irrelevant, aber "für die Fans" nicht :D Ich mag künstliche Limits nicht, und wenn ich einen Weg drum herum finde ist das ideal - "no limits" ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SeniorY und Creekground
@BreadPit Danke. Ich muss bei mir den Sleepbug mit einrechnen. Ausserdem kommtes zu Clockstreching bei mir. Mit den neuesten Werten ist Timespy wieder besser.
 
  • Gefällt mir
Reaktionen: BreadPit
@Verangry und das Ganze ohne WHEA? Wow :)

Dafür hab ich offenbar doch einen -30 AllCore fähigen 5800X3D. Hatte auch nie Fehler bei Tests, aber Idle-Reboots. Die hatten aber offenbar mit zu wenig vSOC und vor allem RAM-OC zu tun, hatte tRFC zu stark angezogen und vDIMM offenbar auch. So läuft es jetzt:

1681216766910.png
 
Das ist ja auch echt sinnlos - das ist wie eine Außenblende über den Radkasten zu machen, wenn in den Autoreifen zu wenig Luftdruck ist. "Man sieht kein Problem, also ist da auch keins?"
Ergänzung ()

Ich hatte übrigens grad noch eine Erkenntnis. Wie es aussieht läuft mein 5800X3D sogar nach S3 mit -CO 30 , also nach dem Sleepmode mit nochmal ~30mV weniger!

Wollte daraus schon schließen, dass ich eine besonders gute CPU habe. Aber ich denke es ist eher folgendes:
  • Bei CO -30 hab ich vor S3 ca ~15070 CB23 Punkte, nach S3 ca ~15300
  • Ich habe ein MSI Mainboard
  • Andere haben 15400+ CB23 Punkte, und das mit deutlich weniger CO, -8 bis -17, siehe @Creekground
  • Diese anderen haben meist Asrock Boards / keine MSI
  • Aber alle haben den S3 Bug, dh dass AVFS nach Sleepmode nochmal mehr negatives CO Offset hat
Was hier also passiert, ist wohl einfach folgendes:
  • MSI hat im AGESA mehr Toleranz in AVFS eingebaut, sprich eine entschärfte AVFS / PBO Kurve hinterlegt
  • Andere wie Asrock gehen mehr ans Limit, also machen mehr "Default-Undervolting"
Nebenerkenntnis: deshalb beklagen sich auch manche User dass mit einer neuen AGESA die alten CO Settings nicht mehr funktionieren. Da hat wohl einfach der Hersteller die AVFS Kurve im AGESA angepasst...

Klingt schon extrem logisch, oder? Oder wissen das schon alle und ich habs überlesen, obwohl ich gefühlt alles gelesen hab? :D
Ergänzung ()

...und deshalb sagen MSI Kunden wie ich ständig: ich versteh ned was ihr falsch macht, bei mir rennt jeder Prozessor mit CO -30? Und genauso kompetente Experten mit Asrock Brett antworten: Humbug, Du glaubst nur das ist stabil, aber Du hast noch nicht Y-Cruncher-Test XY lang genug laufen lassen, denn dann lernst du, dass Du akribisch den CO Offset einzeln pro Kern einstellen musst!! Und beide haben recht.

Ich habe als MSI Kunde erst durch BCLK OC meine ersten WHEA 18 kennengelernt, und auch Y-Cruncher Abstürze / Errors. Vorher nie irgendwas, immer max CO -30 und UV noch on top....
Ergänzung ()

Letzte Ergänzung: bei meinem Prozessor & Board ist erst Schluss bei CO -30 + S3 Bug(=-30mV) + LLC8 - dann gibts die ersten Fehler :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: KeSch, 4BitDitherBayer, Guphoff und 2 andere
@BreadPit könnte alles möglich sein. Der sleepbug nervt, genauso der Bug nach einer Umstellung im Bios. Hab heute Mittag mal meine CO Werte um +2 erhöht. Sleepbug aktiviert und deinen Test gestartet. Nach 1 Std 30Min Fehler Kern 10. Bin mit meinen aktuellen Werten schon ziemlich optimal.
Ich glaube Asrock hat keine Liebe ins Bios (für den X3d) gesteckt. Sleepbug. Vsoc und Ram Geschwindigkeit.
 
  • Gefällt mir
Reaktionen: BreadPit
...man sollte sich also nur noch in gemessenen VIDmin / VIDmax Spannungen unterhalten, alles andere ist "unspezifizierter Herstellerjargon" ;)
 
@BreadPit yup. Die LLC Einstellungen habe ich noch vergessen.:heul:
 
  • Gefällt mir
Reaktionen: BreadPit
Dann lass die LLC doch weg - die stresst ihn nur unnötig, Vdroop ist gesund laut Herstellern, und Du fühlst Dich mit besseren CO Werten... eben besser :D
Ergänzung ()

LLC on top macht ja auch nur Sinn, wenn Du mit CO schon auf Anschlag bist und noch weiter runter willst. Aber Du hast CO ja gar ned ausgereizt, also weg die LLC 😉
 
Zuletzt bearbeitet:
@BreadPit passt schon. Die Bugs sind halt das nervige. Das BIOS funktioniert gegen den Wind sozusagen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BreadPit
Aber Dein LLC Feedback hat mich jetzt auf die Lösung gebracht, wie ich meine CPU doch noch weiter ausreizen kann, sodass meine CO Anleitung auch für mich Sinn macht - ohne BCLK OC: ich mache CO + LLC8 + S3UV, und lote dann für die hftl nur 1-3 problematischen Kerne die CO Reduktion aus. Es geht immer noch was - war schon ganz traurig dass ich am Ende der Freizeit-Optimierung angelangt bin, danke 😉
 
  • Gefällt mir
Reaktionen: 4BitDitherBayer und Creekground
Man stelle sich vor man würde das im Leben auch so machen.
Wenn du den 100km Marathon nicht bestehst, bist du arbeitsunfähig... ;)

Ich hatte im Realbetrieb seit Tag eins noch nie einen Aussetzter oder Anomalie trotz -30+Bclk 101 und CPU LLC auf Minimum.
Wenn ich damit nach S3 (~CO -40) aber y-cruncher mit N64 laufen lasse, knipst es mir früher oder später die Lichter aus :D
Deswegen die Aufgabe CO nach S3 um den Wert 10 nach oben zu korrigieren.
Sehe bei mir keinen Mehrwert den Übeltäter / Kern nach S3 zu identifizieren.

Ob es jemals eine weitere AGESA ggf. mit Fix geben wird bezweifele ich sehr stark.
Laut Gigabyte wurde die Info an AMD weitergeleitet.
 
@BreadPit bedanke dich bei Asrock.;) @SyntaX hat mich draufgebracht die Kurve an den S3 anzupassen. Ich wollte es nicht unbedingt übers Tool machen. Jetzt hab ich einen 5800X3D Hybrid (Stabil/rockstable) Hat auch nicht jeder. :cool_alt:
Ergänzung ()

@SyntaX -30 ist bei mir nicht möglich. Da stürzen schon die Games ab. Meine alten Werte waren gamestable aber nicht Y-Cruncher stabil. Nachdem ich jetzt im Bios -11 abgezogen habe ist es gut denke ich. Ausserdem habe ich kein Clockstreching im Singlecore mehr. Hat also ewas gebracht. Die Temperatur und die Watt haben sich leicht erhöht. Den Asrock support haben wir über den S3 informiert. Das sollten sie wenigstens noch fixen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SyntaX
Zurück
Oben