Installiert.
Merklicher Unterschied: Fast Null.
Idletaktraten unverändert, Lasttaktraten/Spannungen/Leistungsaufnahme (sowohl angezeigte als auch gemessene) unverändert.
Das einzige was neu ist: HWMonitor zeigt bei geparkten kernen im IDle jetzt die 0,2v Spannung an die Roman auch bereits gemessen hatte. Ich tippe aber eher darauf dass das ein besseres Ausleseverhalten ist und nicht tatsächlich niedrigere Spannungen als zuvor im Idle, einfach weil das Strommessgerät im Idle genau den gleichen Wert anzeigt wie vor dem Update.
Schade, ich hatte gehofft dass der WHEA-Fehler beseitigt wird... die Idletaktraten sind mir persönlich wurscht da ich ohnehin seltenst im Idle bin.![]()
Wenn der 7-nm-Prozess nicht absolute Wunder bezüglich der Eigenschaften von Silizium vollbringt, dann liegen 0,2 V auf Niveau der Schwellenspannung oder sogar darunter. Das heißt so "versorgte" Kerne können keinerlei Rechenoperationen durchführen (respektive würden keine richtigen Ergebnisse liefern), selbst wenn man sie extrem langsam arbeiten lässt. Sie müssen also wirklich vollständig inaktiv/geparkt sein und dann hat die anliegenden Spannung kaum noch Einfluss auf den Verbrauch. Es fließen nur die Blindströme.
Es ist etwas ungewöhnlich dass ein Fehler der eine explizite CPU-Funktion (RDRAND() oder so ähnlich heißt die hier glaub ich) betrifft erst nach Release auffällt da die einzelnen Befehle der CPU doch ausgiebig getestet werden sollten. Aber was solls, kommt halt vor. Das sind die berühmten Kinderkrankheiten neuer Plattformen/Architekturen. In zwei, drei Monaten redet da keiner mehr von weil alles Wesentliche gefunden und behoben wurde über Updates.
Nur ganz selten sind Fehler so schwerwiegend dass sie ein dauerhaftes Problem darstellen oder werden erst Monate/Jahre später gefunden (oder beides wie im Falle von Spectre).
Im Gegensatz zu vielen anderen Befehlen gibt es bei einem Zufallszahlengenerator keine falschen Ergebnisse und soweit ich es verstehe besteht das Problem bei Ryzen 3000 darin, dass immer/oft die gleiche Zahl ausgegeben wird. Für Kryptographie-Tools eine Katastrophe, deren Ergebnisse wären kinderleicht zu hacken, und alle Anwendungen die mehrere verschiedene Zufallszahlen abrufen stoßen unweigerleich auf den "nur einmal in einer Gogol Jahre"-Fehler, dass sie zwei identische Zahlen erhalten die dann jede Menge Konflikte verursachen. Aber wenn man einfach nur teste, ob die Funktion eine Antwort liefert, merkt man von der fehlenden Zufälligkeit nichts. RDRAND wurde außerdem erst mit Ivy Bridge eingeführt und es gibt mittlerweile noch komplexere Generatoren für Zufallszahlen, wenn besonders hohe Qualität benötigt wird. Es nutzen also längst nicht alle Anwendungen den Befehl und zumindest Linux hätte wohl sogar einen Alternativpfad – der aber nur genutzt wird, wenn RDRAND einen Fehler zurückgibt. Kommt ein Ergebnis, wird mit der (unbrauchbaren) Zahl weitergerechnet.
. Ich bin wieder bei Ryzen 4000 bzw. Zen2+ bei der Musik, dürfte sich mehr lohnen
.