AMD Ryzen (Zen 1+2 only)

Ich habe mich jetzt dem Thema Ryzen und Windows vs. Linux Energieverbrauch nochmal intensiv gewidmet und die untenstehenden Ergebnisse gewonnen. Unterschiedliche Stabilität festzustellen war dabei eher ein Nebeneffekt.

Wen nur die Schlussfolgerungen interessieren, kann ganz zum Ende springen.

Wesentliche Testkomponenten
AMD Ryzen 5 1600X
Asus ROG Crosshair VI Hero
Asus ROG GTX 1080 Advanced
G.Skill Flare X DDR4-3200 CL14

Softwareversionen im Test
Asus BIOS 1403 (AGESA 1.0.0.6)
Windows 10 Version 1703
Fedora 26
Ubuntu 17.04
Prime95 Version 28.10 64-bit (sowohl für Windows wie auch für Linux von https://www.mersenne.org/download/)

Raumtemperatur war 26.3C bis 27.2C bei 50% Luftfeuchtigkeit während der Tests. Die CPU blieb immer unter 75C (Tdie) und damit weit entfernt von einer Drosselung, was die Ergebnisse in ihrer Vergleichbarkeit natürlich negativ beeinflusst hätte.

Testbeschreibung
Untersucht wurde der Stromverbrauch unter Windows und Linux im Idle und unter Last, wobei beim Lasttest alle drei Prime95 Tortue Tests ausgeführt wurden. Der Idle Verbrauch wurde 1 Minute nach Systemboot gemessen, wobei in Windows sichergestellt wurde, dass keine "großen" Hintergrunddienste wie Skype oder Steam laufen. Der Monitor war aus, um eine Beeinflussung durch unterschiedliche Standardhintergründe im Energieverbrauch zu vermeiden. Ebenso waren die Lüfter im BIOS auf ein Standardprofil fixiert, so dass höherere Drehzahl der Lüfter zu keinem höheren Stromverbrauch aufgrund mehr Abwärme führen konnte. Wobei hier angemerkt sei, dass wenn der CPU Lüfter hochdreht nur 1-2 Watt mehr in der Praxis verbraucht werden, was diesen Test unwesentlich verändert hätte im Ergebnis.

Die Prime95 Tests wurden immer in der Reihenfolge Blend, SmallFFT, LargeFFT durchgeführt, da normalerweise der Stromverbrauch erwartungsgemäß mit jedem Test steigen sollte. Die Tests liefen jeweils für 3 Minuten und der Stromverbrauch wurde auf ganze Watt gerundet. Gemessen wurde an der Steckdose mit Hilfe einer AVM Steckdose (FRITZ!DECT 200) über einen Zeitraum von 3 Minuten. Corsair Link könnte zwar unter Windows sehr zuverlässige Verbrauchswerte liefern, mir war aber keine brauchbare Alternative bekannt die unter Linux und Windows läuft und mir kam es darauf an, dass auf die gleiche Weise eine Verbrauchsmessung stattfindet.

Insgesamt wurden 5 Szenarien untersucht und die Ergebnisse beurteilt. Ergebnisse die unerwartete Abweichungen darstellen oder sonst irgendwelche Besonderheiten aufweisen sind in der Erläuterung rot gekennzeichnet.

Testszenarien
Scenario 0 ist das Referenzszenario mit Stock Einstellungen. Hier wird der Verbrauch in Watt des Gesamtsystems angegeben. In allen folgenden Szenarien wurde der abweichende Stromverbrauch gegenüber Scenario 0 angegeben und nicht der Gesamtverbrauch, entsprechend sind die Werte negativ.



Scenario 0 System Settings: DDR4-3200 @ 1.35V (Auto); SOC 1.15V (Auto); Vcore 1.45V (Auto) - Vcore XFR 1.50V (Auto) - Vcore Load 1.25V (Auto)

Aufällig ist, dass beim Asus Board die VCore by default auch ohne OC höher liegt als die AMD Spezifikation besagt. Dies sollte bei den weiteren Szenarien berücksichtigt werden, da mein negatives offset von einem von Asus standardmäßig angewendeten offset abzuziehen ist und nicht von der von AMD vorgegebenen Stock Voltage von 1.2 (Load) - 1.3625 V (Idle). Interessanterweise basiert der offset wohl auf einer Custom VID Table von Asus, da er im Idle knapp 0.10V beträgt und unter Last nur mehr 0.05V, da hier mit Auto Settings 1.25V erreicht werden. Bei XFR werden nochmal 0.05V raufgepackt. Mit dieser Erkenntnis relativiert sich die Aussage, dass ich mit undervolten ein System außerhalb der Spezifikation betreibe. Im übrigen ist DDR4-3200 schon außerhalb der Spezifikation ...

... daher habe ich mir in Scenario 1 mal die Mühe gemacht alles mit DDR-2400 durchzumessen.



Scenario 1 System Settings: DDR4-2400 @ 1.2V (Auto); SOC 1.05V (Auto); Vcore 1.45V (Auto) - Vcore XFR 1.50V (Auto) - Vcore Load 1.25V (Auto)

Anmerkung: Bei meinem Corsair Vengeance DDR4-3000 CL16 Ram den ich vorher hatte, hat das Bios auf SOC 0.8V gestellt wenn ich den RAM mit DDR4-2400 betrieben habe (was auch Prime stable war). Ich verstehe daher nicht warum die SOC Voltage hier so hoch ist und unterstelle, dass man hier deutlich niedriger gehen könnte. Es kann aber auch an einem zwischenzeitlichen Bios Update liegen, von demher ist der Vergleich mit Vorsicht zu genießen.

Hier fällt auf, dass der gesparte Strom im BIOS, Windows 10 Idle und Prime 95 Blend Test unter Windows 10 bei dem vor allem RAM getestet wird fast identisch ist. Aus meiner Sicht entspricht das auch dem erwarteten Verhalten, da es anders als bei CPU/GPU keine Stromsparfunktionen auf OS Ebene in Windows 10 für RAM gibt. Nicht zu erklären ist allerdings wieso dann in Fedora im Idle messbar weniger und im Blend Test messbar mehr Strom gespart wird (der Gesamtverbrauch bleibt jedoch in beiden Fällen in Linux deutlich höher).

In Scenario 2 bin ich dann wieder auf Standard RAM Einstellungen (Standard für diesen RAM) von DDR4-3200 zurück gegangen, habe allerdings die SOC Voltage fix auf 1V eingestellt (dem von AMD gedachten Standardwert). Asus arbeitet auch hier mit "Auto" mit einem ordentlichen positiven offset von 0.15V bei RAM OC, obwohl AMD in den eigenen Foren ja sagt das 1V und DDR4-3200 kein Problem sind mit Samsung B Die und AGESA 1.0.0.4 oder 1.0.0.6.



Scenario 2 System Settings: DDR4-3200 @ 1.35V (Auto); SOC 1.00V (Manual); Vcore 1.45V (Auto) - Vcore XFR 1.50V (Auto) - Vcore Load 1.25V (Auto)

Wie man sieht wird im Idle auf allen Ebenen nur sehr wenig Strom gespart und RAM innerhalb der von AMD vorgesehenen Spezifikation zu betreiben bringt mehr wie Scenario 1 zeigt. Auch hier lässt sich nicht erklären, warum sich unter Last die gesparte Energie unter Linux als deutlich höher erweist.

In Scenario 3 habe ich dann SOC wieder auf Auto gestellt und stattdessen VCore mit einem negativen offset von -0.125V undervolted. Windows habe ich die letzten Wochen mit einem noch größeren negativen offset stabil betrieben, dann bootet Linux allerdings nicht mehr, weshalb ich diesen bootbaren Wert als Grenze gewählt habe. Rückblick: Im Idle verwendet Asus mit Auto 1.45V, während AMD 1.365V vorsieht. Durch das offset erreiche ich 1,325V was entsprechend nur einem undervolting von 0.04V im Idle entspricht und nicht 0.125V wie die Einstellung vermuten lassen könnte. Unter Last lande ich 0.075V unterhalb der eigentlichen Spezifikation.



Scenario 3 System Settings: DDR4-3200 @ 1.35V (Auto); SOC 1.15V (Auto); Vcore negative offset -0.125V = 1.325V (Idle) - Vcore XFR 1.375V - Vcore Load 1.125V

Man sieht sofort, dass gerade unter Last die Einsparung ganz erheblich ist und auch im Idle diese Einstellung mehr bringt, als die SOC Voltage um 0.15V zu reduzieren. Noch viel auffälliger ist aber folgendes und hier kommt man der Sache mit den Instabilität unter Linux eventuell näher: Trotz massiver Einsparungen auf Bios und Windows Ebene benötigt Fedora Linux im Idle genau gleich viel Strom. Die 0 im Chart ist daher kein Fehler. Ich musste den Test auch mehrmals durchführen um es zu glauben. Der Prime95 Test war nicht durchführbar unter Linux, da das System schon beim Starten von Firefox abstürzt (Asus Q-Code 8 = CPU not operational).

Im letzten Scenario 4 habe ich die Einstellungen aus Scenario 2 und Scenario 3 kombiniert und noch eine weitere Linux Distribution neben Fedora hinzugezogen.



Scenario 4 System Settings: DDR4-3200 @ 1.35V (Auto); SOC 1.00V (Manual); Vcore negative offset -0.125V = 1.325V (Idle) - Vcore XFR 1.375V - Vcore Load 1.125V

Eine Idle Messung mit Fedora war hier nicht möglich, da bereits der Bootvorgang abstürzt (Asus Q-Code 8, s.o.). Ubuntu bootet zumindest auf den Desktop und spart dann ähnlich viel Energie wie Windows im Idle gegenüber der Referenzmessung. Starten von Firefox führt allerdings wie schon in Scenario 3 unter Fedora zu einem Systemcrash (ebenfalls Q-Code 8), weshalb auch unter Ubuntu kein Prime95 Test möglich war.

Windows läuft absolut stabil mit den Einstellungen (siehe Signatur wenn man nicht mobil auf oc.at zugreift) und das sogar mit noch niedrigerer VCore.


Schlussfolgerungen:

• Scenario 0: Ubuntu 17.04 enthält native Nvidia Treiber, was bei Fedora nicht der Fall ist. Bei Fedora hat der Nvidia Treiber auch Probleme gemacht. Damit erklärt sich m.E. der für Ubuntu niedrigere Verbrauchswert in der Referenzmessung gegenüber Fedora. Da der Unterschied im Stromverbrauch bei allen Tests zwischen Ubuntu und Fedora innerhalb von Messtoleranzen immer der gleiche ist, gehe ich hier nicht von besserer CPU Unterstützung aus, sondern es dürfte nur wegen der besser unterstützten Nvidia Grafikkarte strom gespart werden. Ungeachtet dessen benötigt auch Ubuntu wesentlich mehr Strom als Windows.
• Da Linux keine Probleme hat wenn ich nur RAM OC betreibe = DDR4-3200 (was außerhalb der Spezifikation von AMD ist), gehe ich davon aus das RAM hier nicht das Problem ist, wie es bei Ryzen zu Beginn oft der Fall war. Linux hat auch keine Probleme wenn ich die SOC Voltage von 1.15V auf 1.00V reduziere.
• Fedora hat meiner Ansicht nach Probleme die VID zu interpretieren und fährt möglicherweise eine falsche Voltage wenn ich mit einem offset arbeite, denn anders kann ich mir nicht erklären wieso Fedora im Idle gleich viel Strom verbraucht in Scenario 0 und Scenario 3, während im Bios und Windows deutliche Einsparungen (erwartungsgemäß) zu messen sind.
• Ja ich weiß, mit undervolting betreibe ich ein System außerhalb der Spezifikation. ABER: Windows 10 ist seit Wochen auch bei tagelanger Volllast (habe Excel Tabellen mit Power Queries die mehrere Tage laufen ohne jetzt hier ins Detail zu gehen und sowohl RAM wie auch CPU über Tage maximal auslasten). Von Linux hätte ich mir erwartet das es noch wesentlich stabiler und fehlertoleranter als Windows ist, da die ganze Background Bloatware nicht existiert. Ich sehe das Problem zwar schon auch bei AMD/Ryzen, der Linux Kernel ist aber vielleicht nicht ganz unschuldig. Windows musste ja auch erst angepasst werden, wenngleich Anpassung hier nicht heißt, dass vorher Windows massenhaft abgestürzt ist.
• TO-DO: VCore offset von -0.05V testen um zu prüfen ob Linux näher an der Spezifikation immer noch stabil läuft (Asus overvolted massiv mit Auto Settings, s.o.), was dann zu VCore 1.2V (Load) - 1.4V (Idle) führen würde und ggü. der Spezifikation nur einem leichten over(!)volting im Idle und Standard unter Load entspricht. ... (s.u.)

tbc und ich freue mich auf die weitere Diskussion Auf CPU RMA hätte ich echt keine Lust. Ist nicht so, dass ich hier lauter andere PCs als Alternative rumstehen habe

Edit Wie im TO-DO angekündigt und ich vermutet hatte läuft Linux mit Vcore offset -0.05V (hier Fedora) gerade noch so. Eine Stufe niedriger führt Prime schon zum sofortigen Crash. Heißt für mich eigentlich dass dauerhafter Betrieb nach AMD Spezifikation bei hoher Last nicht möglich ist.

passiert ja auch nicht unbedingt bei High Load (evtl gibts da noch Probleme mit versch. RAM unter diversen Linux Distris - da gibts das eine oder andere Indiz) sondern wenn man etwas kompiliert mit dem gcc

Ich vermute da auch keine echte Schuld bei AMD oder Hardwarebug sondern eben ein Compiler flag, nicht x86 konformes verhalten was bis jetzt halt durchging, nicht angepasste Treiber,...
Sonst hätte das auch auswirkungen unter Windows. Da kann man es aber auch nur im Linux Subsystem nachstellen

Dieser Post setzt https://www.overclockers.at/prozess...493#post3836493 fort.

Nachdem @Visitor mich darauf gestoßen hat, ich solle doch mal Default Settings ohne XFR probieren, habe ich mir das nicht zweimal sagen lassen und noch zwei weitere Szenarien bei meinen Messungen ergänzt die zu interessanten Ergebnissen führten.

In Scenario 5 habe ich gegenüber der Referenzmessung in Scenario 0 ausschließlich XFR deaktiviert.



Scenario 5 System Settings: DDR4-3200 @ 1.35V (Auto); SOC 1.15V (Auto); Vcore 1.15V (Auto) = XFR deaktiviert - Vcore Load 1.15V (Auto) - Vcore Idle 1.175V (Auto)

Wie von @Visitor schon angedeutet, ist die im Bios gemessene VCore dann statt 1.45V nur mehr 1.15V und damit sogar unterhalb der Spezifikation von 1.2V (Load) bis 1.365V (Idle). Nicht nachvollziehbar sind die Messergebnisse trotz mehrfacher Testwiederholung zur Verifikation im Vergleich zu Scenario 3, welches ich ebenfalls nochmal wiederholt habe um die Ergebnisse zu bestätigen (jeweils mit vorherigem Coldboot mit Load Optimized Defaults um Wertesetzfehler im Bios auszuschließen. Im Bios wird zwar Strom gespart ggü. Scenario 3, was bei VCore 1.15V vs. 1,325V (mit XFR an und undervolting offset -0.125V) auch zu erwarten ist, da die Voltage auch ohne undervolting viel niedriger ist. Unter Windows wird allerdings messbar mehr Strom verbraucht obwohl die CPU mit niedrigerer Voltage bei nur mehr 3,6 GHz läuft (ggü. 3,7 - 4,0 GHz in Scenario 3). Hat dafür jemand eine Erklärung?

Ebenfalls auffällig ist, dass der Vcore Unterschied zwischen Idle mit 1,175V und Load mit 1,15V nur mehr 0,025V beträgt und nicht 0,2V wie mit aktiviertem XFR und Auto voltages. Bei deaktiviertem XFR scheint also eine nicht linear vergleichbare VID Tabelle genutzt zu werden.

Da ich das technisch mögliche ausloten wollte, habe ich im Scenario 6 die verwendeten Voltages aus Scenario 4 übernommen und komme damit auf enorme(!) Energieeinsparungen ... ohne wesentliche Performanceverluste(!) muss ich einfach jetzt schon erwähnen (bitte weiterlesen).



Scenario 6 System Settings: DDR4-3200 @ 1.35V (Auto); SOC 1.00V (Manual); Vcore negative offset -0.125V = XFR deaktiviert - Vcore Load 1.075V - Vcore Idle 1.10V

Gegenüber der Referenzmessung (Scenario 0) wird unter Windows ~12% (Idle) bis ~17% (Load) Energie gespart. Auch ggü. Scenario 4 (SOC/Vcore undervolted mit XFR aktiviert) wird besonders bei Load nochmal deutlich Energie gespart. Interessant wird das ganze, wenn man die gesparte Energie gemeinsam mit den Benchmarkergebnissen vergleicht (s.u.).

Wie man sieht habe ich es in Scenario 6 auch geschafft Fedora Linux zu starten. Beim Start von Firefox allerdings das bekannte Problem Asus Q-Code 8 = CPU not operational und daher keine Prime95 Messwerte.

Ebenfalls lässt sich bei der Vcore wieder feststellen, dass Idle und Load ein Delta von nur 0.025V aufweist. Das Vcore offset von -0.125V führt allerdings nicht zu 1.15V - 0.125V wie am Messwert von 1.075V unschwer zu erkennen ist. Während das undervolting mit XFR ausgehend vom Asus Auto Wert 1.45V - 0.125V = 1.325V das erwartete Ergebnis produziert hatte, wird hier nun 1.2V (AMD Spezifikation) - 0.125V = 1.075V im Ergebnis erzeugt und der Asus Auto Wert scheint keine Rolle bei der Offset-Berechnung zu spielen. Ob das Zufall ist oder tatsächlich ausgehend von AMD Spezifikation gerechnet wird, kann ich nicht sagen. Ich habe mal Screenshots aus HWiNFO64 nach ca. 2 1/2 Stunden Prime95 LargeFFT angehängt.



Ich habe einige Benchmarks mit XFR an (Scenario 0) und XFR aus (Scenario 6) ausgeführt und komme zum Ergebnis, dass zumindest mit diesen Benchmarks im Wesentlichen keine Performanceverluste außerhalb von Messtoleranzen festgestellt werden können. Bei Spielen ist sogar eher noch ein Performancegewinn festzustellen. Die Ergebnisse mit XFR an (Scenario 0) stellen den 100% Wert dar. Die Ergebnisse mit XFR aus (Scenario 6) habe ich in % Abweichung vom Referenzwert dargestellt, damit eine Vergleichbarkeit von Messergebnissen in Punkten, fps etc. herstellbar ist. Damit man die Unterschiede überhaupt sieht, habe ich mir erlaubt den Chart bei 90% und nicht 0% zu beginnen



Schlussfolgerungen:

• Die Stabilität von Linux wird durch das abschalten von XFR nicht(!) positiv beeinflusst. Windows hält nach wie vor deutlich mehr aus.
• Performanceverluste ohne XFR existieren praktisch nicht. Zumindest in keinem der von mir getesteten Szenarien. Selbst der Cinebench R15 Single Core Benchmark liefert nur ein um 2% verschlechtertes Ergebnis, dem eine Energieeinsparung von über 15% gegenübersteht. Alle Spielebenchmarks sind dagegen eher noch schneller ohne XFR.
• Ich hatte in Scenario 0 in seltenen Fällen, aber besonders bei GPU Benchmarks, nicht eindeutig reproduzierbares Stuttering (Frame Drops?). Dies hatte ich auf die Nvidia Treiber bzw. Grafikkarte zurückgeführt. Es stellt sich allerdings heraus, dass dieses Stuttering ohne XFR noch nicht aufgetreten ist und gerade im Tomb Raider Benchmark dadurch eine höhere min. FPS erkennbar ist, was dann auch wesentlich zum besseren Gesamtergebnis beiträgt.

Ich habe nun mit Scenario 6 meine neuen Settings gefunden und passe meine Signatur gleich an . Im Nachhinein Frage ich mich, wieso ich das mit XFR nicht schon vorher gemacht habe. Bei Intel hatte ich den Turbo immer im Bios deaktiviert, da für minimal mehr Leistung der Energieverbrauch der Intel CPUs enorm viel höher war (der Unterschied war noch viel krasser als bei AMD mit und ohne XFR) und von daher ist es nun nur konsequent auch XFR zu deaktivieren wo es doch scheinbar eh nichts bringt.

Edit: Noch ein Hinweis zu den Bencharmks. Diese wurden mit GPU @ Stock durchgeführt. Normalerweise habe ich die GPU massiv undervolted und mit normalem Takt (die GPU ist von Asus by default übertaktet) betrieben, da dies eigentlich für alles was ich mache ausreicht.

-27 Watt gegenüber Stock sind in der Tat heftig, weswegen ich aufgrund der Benchmark Ergebnisse XFR nun auch erst mal auslasse, da ich ohne XFR auch noch viel stärker undervolten kann (auf 1.075V Vcore eben).

Der Takt wird nur gesenkt, wenn Tctl 95C erreicht wird, sonst bleibt er normalerweise wie er ist im AMD Balanced Power Profile. Eine Tctl von 95C kann ich ohne übertakten / overvolten nicht erreichen.

Ich arbeite in Windows mit AMD Ryzen Balanced Power Profile, dabei Verhält sich die Taktrate wie folgt:

Mit XFR
Idle: 3,7 GHz und springt immer mal auf 4 GHz
Max. Load: Dauerhaft 3,7 GHz

Ohne XFR
Idle: Dauerhaft 3,6 GHz
Max. Load: Dauerhaft 3,6 GHz

Eventuell sind die Mikroruckler bei Spielebenchmarks (um es zu präzisieren, beim Spielen selbst habe ich noch keine bewusst wahrgenommen, man sollte das "Problem" also nicht überbewerten) tatsächlich durch das hoch und runtertakten auf 4 GHz erklärbar, da Spiele ja nie alle Cores max. auslasten und entsprechend XFR Boost noch aktiv ist. Mich erstaunt trotzdem vor allem das gute abschneiden ohne XFR im Cinebench Singlethread Benchmark, weil 2% Performanceverlust ist nix im Vergleich zu Taktverlust von bis zu 10%.

Ein tatsächliches runtertakten wie man es von Intel Speedstepping kennt, gibt es im AMD Balance Power Profile unter Windows allerdings nicht. Erst wenn ich aufs Energiesparprofil umstelle wird auf 2,2 GHz runter getaktet. Energieeinsparungen sind dadurch aber kaum feststellbar, weshalb ich aus Performancegründen das AMD Balanced Power Profile verwende. Ich teste das nochmal ausführlicher.

Ich habe aber in der Tat nicht bedacht, dass dieses Verhalten unter Linux wirklich anders sein könnte. Gibt es denn keine Tools wie CPU-Z, Coretemp etc. unter Linux (speziell Fedora oder Ubuntu)? Ich habe lm_sensors versucht, das findet allerdings keinerlei auslesbare Sensoren.

Edit:

AMD Balanced Power Profile (Windows 10)
Die VID = von der CPU angeforderte Spannung wird im Idle mit 0.85V ausgelesen
Die tatsächliche Vcore liegt mit Scenario 6 bei 1.10V und der Takt beträgt dann dauerhaft 3,6 GHz

Balanced (Windows 10)
Die VID wird hier mit 1.20V wesentlich höher ausgelesen
Die tatsächliche Vcore liegt mit Scenario 6 aber nur bei 0.725V und der Takt beträgt dann nur mehr 2,2 GHz

Der Stromverbrauch sinkt im Balanced Profile im absoluten Idle (welches unter Windows 10 im Normalbetrieb mit Steam, Skype etc. offen nicht existiert) um bis zu ~1-2 Watt. Da ich gelesen habe, dass es dadurch Performanceprobleme geben soll und selbst bei minimaler Grundlast keine Energie gespart wird, nutze ich das AMD Balanced Power Profile.

Also nochmal ... wer kann mir ein Tool für Ubuntu oder Fedora nennen, mit dem ich zumindest Takt und idealerweise Vcore auslesen kann? lm_sensors funktioniert ja leider nicht.

in dem thread war mal was von einem "compiler bug" zu lesen... ?
ich stell das jetzt mal so rein, ohne mich damit beschäftigen zu wollen.

http://www.phoronix.com/scan.php?pa...fixed&num=1
ein cpu tausch soll abhilfe schaffen.

Du hast aber genauso keine Garantie, dass du bekommst was du willst und 5* zurückschicken wird dich Amazon auch fragen was los ist.