Leserartikel Curve Optimizer Guide Ryzen 5000

[Sissy1973]

Hallo ich habe einen Ryzen 5600 und habe im Curve Optimizer einfach negative -30 allcore und hatte noch nie ein Problem also ist es wohl Stabil.

Nun wie gehe ich vor um die Cpu zu bremsen da ich in 4k spiele sind die 4450 mhz allcore(Das liegt an bei CB23) überflüssig in spielen. Mir ist klar das allcore nie anlieget in einem spiel wenn man nicht gerade Shader kompiliert.

Ich habe PBO Boost Clock override negative mal -1Ghz eingestellt das ist das maximum damit komme ich in CB 23 auf 51 Grad und 45 Watt verbrauch bei knapp über 20% Leistungseinbußen in CB23. Stock knapp 11k Punkte mit dieser Einstellung knapp 8500 Punkte. Mit 4650mhz allcore shaffe ich fast 12k wenn alle hintergrundprogramme auf aus sind natürlich, aber die 200mhz gehen kräftig auf den verbrauch.

Deswegen sehe ich Ryzen at Stock wie von AMD geliefert schon im OC Modus da geht nix mehr zumindest nichts was fps mässig irgendwie fühlbar wäre. Deswegen kann man bis 4ghz locker runter ohne fps einbussen die man jemals fühlen könnte im vergleich zu Stock.

Oder gibt es eine klügere Version als wie ich es mache?

 

[Verangry]

"Fühlen" und runtertakten und feste Spannung anlegen etc ist hier halt nicht das Thema.

Messen, "OC-UV" bei Auto Spannungen ist es.

Wenn du dein -30 Allcroe im CO stabil (und das auch getestet) hast gibt es da nichts weiter zu besprechen

 

[Sissy1973]

Die spannung habe ich nicht angefasst nur Curve Optimizer und via PBO Boost Clock Override habe ich - 450 gesetzt so das ich maximal 4ghz statt 4.45ghz habe. Da das gut spart und den Unterschied merkt man eh nicht wollte halt nur wissen ob es für diese vorgehensweise eine besser methode gibt es gibt ja unzählige möglichkeiten bei der CPU.

Ja ist Stabil ich weis aber nicht wie selten das ist? Ryzens aus einer später Prodution sind meistens um einiges besser siehe Ryzen 3600 Release und eol Ryzen 3600 der unterschied war enorm.

 

[Verangry]

Wie gesagt, wenn du das so machen willst mach das so.
Ich persönlich würde da nichts beschränken.

Solange es stabil ist, passt das.

 

[4BitDitherBayer]

Ja ist Stabil ich weis aber nicht wie selten das ist? Ryzens aus einer später Prodution sind meistens um einiges besser siehe Ryzen 3600 Release und eol Ryzen 3600 der unterschied war enorm.

Glaub mir "wirklich stabil" CO-30 ist recht selten u. damit meine ich nicht das der jetzt schon bei dir 4 Monate ohne Absturz läuft oder so. Der sollte schon 48 Stündige Test Marathon mit Y-Cruncher N64, VST, VT3. oder ähnlichem hinter sich gebracht haben.
Sollte das der Fall sein solltest du den meiner Meinung nach direkt mit Board u. RAM zusammen verkaufen für (gutes Geld), u. dir einen "normalen" 5600 kaufen. Golden Sample sollte man scheinen lassen.
Da du seine Kapazität eh nicht voll nutzen willst solltest du ihn abgeben an jemanden der Freude daran hat mit ihm herum zu spielen u. ihn voll auszureizen.
Gerade der 5600 ist recht beliebt da er auch heute noch im Idle Stromverbrauch unerreicht ist bei den AMD Desktop CPU´s, die nach ihm erschienen sind.
Wenn er dann auch noch unter Volllast CO-30 Packt ist er sehr gefragt.

 

[Zornbringer]

ich bin neu bei diesem thema. habe nur eine kurze frage zum uv bei einem 5600x. ich habe eine weit verbreitete "standardeinstellung" genutzt, die ich in einem youtube guide gesehen habe. pbo limits disabled CO auf -30.

die cpu hatte ich bis jetzt immer im eco modus laufen. nun habe ich auf den ersten blick aber praktisch identische ergebnisse mit diesen uv einstellungen, zumindest in bezug zu takt, temp und verbrauch. habe ich was übersehen? erlaubt uv einen höheren takt bei multicore anwendungen im vergleich zum eco mode? kann mich da wer aufklären?

 

[Zornbringer]

nachtrag: es wird etwas kurioser.

ich bin mir absolut sicher, dass ich die cpu im eco mode habe laufen lassen, seit ich sie in betrieb genommen habe. nun hat jedoch mein monitoring tool angezeigt, dass im multi-core benchmark in cinebench 75w verbraucht werden. tatsächlich sollten es aber nur 60w sein.

ich habe die amd chipsatz treiber aktualisiert (komplett deinstalliert und frisch installiert) und habe das uv wieder in den eco mode geändert, weil ich in bf 2042 abstürze hatte. das spiel ist gerade neu und zum ersten mal installiert. der rechner kackt übrigens komplett ab. direkt neustart, obwohl automatischer neustart bei systemfehlern deaktiviert ist.

gut, eco modus ist aktiviert, 60w verbrauch im multi-core benchmark. spiel lässt den rechner trotzdem abstürzen, obwohl wieder alles bei den alten einstellungen ist.

windows ereignissprotokoll hat mir beim vorletzten absturz das hier gezeigt:

Schwerwiegender Hardwarefehler.

Gemeldet von Komponente: Prozessorkern

aber nicht beim letzten, kurioserweise. denn vermutlich ist ja irgendwas mit dem prozessor nicht in ordnung.

ich vermute so langsam, dass es ein software problem ist, denn ich kann cinebench ohne probleme über längere zeit sowohl im single- als auch multi-core benchmark laufen lassen. ich hatte sowieso ohne übertreibung noch nie abstürze dieser art auf diesem rechner.

falls jemand tipps hat, bitte her damit. also, ich bin quasi wieder bei meinen alten settings. eco modus, ohne weitere änderungen im bios, aktuelle chipsatz treiber.

nachtrag2:

scheinbar ist der eco mode der übeltäter?! ich habe testweise elden ring angeschmissen und auch das ist mir innerhalb kurzer zeit abgestürzt. habe nun amd overclock dingens im bios auf "ON" gestellt. bis jetzt läuft alles stabil.

ich versteh es nur nicht ganz, weil vorher alles absolut stabil im eco modus lief.

nachtrag3: CO auf -20 und alles stabil.

hier noch mal die chronologie in kurzform: eco modus ohne abstürze. CO -25 abstürze. zurück zu eco, nun aber mit abstürzen. overdrive ON ohne abstürze. CO -20 keine abstürze. so soll es erst mal bleiben.

 

[Sir Unreal]

Ich habe eine Frage zur Theorie dieser Thematik. Mein 5900X hat das Phänomen, dass in einem HEVC-Benchmark immer recht unterschiedliche Ergebnisse rauskamen. Also habe ich mir die CO-Thematik in diesem Thread angeschaut und als ersten schnellen Schritt All-Core -30 getestet (PPT/TDC/EDC ist deaktiviert). Stabilitätstest auf die Schnelle ohne Fehler, sprich Prime etliche Minuten fehlerfrei, OCCT 2 Minuten pro Kern fehlerfrei. Ausführliche Tests stehen noch an, aber an einem Punkt hänge ich aktuell: 1. HEVC-Lauf heute morgen nach Einschalten des PCs: 38m 36s, 2. HEVC-Lauf mittags: 58m 33s (Package-Temp ca. 70°C maximal), also ~50% langsamer, obwohl keine Änderungen gemacht wurden. Ist das temperaturbedingtes Core-Stretching und kann das so extrem ausfallen? Eben noch einen Lauf mit All-Core -20 durchgeführt: 56m bei 72,5°C max.

 

[Ayo34]

Das kann mehrere Gründe haben, ich glaube aber nicht das es Thema vom Curve Optimizer ist.

Wenn der erste Durchlauf nach dem einschalten immer deutlich schneller ist, dann sammeln sich im Laufe des Tages Hintergrundprogramme an, die laufen oder der PC ist deutlich wärmer? Vielleicht gibt es auch einfach Probleme beim Benchmark selbst, wenn er ohne Restart ein zweites oder drittes mal läuft? Weil Durchlauf 2 und 3 war ja fast gleich schnell und ein vierter wird ohne Restart auch wieder in dem Bereich liegen. Starte mal jetzt neu und mache den Benchmark. Bist du beim ersten Run dann wieder bei einem deutlich besseren Ergebnis?

In dem Fall ist der Benchmark selbst das Problem. Sollte nach einem Restart das Ergebnis wie bei Durchgang 2/3 sein, würde ich die Temperatur in Betracht ziehen. Hast du irgendwelche Limits gesetzt?

 

[Sir Unreal]

Danke für deine schnelle Antwort. Hintergrundprogramme sind in annähernd allen Fällen nicht das Problem, da Anwendungen lediglich RAM benötigen, aber keine CPU, wenn nichts getan werden muss. Ich hab zwischendurch den Firefox mit Youtube laufen, aber der schnappt sich 1,0 bis 1,5% CPU-Last, was auf den HEVC-Benchmark einen aktuell noch irrelevanten Einfluss hat - sprich erst dann, wenn es ums Feintuning geht. Der HWMon hat 0,2% Last, ein paar wenige Windowsprozesse haben 0,1%, alles andere 0%.

Limits habe ich keine gesetzt. Neustart wird aus Erfahrung nicht helfen, aber ich teste das morgen nochmal (aktuell kann ich arbeitsbedingt nicht neustarten). Aktuell läuft jetzt der CoreCycler. Könnte es sein, dass das Board eine bestimmte Stromstärke nicht schafft, wenn eine bestimmte Temperatur überschritten ist? Mir fällt übrigens auf, dass der CCD1 immer kühler ist als der CCD0, was wohl andersrum sein sollte, oder?

 

[Sir Unreal]

HEVC-Test (15 Minuten, 2160p) auf meinem 5900X @ all-core offset -30. Die Zeiten sind zu oben vergleichbar, sprich identischer Test:

1) PC lief einige Stunden, Neustart, keine Programme gestartet => 45 Minuten
2) ca. 1 Stunde Pause + Neustart nach Lauf 1, keine Programme gestartet => 34 Minuten 20 Sekunden
3) ca. 1 Stunde Pause nach Lauf 2, keine Programme gestartet => 36 Minuten 40 Sekunden

BIOS
PBO: Advanced
PBO Limits: Disable
Precision Boost Overdrive Scaler: Auto
CPU Boost Clock Override: Disabled
Platform Thermal Throttle Limit: Auto
Firmware: 2023/11/01 (aktuelle Version)
AGESA: ComboV2PI 1.2.0.B

Treiber
AMD Chipset: Version 5.08.02.027 (aus 08/2023, ganz neue Version vom 31.01.2024 teste ich später)

 

[WiP3R]

Was ist das den für ein Benchmark? Hast du da evt. Mal einen Link?
Du könntest den Benchmark nochmal mit @stock Einstellungen laufen lassen. Falls immer noch inkonsistente Ergebnisse auftreten ist mal nicht CO dafür verantwortlich.
(Für mich hört sich das eher wie ein schlechter Benchmark an. Teste doch mal andere Benchmarks gegen.)

 

[Sir Unreal]

Nein, CO ist definitiv nicht dafür verantwortlich. Ich hoffe eher das Problem mit CO lösen zu können - z.B. wenn die Temperatur ein Problem wäre.

Der "Benchmark" ist ein x265-Kodierungslauf mit dem Tool RipBot264, der ffmpeg verwendet zur Kodierung. Quellmaterial und Zielmaterial sind jedes Mal identisch. Ich würde erwarten, dass das Tool mit gleicher Quelle und gleicher Kodierungskonfig das Gleiche tut. Die fertige Zieldatei ist in jedem Fall aufs Byte identisch groß. Ich verwende diesen Benchmark, weil er praxisnäher ist als ein synthetischer Benchmark und ich dadurch einen Vergleich habe zur Performance meines vorherigen 3900X-Systems. Ein letzter Lauf gestern mit meinen typischerweise gestarteten Programmen (Firefox, VMware Player, darin Thunderbird und erneut Firefox) dauerte sogar 59 Minuten.

Heute mit Cinebench R23 getestet (jeweils in einem 10-Minuten-Durchlauf):
19555 - inkl. Citrix, VMware, Youtube
20750 - inkl. Citrix, VMware
20986 - inkl. Citrix, VMware
19581 - inkl. Citrix, VMware, Youtube

Das schaut besser aus, 6-7% Verlust durch Youtube, was aber laut Taskmanager nur 1-2% Last beansprucht. Ich teste weiter. Ich teste nun auch mit dem CoreCycler, ob -30 auf allen Cores vielleicht doch irgendwann Fehler wirft (bisher nicht).

 

[Ayo34]

Nur weil der Taskmanager 1-2% Last anzeigt, kannst du nicht davon ausgehen, dass der Rest dann 98-99% bringen muss. Die 12 Kerne skalieren nicht perfekt zwischen allen Anwendungen.

1. Youtube, Browsen und Co. haben ja nicht eine Dauerlast von 1-2% sondern eine stark schwankende Last. Wenn du z.B. etwas machst, lädst oder drückst, dann geht der Kern auf ~5000Mhz und ist kurzfristig voll ausgelastet und geht dann wieder zurück. Dann hast du auf einmal für den Benchmark noch 7 Kerne anstelle von 12 Kernen.

2. Jedes mal wenn das passiert und das passiert ständig, müssen die anderen Programme mit deutlich weniger Power auskommen und passen sich auch wieder an. Das ist einfach ein Wechselspiel, weil jeder Kerne eben immer nur eine Aufgabe ausführen kann und mehrere Aufgaben hintereinander ausgeführt werden.

3. Du weiß nicht wie gut dein Programm mit diesen Lastwechseln klar kommt und wie lange er braucht um wieder bei 100% zu sein. Cinebench kann es dann eventuell etwas besser, aber auch da wird du mit diesen Anwendungen niemals ein 98-99% Ergebnis bekommen können.

Das hat schon einen Grund, warum man einen Benchmark nach einem Neustart macht und ohne jegliche andere Programme um ein wertvolles Ergebnis zu bekommen. Selbst ein dummes Windows Update kann einen kurzen Benchmark mal komplett aus dem Rahmen fallen lassen.

 

[WiP3R]

@Sir Unreal , dann habe ich das nur falsch verstanden. Mit dem Anwendungsfall kenne ich mich leider nicht aus.

 

[Sir Unreal]

@Ayo34
Ich stimme dir grundsätzlich zu, aber das Zuweisen von Prozessorzeit durch das Betriebssystem ist nichts neues. Aber ja, wir wissen nicht genau, wie der Taskmanager die Auslastung mittelt und darstellt. Solange wir das nicht wissen, kann ich damit leben, dass aus dargestellten 1-2% echte 6-7% werden. Es erklärt aber nicht, wie eine andere Multicore-Anwendung um fast den Faktor 2 schneller/langsamer ist. Solange das OS für das Zuweisen von CPU-Zeit zuständig ist, sollte keine Anwendung derart aufgehalten werden. Und es war ja auch vorher mit dem 3900X nicht so, obwohl abgesehen vom RAM alles gleichgeblieben ist, also gleiches OS, gleiche Treiber, gleiche Rest-Hardware. Ich werde für weitere Tests das HEVC-Tool wechseln.

Übrigens CoreCycler nachwievor seit 7 Stunden bei einem Offset von -30 ohne Fehler.

 

[sp00n.82]

Video-Encoden verwendet je nach Programm und Einstellung ja zusätzlich auch die GPU und AVX(2), ohne also die Einstellungen und die Quelldatei zu kennen, kann das leider niemand nachvollziehen und auf dem eigenem PC nachstellen.
Beim CoreCycler solltest du die Settings auch entsprechend anpassen, standardmäßig ist dort AVX(2) ja deaktiviert. Es kann gut sein, dass deine Kerne -30 bei SSE packen, dann aber unter Belastung der AVX(2)-Bereiche im Chip aussteigen.

 

[4BitDitherBayer]

Es kann gut sein, dass deine Kerne -30 bei SSE packen, dann aber unter Belastung der AVX(2)-Bereiche im Chip aussteigen.

Das kann ich so bestätigen damit hatte ich früher auch Probleme Video-Encoden ist da recht anspruchsvoll.

Video-Encoden verwendet je nach Programm und Einstellung ja zusätzlich auch die GPU und AVX(2)

Das könnte auch ein Grund sein weshalb bei Sir Unreal die Encoding Zeiten Variieren.
Wenn man unter Verwendung der CPU u. GPU Encodet z.B. NvEnc. Hat man in der Regel keine Vorgabe Bitrate mehr in einem 2-Pas Mode.
Man hat dann einen Qualitäts Modus in dem versucht wird eine Konstante Qualität zu erreichen.

Dabei werden Filter Arbeiten wie Interlace-Erkennung, Farbraum usw. von der CPU übernommen u. das Ergebnis wird dann von der GPU zu einem Video verarbeitet.

Es kommt also auf das Zusammenspiel von CPU u. GPU an eine solche Konstellation ist viel anfälliger gegen Hintergrund Last als wenn man rein über die CPU Encodet.

Der CoreCycler hat mir dabei sehr geholfen meine CPU gegen Abstürze abzuhärten (19-ZN2 ~ Kagari)

 

[Sir Unreal]

Ich habe zusätzlich zum RibBot264 nun auch Handbrake im Test. Muss mich da aber erstmal reinfuchsen. Den Denoisefilter MDegrain hatte ich in meiner Beispieldatei tatsächlich im Einsatz. Die GPU ist eine AMD RX550, also kein encodingfähiges Gerät und im RipBot stehen alle Parameter entsprechend auf CPU und nicht auf GPU. Auch MDegrain wird im RipBot explizit unter CPU Denoise gelistet (während unter GPU Denoise "KNLMeansCL" angeboten wird). Der Avisynth-Aufruf schaut ebenfalls harmlos aus:

#Denoise
Loadplugin("C:\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
video=MDegrain1(video,super,bv1,fv1,thSAD=400)

Ich werde das weiter verfolgen, aber die Handbrake-HEVC-Einstellungen und speziell auch dessen Denoisefilter werden einiges an Zeit kosten und gehört wohl nicht hier ins Thema. Zumindest bei einem Test analog zu oben ohne Denoisefilter lag die Rechenzeit bei nur 23m 40s. Ich bedanke mich auf jeden Fall bei euch, dass Ihr so auf dem Windows-Hintergrundrauschen gepocht habt, das wird es dann wohl beim Encoding gewesen sein - speziell mit den Cinebench-Ergebnissen im Vergleich.

CoreCycler im AVX2-Mode lief bisher 1x durch. Ich lass den heute Nacht durchlaufen und editier das Ergebnis hier rein. EDIT: kaum geschrieben, da ist Core #3 weggeschmiert. Leider direkt per Systemreset.

 

[Sir Unreal]

3 Kerne -25, 9 Kerne -30. Das ist der Stand nach stabilen 14 Stunden CoreCycler@AVX2.

Der 5900X sitzt auf einem Asus B450-Board. RAM sind 2x 32 GB 3200@CL14. Kühlung erfolgt durch Arctic Freezer II 280 AiO.