Energiesparplan Zen2/Zen3 (Ryzen 3000/5000)

[MotherPink]

Ich bin letzte Nacht bald verrückt geworden. Keine Ahnung, was Mozilla am neuen Firefox geändert hat, aber das Verhalten ist äußerst seltsam.

Laut Mozilla wurde primär die GPU-Last im Webrenderer minimiert, aber mir scheint, das letzte Update, hat die VP9 Hardwaredecodierung deines Firefox zerschossen.
Da meine RX 580 eh kein VP9 beherrscht und ich Softwaredecodierung im Browser prinzipiell vorziehe, kommt hier mal ein Schwung an Daten von mir.

Costa Rica die ersten 40 Sekunden, keiner der Durchläufe hatte auch nur einen Framedrop:

Erstmal wird die V4 der ollen V3 und AMDs Ryzen Balanced gegenübergestellt:
Firefox AMD Ryzen Balanced | Firefox V3 | Firefox V4
2160p60
1440p60
1080p60
Man sieht, dass die V4 durchweg besser abschneidet, obwohl der Nutzen mit sinkender Auflösung gegenüber der V3 stetig abfällt. AMD Ryzen Balanced wird komplett deklassiert.

Um zu sehen, wie stark der Browser Einschlag ist, habe ich Firefox V4 mit Chromium V4 verglichen:
Firefox V4 | Chromium V4
2160p60
1440p60
1080p60
Chromium scheint die Teillastschwelle selbst in 4k nicht zu überschreiten, verliert dann aber in den niedrigeren Auflösungen, in denen Firefox ebenfalls zumeist im Teillastbereich bleibt, knapp.

Im Energiesparmodus sieht es ähnlich aus, Firefox schlägt Chromium knapp:
Firefox ESM | Chromium ESM
2160p60


Da V4 durchweg am besten abgeschnitten hat, wird lediglich dieser mit dem ESM verglichen.
In 4K hab ich noch die Chromium V4 Kurve hinzugefügt, da dies der einzige Fall war, indem Chromium vor Firefox lag:
Firefox V4 | Chromium V4 | Firefox ESM
2160p60

Firefox V4 | Firefox ESM
1440p60
1080p60
Abseits von 4k60 liegt die V4 mit Firefox keinen Watt mehr entfernt vom ESM.
In 4k60 besteht noch knapp über ein Watt Abstand von V4 mit Chromium und ESM mit Firefox, welche jeweils die Bestwerte für Auflösung/Plan/Browser darstellen.

 

[Tobse80]

@Tapion3388

Weiter oben hatte ich Screenshots drin. im Bios: AMD CBS > NBIO Common Options > SMU Options

CPPC (Preferred Cores)
DF cStates
EfficiencyModeEn

Diese Optionen findet man, zumindest beim Prime X470 Pro, nur mit einem ModBios.

Hab seitdem eigentlich auch nur das Verändert, was ich einstellen konnte. So wurde es hier oder im Luxx geschrieben

 

[Tapion3388]

@Tapion3388

Weiter oben hatte ich Screenshots drin. im Bios: AMD CBS > NBIO Common Options > SMU Options

CPPC (Preferred Cores)
DF cStates
EfficiencyModeEn

Das Menu gibt es leider bei meinem Board auch nicht (wie Hopie schreibt), die Crosshair-Boards scheinen da etwas besser aufgestellt zu sein... Vielleicht tut sich mit AGESA 1.0.0.5 etwas, vorausgesetzt das kommt für mein Baord.

 

[sz_cb]

Gibt es einen Grund warum die minimale Processorlast hier bei 90% liegt, hab die manuell immer auf 5% damit die CPU bei 2GHZ Idelt und nicht bei 3 irgendwas.

Wie @Tonks bereits sagte, energetisch bringt es bei Ryzen3000 nix, die Taktfrequenz unter 90 % zu senken. Die Spannung erreicht ihr Minimum bei 90 % und dem geparkten Kern ist es egal, welche Taktfrequenz vor dem Parken anlag.


@MotherPink
Herzlichen Dank für Deine Tests!
Ich werde Deinen Beitrag mal im Startpost verlinken

BTW: Vorhin gab es ein erneutes Firefox-Update. Mal sehen, ob sich mein Problem bereits erledigt hat.

 

[LGTT1]

Von der Effizienz des Profils bin ich bereits überzeugt wenn ich bei geöffneten Firefox (kein Video) und Ryzen Master nur das Energiesparprofil von V4 auf 1usmus balanced umstelle springt die Temperatur innerhalb einer Sekunde sofort um ca. Grad in die Höhe und bleibt auch dort, damit hat sz_cb wohl wirklich recht und die "besten Kerne" sind auch bei mir am hungrigsten [was vermutlich daran liegt das die höher Boosten dürften und dafür dann wiederum höhere Spannungen nötig sind] faszinierend wie mächtig so ein Profil ist, oder wie komplex die Leistungsregulation der Ryzen 3000 ist. Ist es eigentlich möglich das Profil so zu konstruieren das wenn das PPT länger sagen wir mal bei einem bestimmten höhren % Bereich liegt wie z.B beim gaming oder transcoding wäre, automatisch wieder die "Hochleistungskerne" bevorzugt werden? Sozusagen das beste beider Welten Effizienz wenn möglich, Gewalt wenn nötig. Aber zugegebener Weise habe ich euer Profil ausprobiert weil mir die springenden Temperaturen beim anschauen eines Videos oder beim Emails checken auf die Nerven gingen und dafür ist es Perfekt.

 

[sz_cb]

[..]
Ist es eigentlich möglich das Profil so zu konstruieren das wenn das PPT länger sagen wir mal bei einem bestimmten höhren % Bereich liegt wie z.B beim gaming oder transcoding wäre, automatisch wieder die "Hochleistungskerne" bevorzugt werden? Sozusagen das beste beider Welten [..]

Wie ich schon schrieb: Das passiert durch den Windows Scheduler automatisch und eigentlich auch recht zuverlässig. Wenn Du bspw. eine sehr hohe Auslastung eines einzelnen Threads hast, wird automatisch der performanteste Kern genommen. Das kannst Du gut mit irgendwelchen Benchmarks prüfen (bspw. Cinebench R15 oder R20 mit Begrenzung auf einen Thread). Im Unterschied zu 1usmus' Plan wird aber nicht in jeder beliebigen Situation (also auch die mit geringer Auslastung) darauf bestanden, zuerst den performantesten Kern zu nutzen, denn nur weil die anderen Kerne nicht als "die performantesten Kerne" deklariert sind, sind sie ja nun auch nicht von Grund auf mies.

Man kann dem Scheduler übrigens auch sagen, er soll zuerst für die effizientesten Kerne planen. Das kostet (bei mir) aber etwas Performance. Und: Bei geringen Lasten hat es keine (energetischen) Vorteile gegenüber der automatischen Wahl.

 

[LGTT1]

Ich bedanke mich die Auskunftsfreude ist ja hier genau so toll wie bei der RAM OC Community. Sehr schön dann behalte ich mal das Thema im Blick und freu mich schonmal über die Energieersparnis und auf die evtl kommende Versionen^^. Die ja vermutlich zumindest solange kommen bis der TE 100% zufrieden ist (passiert selten aber geschieht) oder er einen anderen Prozessor erwirbt.

 

[MotherPink]

Wobei es hier tatsächlich eine Untergrenze gibt.
Wie weit kann man runter bis die Responsivität und Maximalleistung des Systems spürbar leidet.
V3 und V4 scheinen mir schon sehr nah am Optimum.

 

[sz_cb]

freu mich schonmal über die Energieersparnis und auf die evtl kommende Versionen^^

Wobei es hier tatsächlich eine Untergrenze gibt.

Prinzipiell bin ich mit dem V4-Plan schon ziemlich zufrieden, da er bei geringen CPU-Lasten dem Energiesparmodus sehr nah kommt und im Leerlauf sogar unterhalb des ESM landet, ohne auf die "Agilität" des Energiesparmodus zurückzufallen.

Was mich noch etwas beschäftigt, ist das CPU-Verhalten bei höheren Lasten (bspw. in Spielen). Hier liegt V4 verbrauchstechnisch auf einem Level mit den AMD- und 1usmus-Plänen. Hier muss ich bei Gelegenheit mal testen, ob man mit einer noch etwas aggressiveren Vorgehensweise eventuell dem Energiesparmodus näher kommen kann, ohne dessen Verschlechterung* der Performance hinnehmen zu müssen. Ich fürchte jedoch, dass das Eine nicht ohne das Andere gehen wird. Na, mal sehen

* = Der Ingame-Benchmark von Shadow of the Tomb Raider dauerte mit dem ESM 30 Sekunden länger, weil das Laden des Benchmarks bzw. der unterschiedlichen Sequenzen deutlich langsamer ablief. Die resultierenden durchschnittlichen FPS waren jedoch gleich (klares GPU-Limit).

 

[MotherPink]

Das ideale Szenario wäre, wenn im GPU-Limit der Verbrauch ähnlich dem des ESM wäre und abseits davon lediglich die Engine bzw. das PPT die Grenze darstellt.
Die sz_Pläne verhalten sich bereits jetzt teilweise so, wenn die Last gering ist und auf viele Threads verteilt werden kann, aber es gibt nach wie vor zu viele Situationen, in denen der Verbrauch, trotz klarem GPU-limit, eher an den Ryzen Balanced erinnert.

Ob dieses Idealszenario mit den verfügbaren Mitteln überhaupt erreicht werden kann, ist fraglich.
ESM erreicht das Ziel auch nur durch Stur schalten und ein folglich absolut gesenktes CPU-Limit, welches jedoch, je nach relativem GPU-Limit, nicht auffällt.

Der Ingame-Benchmark von Shadow of the Tomb Raider dauerte mit dem ESM 30 Sekunden länger, weil das Laden des Benchmarks bzw. der unterschiedlichen Sequenzen deutlich langsamer ablief.

Sobald Assets geladen, bzw. in modernen Titeln gestreamt werden müssen, bricht der ESM schnell weg, oder produziert frenetische Frametimes. Dedizierte Ladezeiten sind folglich prinzipiell länger.
ESM kann sich jedoch für ältere Spiele lohnen, da diese sich auf statische Speicherbelegung beschränken und die 2,2 GHz stets ausreichen die GPU (Vsync/FPS-Limit) zu füttern.

 

[sz_cb]

@MotherPink
Die Frage (für mich) ist: Wenn die Schwelle zum Hochtakten noch höher liegen würde, sodass die Kerne länger bei den 90 % Takt mit geringerer Spannung verblieben, ob sich damit der Verbrauch senken ließe, aber die Performance trotzdem noch in der Nähe der AMD-Pläne wär. Der im Vergleich zum ESM höhere Kerntakt sollte zumindest verhindern, dass das System träge wird.
Das ist das, was ich noch testen will.

 

[Pizza!]

Beim Energiesparmodus gehts ja auf 2,2 Ghz fest und viele geparkte Kerne runter, bei allen anderen Plänen nicht.
Kann man da einen Plan der dazwischen ist basteln, z.B. 2,2 GHz auf die Hälfte der Kerne, Rest geparkt und bei starker Belastung dürfen die Kerne wieder höher gehen?

Oder ein ESM (idle) + 1usmus (starke blastung) in einem Plan?

 

[sz_cb]

@Pizza!
Der Energiesparmodus kann in Spielen energetisch davonziehen, weil er eine arg hohe Hemmschwelle hat. Die 2200 MHz des Energiesparmodus' machen die CPU nicht zwingend sparsamer, aber mit Sicherheit langsamer. Folge davon ist, dass die Responsivität im Desktop deutlich leidet. Das sollte nicht das Ziel sein. In der Praxis nerven mich beim ESM u.a. die deutlich verzögerten Programmstarts - da brauche ich keine modernen Komponenten, wenn sich der PC in meinem Alltag so verhält, als hätte er Teile von vor 15 Jahren verbaut.


BTW: Der ESM ist im Idle nicht sparsamer als die Ryzen-Pläne, weil der ESM die Kerne später parkt. Hier mal eine frische Grafik (10 Minuten Leerlauf, Aufnahmetaktung: 4000 ms):

Mal von den Peaks beim ESM abgesehen, sieht man recht deutlich, dass der ESM hier durchweg einen höheren Verbrauch hat (der V4-Plan ist hier exemplarisch für fast alle Ryzen-Pläne). Der Verbrauch des gesamten CPU-Packages bei V4 liegt unterhalb des reinen CPU-Verbrauchs des ESM.

Der ESM ist im Leerlauf nur dann (energetisch) sinnvoll, wenn im Hintergrund diverse Programme aktiv sind, die die CPU nicht zur Ruhe kommen lassen.

 

[Duvar]

Meine idle Power droppt auf bis zu unter 8.7W^^

 

[ThommyDD]

An die Linux-Nutzer - wisst ihr ob es passable Tools für die Einstellung von Energiesparplänen für Linux/Ubuntu gibt? Ich finde nichts Gescheites. Ich frage mich auch, was die Einstellungen im BIOS dann unter Linux/Ubuntu für Auswirkungen haben. Will hier eigentlich nicht ins Blaue testen.

Auf meinem ThinkPad mit Intel-CPU nutze ich tlp von linrunner. Ich weiß nicht, ob das für Nicht-ThinkPads und/oder AMD-Prozessoren auch funktioniert, aber vielleicht wäre das als Ausgangsbasis geeignet, um sich was zu basteln.

 

[Salamimander]

Du brauchst ein ACPI Tool für Linux, notfalls selber basteln

 

[xxlrider]

@MotherPink
Die Frage (für mich) ist: Wenn die Schwelle zum Hochtakten noch höher liegen würde, sodass die Kerne länger bei den 90 % Takt mit geringerer Spannung verblieben, ob sich damit der Verbrauch senken ließe, aber die Performance trotzdem noch in der Nähe der AMD-Pläne wär. Der im Vergleich zum ESM höhere Kerntakt sollte zumindest verhindern, dass das System träge wird.
Das ist das, was ich noch testen will.

und was wäre wenn man sagen wir zb. 4 oder 6 Kerne abschaltet,und erst bei starker Last zuschaltet ?
Wäre das sinnvoll ?

 

[sz_cb]

Hätte jemand Interesse an einer (noch inoffiziellen) "szESMv1 beta"? Der Plan ist von Grund auf neu gestrickt. Die Änderungen sind v.a. bei etwas größeren Teillasten gravierend, aber ich habe nicht genügend Software (bspw. Spiele), um das ausreichend zu testen, bevor ich es auf die Allgemeinheit loslasse Der Titel des Plans ist aber Programm: ESM. Es gibt momentan noch geringfügige Leistungseinbußen im MultiCore (CB R15: 2043 szESM; 2056 AMD RB). Dafür sinkt der Verbrauch beim In-game-Benchmark von Shadow of the Tomb Raider auf etwa 2/3. Bei Videos liegt der szESM annähernd auf Augenhöhe mit dem Windows ESM. Im (echten) Leerlauf ist der szESM auf dem Level der anderen Ryzen-Pläne. Im Leerlauf einiger PCs mit viel Hintergrundlast sollte er sparsamer als die bisherigen Pläne sein.

Edit: Ich kann mich bereits korrigieren bzgl. der Performance. Offenbar gibt es einen Bug im Windows Scheduler. Der fiel mir im CPU-Test von 3DMark (Time Spy) auf. Während alle Sparpläne annähernd gleich auf lagen, lagen szESMv1 und 1usmus gemeinsam mehrere hundert Punkte dahinter. Ursache war/ist eine Planungsrichtlinie für Threads mit kurzer Laufzeit. 1usmus' Plan und mein szESM gaben die Anweisung, für die leistungsfähigsten Kerne zu planen - haha! Das ging dann wohl ordentlich nach hinten los Ich hab's geändert und die Performance des szESMv1 ist nun also wieder auf Augenhöhe mit den anderen - am Verbrauch ändert es glücklicherweise nichts



@Duvar
Wieso ist bei Dir das Minimum bei Package Power niedriger als das Minimum bei PPT? Verrückt.
Die 9er Marke konnte ich noch nicht knacken. Nicht schlecht

und was wäre wenn man sagen wir zb. 4 oder 6 Kerne abschaltet,und erst bei starker Last zuschaltet ?

Parken ist ja quasi abschalten. Es bedarf "nur" einer Hand voll gut aufeinander abgestimmter, halbwegs universeller Zahlen, um die CPU bzw. Windows erkennen zu lassen, ab wann eine "starke Last" eine starke Last ist. Und natürlich: Ab wann ist es bei einer nicht so starken Last vielleicht doch nützlich, wenn die CPU hochtaktet?

 

[Duvar]

Hab mich noch verbessern können, hab jetzt mal 6.5 Std mitgeloggt und habe Größtenteils Youtube geguckt.
Nachdem ich nun VDDP/VDDG auf 750mV reduziert habe, habe ich noch den Verbrauch weiter drücken können auf UNTER 7.5W^^

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Edit: Auf jeden Fall ein fettes Dankeschön für den Plan bzw Pläne. Seitdem ich den in den mittlerweile verschiedenen Versionen installiert habe, konnte ich meinen min Idle Verbrauch ~ locker HALBIEREN^^ (natürlich auch den AVG Verbrauch deutlich gesenkt) Geht da noch was?^^

Edit 2:

Was interessant ist:

"Verbrauch weiter gesenkt durch reduzieren von VDDG/VDDP auf 750mV im Vergleich zum anderen Video von mir locker 10% Reduktion des Verbrauchs, nur mit dieser Maßnahme."

Mit dem anderen Video meine ich nicht das was ich kurz vorher gepostet hatte, sondern den exakt selben Benchrun (auf meinem Youtube Kanal), aber da war es mit CLDOVDDG 950mV und CLDOVDDP auf 900mV

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[MotherPink]

Hätte jemand Interesse an einer (noch inoffiziellen) "szESMv1 beta"?

Sicher!

Nachdem ich nun VDDP/VDDG auf 750mV reduziert habe

VDDP läuft bei mir problemlos mit 700mV, aber die VDDG Spannungen sorgen bei mir unter 845mV für Ton und ab 835mV für Leistungseinbrüche.
Die 7,5 Watt im Idle sind schon beeindruckend für Matisse, auch wenn mich die PPT Diskrepanz noch etwas verwundert.