[Leserartikel] Curve Optimizer Guide Ryzen 5000

Darkearth27

BIOS-Overclocker(in)
Deckblatt.jpg

Hallo Zusammen,

auf Wunsch im Ryzen Sammler teile ich auch hier den selben Guide, den ich auch bei Computerbase im Forum als Leserartikel erstellt habe und hoffe, dass sowohl hier als auch im CB Forum dadurch kein "Streit" ausgelöst wird und man sich einzig und allein um den Inhalt kümmert und diesen diskutiert.

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, Settings wie Global C States Enabled, PSS Support Enabled (ehemals Cool & Quiet) und und und

image006.png


image008.png


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



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)

image010.png


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" @gaussmath - > "CoreTunerX".

Als nächsten Schritt gehen wir dann zurück ins BIOS und stellen im PBO Menü auf "Advanced" um.

Grundeinstellungen im PBO Menü:

image012.png

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:

image014.png


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.

*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.
*Anmerkung von @sp00n.82 -> Ersteller des CoreCyclers

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.

image016.png


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 PCGH Forum (auch via PN), im RAM OC Discord oder bei CB 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




image018.png


image020.png


image022.png


image024.png


image026.png

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 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.
image028.png


image030.png
 
Zuletzt bearbeitet von einem Moderator:
Ich wollte es durch deepl jagen, aber es sind zuviele Zeilen. Und alles auf Englisch manuell zu übersetzen hab ich gerade keine Lust.

Außerdem gibt es ja im Netz genug Anleitungen zum CO in englisch.
 
Gefällt mir gut der Guide,saubere Arbeit.

Einige Anmerkungen:
-Ich konnte bisher auf meinen Systemen kein ClockStretching verzeichnen beim Einsatz von CO.
-Ein durchgehender Offset von -30ist teils durchaus möglich, vor allem die kleineren CPU´s verkraften das durchaus wenn man kein weitere OC betreibt und den Takt erhöht.Mein 5600X macht z.B.recht geschmeidig +200Mhz und -30 auf allen Kernen(außer ein Krüppel, der schafft nur -25)

Ohne Taktanhebung konnte ich das so ähnlich auch bereits auch auf einem 5800X umsetzen. Der hat jedoch sehr allergisch auf Taktanhebung reagiert, jedoch konnte man damit die Temperaturen massiv entschärfen.(-10Grad)

-Erwähnenswert wäre meiner Meinung nach noch das +200 nicht zwangsläufig schneller sind als z.B. +75Mhz.
-Ein LLC auf Medium hilft stabilie Werte zu erreichen. Das ist oft besser als Auto.
-Ein zusätzliches - auf die Vcore kann Sinn machen,vor allem in Verbindung mit leicht angehobener LLC.
-Es gehört zwar nicht zum Thema CO, aber SOC UV kann vor allem bei den kleineren Modellen entscheidende Watt einsparen und senkt auch den IDLE Verbrauch.
 
Danke @Gurdi für deine Worte.

Das mit den LLC Einstellungen lasse ich absichtlich weg, da alle Mainboard Hersteller entweder eine andere Reihenfolge oder unterschiedliche Werte haben (bei den einstellbaren Werten)

Das mit dem Boostoverride hatte ich ja schon indirekt im Guide angesprochen und wird auch bei fast jedem abweichen, auch da kann ich halt keine allgemeine Aussage machen. (deswegen ist der Guide so geschrieben, dass man sich ein wenig selbst damit beschäftigen muss)

Was die SoC Power angeht, werde ich es nicht mit aufnehmen, da RAM OC immer noch die meiste Leistung bringt und einige bei 3800CL14 (und höher) den SoC eh ausloten müssen.

Man kann hier und dort immer an der Leistungsaufnahme sparen, aber wie ich bereits schrieb sollen sich die Leute ein bisschen selbst mit ihrer Hardware auseinander setzen, viel zu oft kamen immer wieder die selben Fragen wie z.B.

"Wieso hast du soviel mehr Punkte" oder "du hast doch geschrieben, dass:"

Gebe allen recht, aber die haben halt ihre HW und ich meine, man versucht da dann immer alles zu vergleichen was nicht vergleichbar ist, denn alles ist ein Unikat und jeder hat einen anderen Workflow und Workload.

Natürlich könnt ihr gerne Erfahrungen sammeln und hier in dem Thread mitteilen, machen sie bei CB ja nicht anders und dann können erfahrene User helfen, Probleme zu lösen oder Hilfestellung geben.

Ich wollte mit dem Guide lediglich einen Anhaltspunkt schaffen wie man am besten an die Sache herangehen kann (sollte), was der Einzelne hinterher mit den Infos macht muss jeder selbst wissen und vor allem testen ;)
 
Zuletzt bearbeitet:
Moin,
@Darkearth27 besten Dank für den tollen Guide!

Habe mal ein bisschen mit CO+CC rumgespielt mit dem Ergebnis, dass @ stock immer mein "bester" Kern (--> #1/1) auf meinem 5800X mit CC aussteigt. Egal, ob frisch nach einem BIOS-Reset (drei unterschiedliche AGESA-Versionen durch!) oder mit diesem Kern auf +5 und Rest auf 0. Das System läuft aber soweit stabil, bisher keine BSOD oder Abstürze... Jemand eine Idee?
 
Hatten wir leider schon öfter, dazu am besten mal das Log aus dem corecycler hochladen, eventuell kann man da die Ursache finden.

Wenn du ein CB oder Luxx account hast, kannst du auch sp00n.82 im Thread Fragen, er hat in beiden Foren seinen corecycler zur Verfügung gestellt.
 
Gibt es irgendwo übersichtliche/belastbare Untersuchungen, wie sich der Boost Offset auf das Endergebnis (insbesondere in Verbindung mit aktivem Curve Optimizer) auswirkt? Und das gerade in Bezug zu effektivem Takt?
 
Mir sind keine bekannt, einzig an der Stabilität merkt man es (früher oder später) und wenn man Benchmarks vergleicht, diese sind aber auch oft variabel, sodass einem nur das testen mit der eigenen CPU bleibt.

Silicon lottery und insbesondere die "Best Core" Reihenfolge spielen hier auch eine Rolle.
 
Toller Guide!
Ich habe mich da an die Anleitung von Sp00n.82 orientiert und folgende Werte geschafft:
1617824418975.png

Ziel war im Single-Core-Boost 5 GHz zu erreichen, dazu habe ich bei PBO +150 MHz eingestellt, Scalar ist auf Auto. Der letzte Kern schafft es leider nicht ganz, der Allcore-Boost ist aber um gut 100 MHz gestiegen.
Zusätzlich ist die Leistungsaufnahme auch noch um 10-20W gesunken.
Getestet habe ich erst mit dem CoreCycler und ausgiebig mit verschiedenen Games, wobei letzteres zuferlässiger war.
 
Habe mal ein bisschen mit CO+CC rumgespielt mit dem Ergebnis, dass @ stock immer mein "bester" Kern (--> #1/1) auf meinem 5800X mit CC aussteigt. Egal, ob frisch nach einem BIOS-Reset (drei unterschiedliche AGESA-Versionen durch!) oder mit diesem Kern auf +5 und Rest auf 0. Das System läuft aber soweit stabil, bisher keine BSOD oder Abstürze... Jemand eine Idee?
Nachtrag: mit der Prime95 Version 30.3 im CC (original 30.5) läuft es jetzt bei mir!
 
Hattest du dich mit sp00n.82 unterhalten?
Ich hatte nämlich ein ähnliches Problem mit anderen Prime Versionen, ältere brachten keinen Fehler, die anfänglich integrierte im Core Cycler hatte dann Fehler geworfen, die ich mir nicht erklären konnte (alle Quertests waren fehlerfrei) woraufhin sp00n.82 dann die Prime Version aktualisiert hatte.

Ist schon merkwürdig, dass es da immer mal wieder zu Fehlern mit verschiedenen Versionen kommt und gibt.

Immerhin hast du eine Lösung gefunden, ich hatte anfangs echt Probleme und war schon frustriert das immer wieder Fehler kamen. (Hat mich auch lange beschäftigt und erst ein Quertest hat dann die Quelle bestätigt)
 
Zuletzt bearbeitet:
Liegen die 5 GHz denn unter effective clock beim Cyceln auch real an?
Da hab ich gar nicht geschaut :ugly:
Kann ich heute Abend aber noch nachholen.

Edit:
Hab jetzt nochmal geschaut, hier das Ergebnis:
1617911040567.png

Effektiv werden nicht ganz 5 GHz erreicht aber da gehts am Ende eh um die psychologische Grenze. :D
 
Zuletzt bearbeitet:
Hattest du dich mit sp0082 unterhalten?
Ich hatte nämlich ein ähnliches Problem mit anderen Prime Versionen, ältere brachten keinen Fehler, die anfänglich integrieren im Core cycler hatte dann Fehler geworfen, die ich mir nicht erklären konnte (alle Quertests waren fehlerfrei) woraufhin sp00n82 dann die Prime Version aktualisiert hatte.

Ist schon merkwürdig, dass es da immer mal wieder zu Fehlern mit verschiedenen Versionen gibt.

Immerhin hast du eine Lösung gefunden, ich hatte anfangs echt Probleme und war schon frustriert das immer wieder Fehler kamen. (Hat mich auch lange beschäftigt und erst ein Quertest hat dann die Quelle bestätigt)
Hey @Darkearth27,
mangels Account in den anderen beiden Foren leider nicht.

Mit der Version 30.5 gab es immer Fehler trotz stock Settings (ohne XMP!). Habe dann irgendwo gelesen, dass es auch an der Prime95 Version liegen kann und entsprechend die ältere 30.3er probiert - voilá! die Sache läuft.

Interessanterweise sind mit der V30.5 die Kerne manchmal wie Domino-Steine ausgestiegen, also nach dem ersten Fehler auf einem Kern haben alle folgenden auch innerhalb kurzer Zeit versagt. Eine weitere Beobachtung betrifft die Ausgabe der Fehler: in der aktuelleren P95-Version wurden die Fehler mit allen Nachkommastellen ausgegeben, also:

FATAL ERROR: Rounding was 0.4999276052, expected less than 0.4

Bei der alten Version wird dagegen gerundet:

FATAL ERROR: Rounding was 0.5, expected less than 0.4

Kann jetzt nicht beurteilen, ob es da einen Zusammenhang gibt, das sei an dieser Stelle nur aus Gründen der Vollständigkeit erwähnt...

VG Epi
 
Zurück