Verangry
Commander
- Registriert
- März 2019
- Beiträge
- 2.112
Hallo Zusammen,
es ist nun schon ein Weilchen her seitdem in meinem letzten Guide ein Update geschrieben wurde, also folgt nun ein etwas längerer Artikel, diesmal zum Curve Optimizer. Die Testmethoden und Ergebnisse weichen eventuell von vorherigen Guides ab, manches kann und wird aber schon bekannt sein, je nachdem wie sehr man sich bislang mit dem Curve Optimizer beschäftigt hat.
Nachdem die 5000er Ryzen ja nun schon seit einer gewissen Zeit im Handel sind (nicht gerade gut verfügbar offen gestanden, aber das ist ein anderes Thema) hab ich mich mal dran gesetzt und versucht die besten Bios Settings für Zen3 zusammen zu stellen und besonders den Curve Optimizer zu beleuchten.
Das übliche Vorwort, dass ihr mit den Einstellungen die hier empfohlen werden ggf. außerhalb der Spezifikationen arbeitet und damit einhergehend einen Garantieverlust durch Overclocking in Kauf nehmt, sollte euch bewusst sein.
Falls nicht, dann jetzt schon
Ich übernehme auch keinerlei Verantwortung oder hafte für die von euch getätigten Einstellungen. Ich gebe nur Tipps wie man es machen kann (muss ja auch nicht bei Jedem zum Erfolg führen).
Eines noch vorweg, wer das ganze in Ruhe und nicht im Forum lesen möchte, der kann sich HIER die PDF herunterladen.
(Eine englische Version wird es auch bald geben)
Vieles kann von Zen2 übernommen werden, Geschichten wie Global C States Enabled, PSS Support Enabled (ehemals Cool & Quiet) und und und
Erster Punkt.
Kommen wir zu den wichtigen Änderungen.
PBO ist aktuell, wenn auf Auto gestellt, eine Blackbox. Manche Boards setzen die echten CPU Limits für deren TDP Klasse, manche Boards lassen „Auto“ aber auf Enabled mit Mainboard Limits und wieder andere mit offenen Limits.
Ich empfehle daher, wenn mit PBO und dem Curve Optimizer gearbeitet wird (und die TDP eingehalten werden soll), dann die TDP Limits der CPU manuell einzustellen.
Die einzige Änderung bei den Limits hat der 5600X erfahren, dessen PPT Limit von 88w auf 76w gefallen ist.
Also im Klartext:
5600X TDP = 76w PPT 60A TDC 88A EDC
Die restlichen Limits sind so geblieben wie sie es auch schon bei den 3000er waren, aber auch hier nochmal zur Übersicht:
5800X TDP = 142w PPT 95A TDC 140A EDC
5900X TDP = 142w PPT 95A TDC 140A EDC
5950X TDP = 142w PPT 95A TDC 140A EDC
Auf Anfrage hier noch eine Zusatzinformation.
Für 45W TDP CPUs/APUs gibt AMD folgende Werte vor: 60W PPT - 45A TDC - 65A EDC
HINWEIS!
Alles Nachfolgende basiert auf Erfahrungen mit dem Curve Optimizer und dem AGESA 1.2.0.1 (Beta) und kann sich mit früheren oder späteren Versionen wieder unterscheiden und vom Ergebnis abweichen. Deswegen die Empfehlung auf ein stabiles AGESA zu warten und dann einmalig die Werte auszuloten und zu nutzen denn bei einem AGESA / BIOS Update muss der Vorgang wiederholt werden, da sich Parameter geändert haben können.
Kommen wir nun zum Ausloten der Spannungen einzelner Kerne damit wir mit dem Curve Optimizer arbeiten können.
Dazu lassen wir PBO aus bzw. stellen es auf disabled (nicht auf Auto) stellen die VCore auf AUTO und starten den Rechner. (ein zusätzliches negativ Offset auf die VCORE würde die Werte verfälschen)
Nun öffnen wir CPUz und HWiNFO64 (HWiNFO zum Auslesen der Spannungen einzelner Kerne am SVI2 TFN Sensor).
Bei CPUz nutzen wir den Stresstest, beschränkt auf einen Thread und starten diesen.
Nun gehen wir in den Taskmanager und forcieren die Arbeit auf die Kerne, der Reihe nach.
Also als Erstes wird Core 0 getestet, dann geben wir im Taskmanager ein, dass die Last auf Thread 0 und 1 aufgeteilt werden soll (damit CPUz sowohl den echten Kern, als auch den dazugehörigen SMT Thread nutzt). Beim Wechseln der Kerne lassen wir den Stresstest laufen und ändern nur die Zuweisung via Taskmanager.
Nun schauen wir uns die Spannung an, die an dem Kern anliegt (SVI2 TFN Sensor) und vergleichen diese
mit der VID ab, also das, was die CPU anfordert (CPU Core0 VID).
Der Kern welcher die niedrigste Voltage bei höchstem Takt hat ist unser bester Kern und alle anderen
werden dann abgestuft.
Z.B.
Core 0 erreicht 4950 MHz bei 1.45v (SVI2)
Core 1 erreicht 4800 MHz bei ebenfalls 1.45v (SVI2)
Somit ist Core 0 um einiges besser, da bei selber Voltage 150MHz mehr erreicht werden.
Siehe Bild: (Achtung, es ist ein Beispielbild → es kann und wird bei euch abweichen)
Dies machen wir nun für jeden einzelnen Kern und notieren uns die anliegende Spannung, damit wir einen Ausgangswert für den Curve Optimizer haben.
Es gibt auch ein Tool, welches euch die "Güte" der Kerne, wie Windows sie einschätzt, anzeigen kann. Hierzu kann man entweder die im Bild oben zu sehende Core PERF Reihenfolge nutzen oder ihr nehmt das Tool vom "CapFrameX Entwickler" @ZeroStrat - > "CoreTunerX".
Als nächsten Schritt gehen wir dann zurück ins BIOS und stellen im PBO Menü auf "Advanced" um.
Grundeinstellungen im PBO Menü:
Boost Override
+0 bis +200 (jede Erhöhung muss ausgelotet werden. Es kann vorkommen, dass bei Einigen in Verbindung mit „CO“ schon bei +100 Instabilitäten auftreten können, bei anderen aber erst mit +200 -> Güte der CPU ist hier entscheidend)
Scalar
Auto (bis hoch zu 10x das entscheidet über die Dauer des Boosts und kann auch indirekte Auswirkungen auf den Curve Optimizer haben)
TDP Limits
auf weiter oben genannte Werte einstellen, oder selbst wählen wie viel die CPU bekommen darf. Höher als "Standard PBO Werte" werde ich allerdings nicht empfehlen.
Temperatur Limit
kann auf AUTO bleiben, oder ihr wählt einen Wert, den ihr maximal haben wollt. Beachtet aber, dass dann die CPU früher heruntertakten könnte.
Den Curve Optimizer erreichen wir durch die Änderung auf PBO Advanced nun auch und unter dem Reiter haben wir dann dieselbe Reihenfolge der Kerne wie sie bei HWiNFO angezeigt wird.
Im Curve Optimizer Menü haben wir nun drei Möglichkeiten:
1. Alle Kerne (positiv und negativ)
2. Je Kern (positiv und negativ)
3. Disabled (wollen wir ja nicht)
Nun beginnt die eigentliche "Arbeit".
Wir müssen für jeden Kern die Maximalstufe ausloten, aber wie am besten vorgehen?
Wir stellen zu Beginn einfach der „Güte“ nach ein. (Man kann natürlich auch direkt mit hohem Offset anfangen z.B. -10 oder -15 auf allen Kernen im ersten CCD und -30 im zweiten CCD, davon rate ich aber ab)
Dies bleibt euch überlassen und ist auch von CPU zu CPU verschieden wie viel diese mit macht.
Kernen, die eine niedrigere Voltage benötigen, geben wir einen geringeren Offset (negativ) als den Kernen, die eine höhere Voltage benötigen.
Also z.B. unser Kern 0 und Kern 1 haben die gleiche Güte (höchster Takt bei geringster Voltage), daher geben wir hier erst mal eine 0 oder -5 ein um einen Ausgangspunkt zu haben.
Dann geht es der Reihe nach weiter.
Je mehr Voltage ein Kern benötigt, desto "schlechter" ist dieser (meistens zumindest).
Im ersten CCD / CCX sollten die Spannungen der Kerne nicht weit auseinander liegen. Hier muss man schauen wie weit man herunter gehen kann, für den Anfang würde ich aber folgendermaßen vorgehen:
Beispiel:
Kern 0 (bester Kern) Offset negativ = 0
Kern 1 (zweit bester Kern) Offset negativ = 0
Kern 2 Offset negativ = 5
Kern 3 Offset negativ = 7
Kern 4 Offset negativ = 9 -> benötigt die höchste Spannung um den Takt im CCX zu erreichen
Kern 5 (dieser ist besser als 4 aber schlechter als 3) Offset negativ = 8
Damit hätten wir bei einem 5900X oder 5600X das erste CCD schon mal fertig.
Man kann, wie ich oben schrieb, auch weiter runter gehen aber wir wollen ja einen Einstieg haben wo wir ansetzen können.
Sofort auf -15 CCD1 und -25 auf CCD2 hat sich meist als zu hoch und instabil herausgestellt.
Beim 5900X ist das zweite CCD meistens und in 90% aller Fälle etwas schlechter als das erste (die restlichen 10% sind lucky). Da gehen wir dann in der Curve weiter in 2 - 5er Schritten, je nach Voltage die wir ausgelotet haben.
Beispiel:
Kern 6 (bester Kern im zweiten CCX) Offset negativ = 10
Kern 7 (schlechtester Kern im zweiten CCX) Offset negativ = 15 -> benötigt die höchste Spannung um den Takt im CCX zu erreichen
Kern 8 Offset negativ = 13
Kern 9 Offset negativ = 12
Kern 10 Offset negativ = 14
Kern 11 Offset negativ = 11
Wie im ersten CCD besteht auch hier die Möglichkeit weiter runter zu gehen (bis -30), aber wie oben schon erwähnt wollen wir erst mal ein grundsolides Gerüst auf dem man aufbauen kann.
ACHTUNG jeder Boost Override (0-200) hat Auswirkungen auf die Höhe des möglichen Offsets beim Curve Optimizer.
Kommen wir zu den Stabilitätstests:
Hier empfiehlt es sich die Kerne einzeln mit Prime95 oder jedem anderen Programm das eine Wechsellast hervorrufen kann zu testen.
Wenn man manuell mit Prime95 testen will, dann empfehle ich 20 Minuten je Kern bei FFT Größen zwischen 4 – 160, für den schlimmen Teil und 1344 – 4096 für den "normalen" Bereich.
Es kann vorkommen, dass ein Kern in einem gewissen Bereich einfach immer Fehler wirft, dies ist der Augenblick bei dem man den negativen Offset auf „positiv“ umstellt und es nochmal testet (zu geringe Voltage beim negativen Offset ist hier der „Fehler“).
Es ist mühsam alle Kerne einzeln so zu testen, aber es gibt ja Abhilfe!
Wer mit Prime95 arbeiten möchte und nicht manuell alle Kerne einzeln eingeben möchte, kann den CoreCycler von @sp00n.82 benutzen.
Dort sind einige Variablen in der Config.ini hinterlegt, wie z.B. FFT-Größen jenseits der 8192, oder Small FFTs und so weiter. Man kann auch festlegen ob ein Kern mit oder ohne SMT getestet werden soll und mit welchem Befehlssatz (SSE / AVX / AVX2) (Computerbase Thread zum Tool).
Als Iteration (also Durchläufe) empfehle ich für den Anfang erst mal 2 - 3 Stück à 360 Sekunden - wir wollen ja "schnell" ein Resultat haben und schauen ob wir weiter herunter können.
Wenn man der Meinung ist man habe die optimalen Settings gefunden, nutzen wir die in der Config.ini ab Ver. 0.8.0.0 dafür bereits als Presets hinterlegten „Heavy“ (entspricht den FFT-Größen von 4 - 1344), „HeavyShort“ (4 - 160) und „Moderate“ (1344 - 4096). Diese drei Presets lassen wir bis zum Erreichen aller FFT Größen (je Kern) zweimal durchlaufen, einmal mit SSE und einmal mit AVX/AVX2 wobei der AVX2 Befehlssatz für sehr hohen und stark belastenden Workload steht, welcher beim Gaming z.B. kaum bis gar nicht auftritt.
*Anmerkung von @sp00n.82*Hier entscheidet dann euer Nutzungsverhalten, was und wie ihr testet. Wollt ihr "nur" ein stabiles Gaming-Setup, reicht ein abschließender Test über Nacht. Für ein wirkliches "Rock-Stable" OC empfiehlt es sich allerdings, verteilt über mehrere Nächte mit verschiedenen FFT-Größen und Befehlssätzen (SSE, AVX oder AVX2) zu testen. Als Orientierungshilfe kann man hier den "traditionellen" Allcore-Overclock heranziehen. Ein 12 Stunden Test mit Prime95 auf Stabilität für einen Allcore-Overclock entspräche dann 12 Stunden Stabilitätstest pro Kern bei einem OC/UV mit dem Curve Optimizer. Ihr könnt euch also ausrechnen, dass dies um einiges zeitaufwändiger ist, um das gleiche Level an Stabilität zu erreichen.
WICHTIG!
Wenn schon RAM OC vorhanden ist können Fehler auch dadurch hervorgerufen werden, es muss nicht zwangsweise am OC der Kerne liegen. Deswegen solltet ihr 100%ig sicher sein, dass euer RAM OC stabil ist oder ihr stellt den RAM auf die maximal vom Hersteller zugelassene JEDEC Norm ein. 3200MHz mit CL22 22 22 22 bei 1.2v (oder einfach den RAM auf JEDEC 2133 stellen, um ganz sicher zu gehen).
Weiter zu den anderen Stabilitätstests:
Nachdem der CoreCycler 2 bis 3 Durchläufe Prime95 geschafft hat, würde ich vorschlagen mit AIDA64 und dem Stresstest "nur CPU" zu testen und diesen Test eine Stunde lang laufen zu lassen, auch dies kann der CoreCycler ab Version 0.8.0.0 nun, genauso wie Y-Cruncher (siehe Forumsposting bezüglich Presets bzw. siehe Config.ini).
Leider benötigt man für AIDA eine spezielle Version, deswegen müsst ihr nicht zwangsweise eine neue Version kaufen, es genügt auch die Testversion oder, falls vorhanden, benutzt eure AIDA64 Version die ihr bereits habt.
Sollte auch das geschafft worden sein beginnt der "spaßige" Teil des Testens und zwar Gaming.
Gaming-Last hat viele schnelle Spannungs- und Lastwechsel - anders als die synthetischen Tests bei denen ein fester Wert immer und immer wieder berechnet wird.
Besonders zu empfehlen sind hier Multiplayer Titel wie z.B. COD, BFV, CS und wie sie alle heißen.
Denn jedes Game hat ein anderes Ausnutzungs- und Taktverhalten.
Wer kein Gamer ist kann auch viele kleine und mittelgroße Datenmengen kopieren, zippen und extrahieren. Außerdem kann man als Miner ETH, F@H usw. oder die anderen alltäglichen Arbeitsaufgaben erledigen lassen.
Für den Anfang würde ich auch eine Stunde empfehlen (hier könnt ihr euch ja selbst aussuchen wie lange ihr es laufen lassen wollt).
Als absoluter „Grenzbereich OC-Killer“ hat sich bei mir übrigens SuperPi MOD 1.5XS mit „32M“ Berechnung herausgestellt, da hier sowohl die Kerne als auch der RAM / Cache / IF genutzt wird.
Liefen alle anderen Tests ohne Probleme durch, gab es hier Rundungsfehler, bis hin zu Systemneustarts.
Also auch ruhig mal ausprobieren.
Wenn das alles "stabil" ist, dann könnt ihr weiter runter mit dem Offset beim Curve Optimizer. Hier empfehle ich dann 2er Schritte.
Wie im ersten Beispiel von oben nur zusätzlich -2, diesmal allerdings auch bei den besten Kernen.
Kern 0 Offset negativ = 2
Kern 1 Offset negativ = 2
Kern 2 Offset negativ = 7
Kern 3 Offset negativ = 9
Kern 4 Offset negativ = 11
Kern 5 (dieser ist besser als 4 aber schlechter als 3) Offset negativ = 10
Diesen Schritt wiederholen wir nun so lange, bis man entweder das Maximum herausgeholt, oder mit dem erreichten Ergebnis zufrieden ist.
Seid ihr mit dem Optimieren fertig und wollt PBO wieder deaktivieren, bleiben die Werte vom Curve Optimizer bestehen. Diese müssen, bevor PBO auf Disabled gestellt wird, selbst auf Disabled gestellt werden. (Dies kann jedoch von AGESA zu AGESA unterschiedlich sein, selbst Hersteller-weit kann es Unterschiede geben (MSI, ASUS, GB).
Spannungen und Load Line Calibration (LLC) sollte bei CPU auf Auto gestellt werden, da wir in der Spitze Spannungen bis zu 1.5v bekommen können und eine zu hohe LLC einen Overshoot hervorrufen kann, der weder gemessen noch ausgelesen werden kann (ohne Profi Equipment). Diese Spannungen sind oft weit höher als die 1.5v maximal Spannung die uns angezeigt wird und auch gefährlicher. Deswegen aufpassen bei zu hoher LLC Einstellung!
Man kann allerdings die Schaltgeschwindigkeit etwas erhöhen bzw. einstellen (falls vorhanden, siehe Bild unten). Aber Achtung, je schneller geschaltet wird, desto wärmer können die VRMs werden.
Wie immer gibt es auch wieder (leider) versteckte Optionen, die mit einem MOD BIOS eventuell verfügbar gemacht werden können. Je nach Hersteller unterscheiden sich diese allerdings auch im Umfang.
Einige bei MSI (üblich versteckte, bzw. nicht zugängliche) liste ich in den nachfolgenden Bildern auf. Das kann bei ASUS oder Gigabyte z.B. wieder komplett anders aussehen, also schaut ob ihr Zugang dazu habt.
Die einzelnen Erklärungen was welche Option bewirkt, würde den Rahmen nun etwas sprengen und vieles davon hatte ich auch schon im vorherigen „Guide“ beschrieben.
Ich hoffe ihr könnt einiges an Wissen mitnehmen oder herausfiltern und falls euch Fehler auffallen, schreibt mir.
Hier im Computerbase Forum (auch via PN), im RAM OC Discord oder bei PCGH im Forum.
Auch @sp00n.82 ist sicher gerne bereit eure Fragen zum CoreCycler zu beantworten, geht dazu bitte in den entsprechenden Thread bei CB und stellt dort eure Fragen.
MFG Verangry / Darkearth27
DPM = Dynamic Power Management
Gab es schon früher mal (2013?) und ist, wie der Name schon sagt, ein dynamisches Leistungsmanagement. Wenn Leistung nicht gebraucht wird, kann der Cache und der RAM (falls eine APU genutzt wird auch der GPU-Takt) hier im Idle reduziert werden.
1 = 333 MHz / 2 = 400 MHz -> Wir stellen es auf 2, wenn wir maximale Performance haben wollen.
Die letzten beiden Bilder sind eher für APUs gedacht.
https://www.computerbase.de/forum/threads/curve-optimizer-guide-ryzen-5000.2015251/post-25494043
Die schlechtesten Kerne brauchen mehr Voltage um eine ähnliche Taktrate zu erreichen wie die guten Kerne.
Nimmt man das Bild oben und stellt sich die hellere Orangene Linie als 1.5v max vor (manchmal gibt es einen kleinen Overshoot, dann gehen auch 1.506-1.513v drauf, ggf sogar noch höher wenn die LLC falsch eingestellt ist)
Nun sieht man, dass der Spielraum bei den besten Kernen am geringsten ist, da diese schon nahe am Maximaltakt (grüne Linie) sind.
Ein Negativer Curve-Offset bewirkt nun folgendes:
Der Kern erreicht mit weniger Voltage die selbe Taktrate und da kommt der Boost Algorithmus ins spiel. Dieser merkt nun "aha der Kern hat noch nicht die max Voltage also kann ich den Takt erhöhen" und schon boosted der Kern 20/30/50 MHz mehr bei geringerer Voltage.
Ein Step im Offset entspricht real anliegend zwischen 2 und 4mv (3-5 wurde mal von AMD ausgegeben wenn ich mich recht erinnere).
Also wenn man mit Offset -30 z.B. einem Kern im Boost dann 90mv nimmt, gibt es einen Boost, bis zum erreichen der 1.5v die bei "PBO Aktiv" automatisch das Maximum bilden.
Entsprechend höhere Taktraten könnte man erwarten.
Bei den besten Kernen hat man da weniger Spielraum, weil die ja schon nahe am maximal erreichbaren Takt der CPU liegen und im Vergleich zu den schlechtesten Kernen dafür weniger Voltage brauchen.
Beispiel:
Kern 1 braucht für 5 GHz 1.43v (bester im System) der schlechteste 1.475v schafft aber nur 4.9 GHz -> bei automatischer Taktung
Nun kommt der Boost Override und sagt +200MHz bitte -> Kern 1 Schafft 5150MHz (aktuelle Grenze beim 5900x mit allen neueren AGESA versionen) braucht dafür nicht mal ein Offset.
Der schlechteste Kern müht sich ab mit 1.5v kommt aber gerade auf 5000MHz weil der Spielraum kleiner ist (0.025 zu 0.07v).
Da die Automatik aber immer für maximale Stabilität sorgen muss (in jedem Fall für ALLE) kann das aber zuviel sein und mit weniger Voltage könnte der Kern dann höher boosten, genau das macht dann der Offset den du mit dem CurveOptimizer einstellst.
Mehr Power heißt in dem Fall übrigens nicht mehr Leistung auf einzelnen Kernen, da diese ihr eigenes Budget haben (28w oder 29w hat ein Kern bei mir maximal erreichen können wenn absolut nur auf diesem die Last anlag) Die Gesamtleistung wird allerdings steigen, da jeder Kern dann unter Multicore Last mehr zur Verfügung hat.
PBO Mainboard Limits sind abhängig von der Menge und Güte der VRMs, zuviel und die CPU wird wieder weniger Takt schaffen, da das Limit überschritten und der Algorithmus damit nicht klar kommt, desweiteren weil die Temperaturen der VRMs auch eine Rolle spielen.
Zuletzt bearbeitet: