Destiny 2 už funguje
Už v pondělí jsme tu měli zprávu o tehdy ještě jen polooficiálním testovacím ovladači pro čipsety AMD, který obchází chybu v Destiny 2. Včera tento ovladač firma vydala oficiálně jakožto už standardní vydání 1.07.29. Stahovat přímo z webu AMD můžete tímto odkazem. Stejně jako předchozí polooficiální verze dovoluje spustit tuto hru, která předtím na Ryzenech 3000 „Matisse“ padala během startu.
Řešení vysokých taktů a napětí při nečinnosti
Součástí tohoto ovladače jsou ale nyní i další změny. Měl by řešit nebo zlepšovat problém, který se minimálně části uživatelů projevuje v nečinnosti, tedy například na ploše Windows bez zátěže. Ačkoliv by v takovém případě CPU mělo běžet v úsporných režimech a taktech, řada uživatelů hlásila, že jim Ryzen 3000 místo toho zůstává na vysokém taktu a napětí, jako při jednovláknovém turbu. Nová verze ovladačů obsahuje na pomoc před tímto jevem nové nastavení řízení spotřeby pro Windows, tzv. AMD Ryzen Balanced power plan. Nepleťte si ho s tím, který dříve AMD vydalo pro Ryzeny generace 1000, ten již není pro starší Ryzeny na aktuální verzi Windows 10 třeba a můžete místo něj používat normální plány ve Windows. Ovladač 1.07.29 přináší jiný „Ryzen Balanced“ plán, která má specificky upravovat fungování jen na Ryzenu 3000, aby předcházel vysokému napětí a frekvencím v nečinnosti.
V čem tento problém byl? Podle AMD je problém vysoké frekvence a napětí v nečinnosti mimojiné problémem měření. Údajně ho způsobují (nebo aspoň částečně) diagnostické nástroje jako HWiNFO nebo třeba utility od výrobce desky, které monitorují frekvenci a napětí. Pokud takový program spustíte (a ještě horší má být, pokud jich běží více), tyto programy probouzejí jádra velmi často (podle Roberta Hallocka až na 20 ms každých 200 ms). U Ryzenu 3000 má turbo značnou agresivitu ve snaze dodávat co nejlepší responzivnost a výkon v úlohách typu webového prohlížeče, kde je zátěž nárazová a může trvat jen krátce.
Diagnostické programy nemusí ukazovat frekvence a napětí správně
Ovšem diagnostické programy při zjišťování napětí a frekvence pro tento algoritmus turba vypadají jako taková aplikace a jejich přístup proto jádra provokuje k turbu – které používá ono vysoké napětí. Podle AMD tedy ony stavy CPU jsou způsobené často právě tím, že je zkoušíte sledovat, a pokud byste monitorovací program nespustili, měly by být normální, jako na předchozích procesorech. Výjimkou je snad CPU-Z, které by v aktuální verzi prý Ryzen 3000 „vytáčet“ do turba nemělo.
Kromě toho, že monitorovací aplikace samy vyprovokují turbo, také tyto programy nemusí ukazovat frekvenci přesně – Ryzen 3000 dokáže měnit frekvenci až každou 1 ms, takže programy sledující s mnohem menší granularitou nemusí vůbec zaregistrovat, že se mezitím jádra přepnula na nižší takty a chybně ukazovat, že je CPU ve výkonném režimu. Kromě Ryzen Masteru také žádný jiný program neumí poznat, že je jádro v úsporném stavu CC6 (0 MHz/0,2 V). Místo toho pak může ukazovat pořád poslední známé frekvence/napětí vstupem do CC6.
Stavy CC6 (Sleep) v programu Ryzen MasterAMD Ryzen Balanced power plan
Je možné, že toto bude AMD zkoušet ladit i v budoucích AGESA a mikrokódech, ale prozatím situaci má řešit právě nový Ryzen Balanced power plan (česká Windows by řekla schéma napájení). Jak už bylo řečeno, ten je potřebný jen pro Ryzeny 3000 (asi mimo APU Ryzen 3 3200G Ryzen 5 a 3400G), na starších Ryzenech ho instalátor zřejmě ani nenainstaluje. Současně AMD také vydává aktualizace softwaru Ryzen Master (2.0.1.1233), který by také měl být přizpůsobený této problematice.
AMD Ryzen Balanced power planV čem oprava spočívá? Nový Ryzen Balanced power plan nastavuje jako frekvenci CPU, kterou mají Windows použít v klidu nebo při mírné zátěži, 99 % základního taktu. Zároveň při nízké zátěži nebo nečinnosti není zapnuto rychlé přepínání frekvencí po 1 ms, ale granularita je snížená na tradiční pomalý krok po 15 ms. Napětí by se mělo typicky pohybovat do 1,2 V. Jen když je detekována vyšší zátěž a CPU je v turbo režimu, začne se používat rychlé 1ms přepínání frekvencí.
Toto by mělo zabránit situaci, kdy nízké zátěže provokují procesor zbytečně do turba. Je ale možné, že se může trošku zhoršit třeba rychlost načítání aplikací a reakce v programech (třeba těch benchmarcích webových prohlížečů) během oněch prvních 15 ms, které z agresivního turba dosud těžily. Mimochodem: to, že takt v nečinnosti je pořád docela vysoká základní frekvence, by něělo vést k vysoké spotřebě, protože CPU při nečinnosti používá ony úsporné režimy jako CC6 a může do nich neustále docela rychle přecházet.
Takto by se měla chovat frekvence při použití schématu napájení AMD Ryzen Balanced power planOpravy v AGESA 1.0.0.3ABB: RdRand a chyby WHEA Event 17 v logu Windows
Zatímco tento ovladač čipsetu je dostupný teď hned, další opravy ještě budou chvíli trvat. AMD oznámilo, že chybu, který způsobuje pád Destiny 2, ale zároveň také rozbila systemd/Linux, definitivně opraví až nové BIOSy pro základní desky, které budou založené na verzi AGESA 1.0.0.3ABB (či 1003ABB). Stejný workaround, který ve Windows opraví Destiny 2, totiž pochopitelně neopraví Linux „out-of-the-box“ (je však možné opatchovat systemd, například Mageia vydala speciální vydání, které na Ryzenu 3000 funguje).
Skutečné řešení chyby v RdRand bude tedy až přes BIOS, po čemž už workaroundy nebudou třeba. Tyto opravné BIOSy od výrobců základních desek v tuto chvíli ještě k dispozici nejsou, AMD uvádí, že tito teprve ještě musí dokončit testování a validaci. Údajně by to mohlo typicky trvat „pár týdnů“, takže úplně brzo se tyto opravy čekat nedají, ale snad by se mohly objevovat řekněme během druhé poloviny srpna.
I pokud vás Linux netrápí, je tu ještě jedna věc, kterou vám tato AGESA (a BIOSy, které ji budou mít začleněnou) přinese. Má totiž odstranit jinou věc, které si uživatelé Ryzenů 3000 všimli. V logu Windows se s těmito CPU objevují zprávy o chybě „Event 17, WHEA-Logger“ (mělo by to souviset například s M.2 SSD na sběrnici PCI Express, ale asi i s grafikami). Údajně to snad nemá znamenat porušení dat na disku, ale jen to, že řadič detekoval a opravil chybu. Ale každopádně tato varování nové BIOSy mají odstranit.
Mělo by zřejmě jít jen o kosmetickou záležitost – ECC korekce paketů na PCI Expressu je rutinní věc, která se podle AMD děje normálně. Chybou tedy bylo zřejmě spíš to, že se tato událost logovala ve Windows jako varování a vytvářela v protokolech spam. Oprava by tedy neměla spočívat ve změně fungování, ale v tom, že se ECC korekce nebude v logu zobrazovat (a varování by nastávala jen u případů, kdy se korekce nezdařila a podobných závažných chyb).
