AMD k Ryzenu: proč jsou vysoké teploty a jak to vypadá s výkonem SMT a Windows 10

45

Prach po vydání procesorů Ryzen se pomalu usazuje. Nová CPU a s nimi také nová platforma AM4 přinesla hodně změn a objevily se i diskutabilní fenomény, dané její nezralostí a doufejme odstranitelné. AMD nyní publikovalo oficiální blogový článek, kde se k některým z nich vyjadřuje. Včetně toho, že v některých testech vycházejí na Ryzenu výkonově lépe Windows 7, oficiálně nepodporované, ale nakonec plně provozuschopné.

Windows 10 to nedělají špatně

Hráče asi po recenzích nejvíce zaměstnává téma SMT (tedy počítání dvou vláken na jednom jádře jako u Intelova HT). Jeho použití v některých hrách snižuje výkon, což se běžně dává za vinu plánovači CPU ve Windows, který procesy na jednotlivá jádra a vlákna přiřazuje. Často se usuzovalo, že toto nedělá optimálně. Tedy že nerozeznává, která logická vlákna patří ke kterému jádru; správně má totiž nejprve saturovat všechna fyzická jádra jen jedním vláknem, než jim začne přiřazovat druhé. Dvě vlákna sdílející jedno jádro totiž u obou vedou ke snížení individuálního výkonu (toto se týká jak SMT, tak HT).

Podle AMD ale Windows v tomto ohledu procesor chápou korektně a špatného „schedulingu“ se nedopouštějí. Podle testování je údajně na této frontě vše v pořádku (což dává smysl, neboť AMD s Microsoftem určitě vše interně testovalo). Windows údajně přidělují správně nejprve jedno vlákno na každé jádro, což naznačuje také tento test webu PC Perspective. Určité pochyby prý mohly vyvolat jiné nástroje, které špatně detekují uspořádání Ryzenu, což by měl být případ starších verzí Sysinternals Coreinfo (před 3.31).

Podle AMD s otázkou SMT a scheduleru nesouvisí ani hlášené regrese výkonu mezi Windows 10 a Windows 7 v některých testech. Po analyzování nahlášených případů se údajně plánovač jeví i zde být nevinný. Rozdíly ve výkonu jsou tak podle firmy pravděpodobně v architektonických odlišnostech obou operačních systémů, případně v tom, že nové jádro dělá více práce navíc, která někde dostupný výkon ubírá. Tento jev by snad ale měl mít výrazný dopad spíš ojediněle.

Procesor Ryzen v desce (Zdroj: Ars Technica)
Procesor Ryzen v desce (Zdroj: Ars Technica)

Toto ale neznamená, že na fungování SMT v programech (respektive hrách, aplikační software prakticky vždy benefituje) nejsou příležitosti ke zlepšení. Nebudou ovšem na straně operačního systému, ale přímo na bedrech vývojářů jednotlivých programů. V některých případech se patrně bude dát výkon zlepšit úpravami kódu, je možné, že někde se kód k SMT nechová správně a neguje tak to, že plánovač jádrům a vláknům rozumí. Nelze asi zdaleka čekat, že bude pro Ryzen vyladěn každý program, nicméně AMD řadě vývojářů poskytuje počítače s Ryzenem pro testování a snaží se tímto způsobem k zlepšení situace přispět. Alespoň v některých případech by se tak optimalizací mohlo dočkat.

Nastavení spotřeby aktualizaci potřebuje (a dostane)

Zatímco plánovač procesoru zdá se ve Windows funguje, skutečné problémy (respektive neoptimální chování) se dějí v řízení spotřeby. Jak už patrně víte, AMD doporučuje mít zapnuté nastavení spotřeby „Vysoký výkon“ (u anglické verze High Performance) místo výchozího režimu „Rovnováha“ (Balanced). Důvody, proč je Ryzen měřitelně lepší pod prvním, jsou údajně dva. Prvním je tzv. Core Parking, tedy vypínání jader (přesněji řečeno jejich přepínání do úsporných stavů). Jelikož jejich probuzení přináší určitou latenci, není pro vysoký výkon optimální – přinejmenším se současným nastavením. Režim Vysoký výkon Core Parking vypíná, takže tento účinek obchází.

Druhým důvodem je odlišná rychlost přepínání frekvencí. Ryzen dokáže svůj takt škálovat nahoru či dolů velmi rychle, během 1 ms. Plán spotřeby Rovnováha škáluje frekvence a napětí poměrně pomalu, zejména mu asi déle trvá, než CPU vytočí na vyšší takty (turbo), kvůli zaměření na snižování spotřeby. Toto se má údajně také u Ryzenu projevovat negativně, neboť jeho dynamická úprava frekvence (nazvaná Precision Boost) je poměrně pokročilá.

Výběr plánu řízení spotřeby najdete v dialogu Možnosti napájení. Ve Windows 10 a 8.1 se k němu dostanete například kontextovou nabídkou spuštěnou pravým kliknutím na tlačítko Start
Výběr plánu řízení spotřeby najdete v dialogu Možnosti napájení. Ve Windows 10 a 8.1 se k němu dostanete například kontextovou nabídkou spuštěnou pravým kliknutím na tlačítko Start

Dobrá zpráva je, že v tomto případě plošná oprava na straně operačního systému nastane. AMD vydá aktualizaci ovladače, která chování řízení spotřeby změní a oba zmíněné problémy pokryje. Tento ovladač upraví chování pod nastavením Rovnováha, aby bylo pro Ryzen optimální, tedy rychleji škálovalo frekvenci a nepoužívalo (či méně agresivně používalo) Core Parking. Touto aktualizací by se rozdíl mezi oběma režimy měl zredukovat a tím pádem bude ve výchozím nastavení Windows Ryzen dávat o něco lepší výkon.

Aktualizace: Pokud zvládáte němčinu, můžete se podívat na test, v němž vyzkoušel web rozdíly dané řízením spotřeby (ale také použitím Windows 7 místo 10) web ComputerBase. Vyšlo mu, že plán Vsoký výkon (v grafech Höchstleistung) může vylepšit FPS ve hrách o 2–4 % (V Project Cars vyšlo dokonce 13 %, což je ale asi extrémní výjimka). Něco málo může přidávat také vypnutí HPET v BIOSu (v grafu označeno: HPET aus). Nastavení Vysoký výkon ale zvyšuje spotřebu mimo zátěž o 9 W (z 53 na 62 W pod Windows 10, ve Windows 7 je výchozí spotřeba bez zátěže 58 W, tedy také o něco vyšší).

Monitorování teploty někdy kecá, nadhodnocuje o 20 °C

Pozoruhodná je třetí věc, o které AMD v blogpostu hovoří. V recenzích se u Ryzenů 7 1700X a 1800X objevují v zátěži poměrně vysoké teploty, ačkoliv spotřeba CPU není zas tak vysoká; Ryzen 7 1700 vyhází podstatně chladněji. Zdá se, že tato měření jsou ovlivněna kuriózní zvláštností. Podle AMD totiž Ryzeny 7 1700X a 1800X hlásí vyšší teplotu, než ve skutečnosti jejich čidla měří – CPU k výchozí hodnotě vždy natvrdo přidává celých 20 °C, tzv. tCTL Offset. Pokud tedy všechny tři modely Ryzenu 7 zahřejete zátěží na 40 °C, pak jen model 1700 hlásí tuto teplotu (samozřejmě s určitými nepřesnostmi danými metodou měření). Modely 1700X a 1800X budou monitorovacím aplikacím hlásit 60 °C.

Ryzeny 7 1700X a 1800X ke skutečným teplotám připočítávají dvacet stupňů, aby je deska více chladila
Ryzeny 7 1700X a 1800X ke skutečným teplotám připočítávají dvacet stupňů, aby je deska více chladila

Tato zvláštnost není údajně chybou, ale záměrem, ač to nemusí znít logicky. Cílem korekce v modelech s označením X je, aby tato CPU ve stejné základní desce a se stejným chladičem dostala agresivnější chlazení. Při vyšší hlášené teplotě totiž automatika nastaví otáčky ventilátoru výš. To má význam třeba pro funkci XFR, která na modelech s písmenkem X může zvednou takty maximálního turba o 100 MHz, kdežto na „neikskách“ jen o 50 MHz (a na nižší absolutní hodnotu). Pro tyto výkonnější modely je tedy kvůli vyšponovaným frekvencím jejich turba vhodné, aby měly silnější chlazení, a AMD to zřejmě nechce nechat na náhodě.

Software pro sledování systému tak bude muset tyto umělé přirážky zohledňovat, má-li ukazovat přibližně reálné teploty. Zatím tedy asi vyšší hodnoty u R7 1700X/1800X obvykle nejsou správné a ves skutečnosti vaše CPU takovým horkem netrpí. Bohužel asi budou trochu zmatky třeba v BIOSech desek, kdy nebudete automaticky vědět, zda vám hlášená teplota onu 20°C přirážku započítává, nebo ne.

45 KOMENTÁŘE

  1. Doufal jsem, že to je ve Windows ještě neoptimální. Takhle je to jen na vývojářích SW a ti tedy moc optimalizací za poslední roky nedělají, takže nějak nevěřím, že by se to teď mohlo změnit.

      • AMD snad může smysluplně kecat tak do OS a BIOSu(základní desky). Zbytek je na celkem nepružném a roky nereagujícím SW průmyslu, když vezmu třeba jednoho z těch velkých, který by mnohovláknový výkon opravdu smysluplně využil – Adobe, tak to roky škáluje přímo zoufale. V nějakou optimalizaci kódu pro hry, tomu se grafická sekce AMD jistě hodně směje., možná nové tituly, když se bude Ryzen skvěle prodávat.

    • Přesně tak, plnou hubu keců jak je bug ve scheduleru, jak po odstranění naroste bohovsky výkon.
      A i kdyby tam byl problém s přidělováním u Ryzenu, tak by to nebyl rozhodně bug. Protože pokud něco funguje a pokud pak někdo přijde s jiným rozložením nebo fungováním jader procesoru, tak by to byla jen nepodpora nové technologie, ale rozhodně ne bug.

    • Tak o tom psal téměř každý web, ne jen Stach a všichni se celkem shodovali, tak proč si Maudit vybírá jen Stacha, to teda nevím, že by zášť :oDDD
      Jinak ten problém se SMT tam pořád je, jinak by nepomohlo vypnutí SMT a tím zvýšení výkonu. A protože to někde funguje dobře a někde ne, tak je chyba v softwaru. A to buď WINDOWS (teď pravděpodobně vyloučeno) a nebo v samotné aplikaci nebo hře. Z toho je jasný, že prostě chybí optimalizace her, což je pochopitelný, protože doteď o Ryzenu nevěděli.

      • Pochop, ze nektere hry jako FarCry4 maji tezke problemy se SMT i od intelu. na nektere hry to nema zadny, ani pozitivni vliv, proto to vychazi ruzne. Proste SMT se v ryzenu buglo, mluvilo se tu o tom pred pul rokem, a oprava je dobra, ale ne idealni. Se s tim smirte. Proc myslis, ze amd chce vydat respin ryzenu uz za rok. Soucasny ryzen je proste beta produkt, nic noveho, to se stava i v lepsich rodinach, u intelu to byla kauza FMA… Muzeme bejt radi, ze to je jen tohle. Teda zatim.

        • SMT se nebuglo, to je prostě způsob, jak funguje – když jádro sdílí dvě vlákna, oběma z nich klesá ST výkon ve jménu vyššího MT výkonu v součtu. TO prostě může v některých aplikacích uškodit a děje se to i na Intelech.

          Někdy může ta penalizace být i bez zatížení toho druhého vlákna, pokud ji způsobuje sdílení některých struktur se statickým rozdělením na oba thready. Staticky rozděleného toho v Zenu IIRC moc není, ale některé věci ano, a je možné, že je to o něco větší bottleneck než u současných Intelů. Ale IMHO je teda výkon jádra Zen moc dobrej, takže dost těžko mluvit o „bugu“, jak všude slyším. Stačí se podívat na IPC, na frekvenci – jsou možná i o ~20 % dál, než jsme čekali.

        • Další generaci Ryzenu určitě AMD nedělají kvůli nějakému SMT bugu, protože žádný SMT bug Ryzen nemá. Stejně tak není pravda že jde o nějaký beta produkt. Ten procesor má své silné a slabé stránky, jako každý jiný produkt a další generace přijde zhruba za rok protože tak to bylo naplánováno v roadmapách ZENU bez ohledu na to, co tu píšeš za doměnky….

          • LOL, to nejsou fakta, to jsou babské drby 🙂 už jen proto, že Canard PC Hardware neměl finální revizi CPU, ale nějaký ES, navíc sami napsali, že díky velice rannému biosu desky ani nefungovaly některé featury… informační hodnota = 0

            a to že se to tu tehdy objevilo jako newska tomu na váze nepřidá ani z toho drbu neuděla fakt.

          • Hmm, okej, takze mame tu info o problemech se smt v ES. Dnesek – problem se smt. Del42sa udela zaver – babske drby.
            Tak okej 🙂 Kazdej si udela obrazek sam.

          • @Hnizdo – to bylo na 100% něco úplně jiného. Jestli mají pravdu, že ta starší verze měla chybu, tak se to pravděpodobně projevovalo tak, že systém zamrzl. BIOS s workaroundem tehdy měl snížený výkon, něco jako u TLB bugu B2 revize Ageny. Teď evidentně máme plnej výkon, tj. workaround není třeba, tj. bug s SMT/uOP cache, o kterém mluvíš, musel být vyřešen v křemíku.

          • Ten clovek tam nema ani popsanou metodiku, ale presto tam vidim tedy poradne vykyvy, a kabylake mi prijde podstatne vyrovnanejsi.
            Coz nic nemeni na tom ze se jedna o syntetesty a v realu to vypada jak to vypada.
            Davam prednost drtive vetsine svetovych recenzi nez se prebijet nejakymi typky z fora.

          • @Jan Olšan 15.3.2017 at 13:00> Nesouhlasim. Tehdy se bug skutecne projevoval nestabilitou, proto byly ES na tak nizke frekvenci. Nejednalo se o snizeny vykon, ale frekvenci, tehdy jim to bezelo na 3-3.4. Takze to fixli, ale evidentne ne idealne.
            V zadnem, ALE V ZADNEM PRIPADE, nemohli behem iterace ES-production stihnout opravu niceho jineho nez metalizacni vrstvy, to vime oba.
            Takze fix je 100% v mikrokodu. A ma to dopady.

          • Vzdyt rikam, ze nemohli stihnout nic jineho nez metalizaci. Ale interakci smt a uop cache metalizaci skutecne neopravis.
            A mimochodem, na jinem miste se psalo, ze ES se od production nelisi, cili zadny respin nebyl.

          • @Hnizdo
            Nevíme, jak dlouho se na té opravě pracovalo. První vzorky byly dostupné nejpozději v červnu-červenci, tj, v té době nebo krátce na to už se o tom mohlo vědět pokud to nebyla hodně vzácná chyba a mohly začít práce na té opravné revizi. Že se o tom Hnizdo a Olšan dozvěděli až v prosinci, neznamená, že ta věc do té doby neexistovala. Ten křemík dokonce už mohl existovat v tom prosinci, jenom ještě nebyl „na černém trhu“ a tedy dostupný těm Canardům.

            Jinak pochybuju, že by ten problém zamezoval dosáhnout vyšší frekvence, na to jsou většinou jiné a složitější faktory. Bug se většinou projevuje nestabilitou, zamrznutím, obecně se tomu říká „unpredictable behavior“ – prostě to neudělá, co má, a OS nebo hardware spadne, zamrzne nebo udělá nějakou záludnou chybu.

          • Tady uz zabihame do divokych kdyby. Nechapu, proc se porad vyhybame zmerenemu faktu, ze SMT ryzenu neposkytuje vzdy ocekavany vykon, a ze se SMT byl problem hlaseny uz v minulosti. To jsou fakta. Vymyslet si spekulace, proc by tomu tak nemuselo byt, je preci zbytecne.

          • hnizdo> Sorry, nedá mi to. Ty by si si mal ujasniť, čo znamená „fakt“.

            Za fakt (aj to len na základe dôvery) môžeme považovať jedine to, že Canard na svojej testovacej zostave (nefinálnej podotýkam) naozaj objavili nejaký SMT bug. Dôvody, prečo sa taký bug ukázal sú už ale len špekulácie ako aj akékoľvek ďalšie rozvíjanie tejto témy.

            Argumenty typu „bios SMT buď zapne alebo vypne“, „plne funkcni SMT“ atd mi pripadajú dosť netechnické aj na tvoje pomery…

          • Ale dobre, vzdyt ja se nesnazim dokazat, ze zadny respin nebyl, jinak bych to sem postnul, a respin metalizace se stihnout mohl, ale minimalne ten A0 ten problem se SMT mel, a nyni nejake to reziduum pretrvava, proc se tomu tak branis, nechapu. Tedy ja to chapu, samozrejme. Jen nechapu proc si myslis ze tvoje snaha ten problem popirat ma jeste nejaky smysl.

        • Ale plosimtebe, tvymi slovy babske drby na foru od cloveka co si hraje se syntetesty, AMD jasne reklo ze problem s windows schedulerem neexistuje, proste smt ryzenu je v realnych aplikacich mene efektivni nez u intelu. se s tim uz smirte, proboha, zas to neni takovej pruser.

          • ty zřejmě nedokážeš pochopi ty rozdíly při testování:

            Canard HW : testy ES na zabugovaných biosech s nefunkčními featurami

            a testy prodejní finální revize , kterou dělal The Stilt na oficiálním release biosu

            co víc dodat ….

          • Canard pracoval s plne funkcnim SMT. Uvadi to doslovne. Ze mu nefungovaly nejake features na jeho zaverech o smt nic nemeni, bios smt bud zapne nebo vypne, ale nemuze ho bugnout. Pochop aspon tohle.
            Je zcel jasne ze tam problem byl a byl castecne opraven.

          • Hnizdo, ja bych na tebe reagoval, ale nema to cenu. Ty si vezmes jeden nejaky fakt a kolem toho si vytvoris celou teorii, kterou po tom davs druhym a nazyvas tu teorii „faktem“. Kdyz by se s Tebou dalo soudne diskutovat, tak nemam nic proti. Podivej se, ze Ti tady kazdy oponuje..ne proto, ze by si mysleli, ze AMD je zlate vejce a nema chyby, ale proto, ze vytvaris teorie, ktere se ostatnim proste nezdaji.
            Pokud si ochoten videt veci trochu barevneji, ja budu jedine rad s tebou diskutovat.

          • Nikdo ti v argumentaci nebrani, ale musis se trochu snazit. Toto je tvuj prvni prispevek a jeste OT.
            Nevytvarim zadne teorie. pracuji s fakty. O vecnou diskusi se pokusil jedine Honza, del42 jako skalni fanAtik se uchylil pouze k popirani.

  2. K měření teploty – „Tato zvláštnost není údajně chybou, ale záměrem, ač to nemusí znít logicky“. Já tedy podezřívám AMD, že jde o chybu zabalenou jako fíčura. Proč zavádět takovou nestandardnost? Teplota má být snad indikována správně, bez nějaké bulharské konstanty. Pokud chtějí agresívnější chlazení, tak snad to jde v BIOSU zařídit na základě třeba cpuid.