AMD julkaisi viime vuonna toisen sukupolven Ryzen Threadripper -prosessorit, jotka on varustettu parhaimmillaan 32 ytimellä, jotka kykenevät SMT-teknologian avulla suorittamaan samanaikaisesti 64 säiettä. Etenkään 32-ytiminen Ryzen Threadripper 2990WX ei kuitenkaan selvinnyt kaikista suorituskykytesteistä odotusten mukaisesti.
Ryzen Threadripper -prosessoreiden suorituskykyongelmia on ratkottu jo monella taholla. AMD on julkaissut oman Dynamic Local Mode -ominaisuutensa, joka parantaa suorituskykyä useissa tilanteissa ja NVIDIA korjasi ajureistaan löytyneen ongelman, joka puolitti suorituskyvyn 32-ytimisillä, 64 säiettä suorittavilla prosessoreilla. Osa ongelmista on kuitenkin edelleen ratkomatta ja LevelOneTechs uskoo selvittäneensä mm. Bitsumin ja AnandTechin avustuksella mistä on kyse, eikä se ole monien syyttämä muistiohjainten puute kahdella sirulla, mikä varmistettiin ajamalla testejä Threadripperin lisäksi 32-ytimisellä Epyc-prosessorilla.
LevelOneTechs käsittelee Windowsin ytimestä tämän hetken tietojen perusteella löytyvää ongelmaa sekä blogissaan että YouTube-videolla. Esimerkiksi Indigo-testiohjelmassa TR2990WX:n suorituskyky on Windowsilla vain puolet tai alle Linux-versiosta, eikä Linux-version ajo Windowsin alla auta tilanteeseen, koska Windows Subsystem for Linux suorittaa kaiken edelleen Windowsin kernelillä, ei Linuxin. NUMA-tilassa myös Epycin suorituskyky on Windowsilla heikko, mutta UMA-tilassa suorituskyky vastaa Linuxia.
Prosessorin rasitusaste on kuitenkin kummallakin alustalla identtinen 100 % riippumatta suorituskyvystä, joten Windowsilla prosessori hukkaa johonkin merkittävän osan suoritusajastaan. Tarkempien tutkimusten jälkeen syylliseksi paljastui Windows, joka merkitsee Indigon säikeet ideal_cpu-tagilla käynnistyksen yhteydessä. Jos käytössä on maksimissaan kaksi NUMA-noodia, kaikki toimii kuten pitää ja ideal_cpu-tagi syntyy edelleen, mutta säikeet löytävät kotinsa kummankin NUMA-noodin sisältä.
Kun NUMA-noodeja on yli kaksi, rupeaa Windows noudattamaan ideal_cpu-tageja ja säikeet pyritään saamaan vain yhden NUMA-noodin sisälle, jolloin Windows käyttää puolet prosessoriajasta siirrelläkseen säikeitä ytimiltä toisille. Yksi ratkaisu bugiin on ottaa ensimmäinen prosessoriydin pois ohjelman käytöstä, kun ohjelma on jo päällä, jonka jälkeen Windows jättää ilmeisesti jälleen ideal_cpu-tagit huomiotta. Ohjelman käytöstä poistetun ytimen voi ilmeisesti myös ottaa takaisin käyttöön ilman, että suorituskyky putoaa uudelleen, mutta sama kikka on toistettava joka kerta, kun ohjelmaa käytetään.
Bitsum on näiden löydösten myötä päivittänyt CorePrio-ohjelmaansa NUMA Dissociater -ominaisuudella, joka pyrkii automaattisesti tunnistamaan edellä kuvatun ongelman ja korjaamaan sen, ilmeisesti käyttäen juuri yllä kuvattua metodia. Indigon lisäksi vastaavaa ongelmaa esiintyy myös muilla sovelluksilla ja esimerkiksi 7zipin suorituskyky nousee CorePrion korjauksen avulla peräti 70 % noin 41 000 MIPS:sistä noin 70 000 MIPS:iin.
Mikäli LevelOneTechsin johtopäätökset ovat oikeita, voidaan toivoa Microsoftin päivittävän kerneliään tarpeellisilla muutoksilla ongelman ratkaisemiseksi lähitulevaisuudessa.
Lähde: LevelOneTechs, Bitsum CorePrio
Otsikossa on Pahavirhe tässä korjattu versio
”LevelOneTechs ja Bitsum uskovat korjanneensa Wndowsin suorituskykyongelmat Threadripper 2990WX prosessoria käytettäessä.”
Alkuperäine otsiko antaa sen kuvan niin kuin Threadripper 2990WX prosessorisssa olisi ollut jotain vikaa mikä ei pidä paikaansa.
Jos olisi foliot tiukemmalla voisi haistaa jonkun salaliittoteorian siitä että TR prossuja jarrutellaan tarkoituksella. En tiedä Intelin enterprise palvelimista tarpeeksi, mutta onkohan mitään muuta ympäristöä, jossa Windows 10 oikeasti olisi ajossa NUMA ympäristössä?
Herää kysymys miksei näin selvää bugia ole löydetty ja korjattu MS toimesta? Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
Koskee myös Epyciä NUMA-tilassa, UMA-tilassa ei koske Epyciä.
Ei kannata aina olettaa pahantahtoisuutta tilanteessa, jossa useimmiten kyse on vain ammattitaidon puutteesta. Ihan mahdollista on, että siellä on vain ajateltu, että 2990WX on persiistä, ja siksi suorituskyky on huono. Koska markkinaosuus on pieni, ei ole laitettu asiaan enempää paukkuja.
Ihan "puhdas bugi" tämä on minun mielestäni kun otetaan huomioon kuinka erilaisia nämä prosessorit on useamman NUMA noodinsa kanssa. Wendell veikkaa että tämä voisi liittyä 1 tai 2 kannan XCC Xeoneja varten tehtyyn bugi korjaukseen.
Enkä tiedä onko Wendell tai joku muu testannut mutta veikkaisin että Server 2016/2019 on sama ongelma kuin Windows 10:ssä.
P.S. Eikö se ole virallisesti Level1Techs eikä LevelOneTechs About Us
Hyvä ettää löytyy asialla omistautuneita ihmisiä kun noiden suorituskykyasioiden etsintään kuluu varman aika paljon miestyötunteja mitä helpottaa paljon korjauspäivitysten teossa.
Nyt puhutaan samasta firmasta joka pisti ulos dataa hävittävän ja bugiseksi tiedetyn päivityksen Windows 10:lle. Jos he eivät tajua korjata edes raportoituja bugeja, niin miten joku piilossa oleva olisi sitten korjattu?
Tuskin mitään tahallista hidastamista, näyttäis aika tyypilliseltä windows-bugilta. Niinkuin Wendell videollaan kertoo niin AMD on historiansa aikana tarponu jo monen monta kertaa windowsin bugisuossa, lähinnä koska AMD kehittää usein uusia ratkaisuja joille sitten joutuu odottamaan windows-tukea joskus pitkäänkin. Nythän tässä on kyse siitä että AMD on kehittänyt ensin tämän chiplet-arkkitehtuurin, ja MS:llä ei ole ehkä tieto-taitoa viilata kerneliä niin että kaikki toimii täydellisesti. Ihmetyttää oikeastaan se että näillä yhtiöillä ei ole parempaa kommunikaatiota keskenään ja että tämän tason bugi löytyy vielä näin pitkän aikaa tuotteen julkaisun jälkeen :darra:
Ja tekijätkin ovat sellaisia joilla ei ole mitään sisäpiiritietoa Windowsista. Silti pystyvät parempaan kuin Microsoft ":tup:"
Tässähän ei varsinaisesti ole kyse chipleteistä. Onkin jännittävää nähdä miten se oikea chiplet-homma tulee toimimaan.
Tuskin se kommunikaatiosta on kiinni. Microsoftia ei vaan kiinnosta.
Siteerasin vain videota, mulla ei ole mitään kompetenssia sanoa yhtään että mistä tämä bugi johtuu 🙂
Aika selvää, että jokin bugi on ollut, kun useampi testi antaa saman tuloksen 32-corelliselle Threadripperille kuin 16-corelliselle esim. PassMark ja Indigo. Ei sitä selitä mikään muistin pullonkaula. Joko bugi on windowsissa, kuten nyt selvisi sen olevan, tai sitten testeissä, mikä olisi vähän outoa, kun ne testit kuitenkin toimii 16+ corellisilla Intel prosessoreilla. Joo, ei siinä winkussa ole vain ollut tukea vielä uudenlaiselle arkkitehtuurille ja siksi se kusee. Mutta hyvä juttu, että Threadripperit on mainettaan parempia. Tosiaan on ollut tiedossa, että 32-corellinen pyörii paljon paremmin Linuxin puolella se on näkynyt testeissä. Minäkin vaik en oo Linux-miähiä huomasin semmoisen testiartikkelin.
Ei voi koska sama ongelma on myös Epyceissä ja tuo on iso ongelman Microsoftille joka kuvittelee vieläkin tunkevansa omaa käyttistään todellisiin palvelimiin ja muuhun raskaaseen käyttöön.
Juu. Samaa tässä konesalimiehenä ihmettelin. Ei näy tällä Winukkaa missään. Tai on yksi kone missä on Windows mutta se ei ole kiinni missään vaan toimii pasianssi konenna Artolle ku se tykää pelata…
Eiköhän AMD:n ja Microsoftin välillä kommunikaatio kulje ihan hyvin.
Kun tuntuu Microsoftin kymmeniävuosia jatkuneen tupeksimisen perusteella siltä että ne kommunikaatiotukotkset on siellä Microsoftin sisällä.
Kenenkään ei pitäisi olla yllättynyt tällaisesta. Samat ongelmat vaivaavat myös moniprosessorijärjestelmiä.
Windowsin oma scheduleri toimii hienosti, kun käytössä on yksi NUMA-node ja yksi processorgroup. Kun määrät nousevat, scheduleri rupeaa nikottelemaan. Käytännössä Windowsin scheduleria on jo vaikea käyttää, jos loogisten prosessorien määrä ylittää yhden Processorgroupin rajan. Eikä ole kauaa, kun ominaisuus, jossa yksi numa-node saattoi pilkkoutua useampaan processorgrouppiin korjattiin.
Tosiasiassa Windowsille ei ole juuri muita softia, kuin niiden oma SQL-server joka tukisi kunnolla montaa prosessoria/processorgrouppia. Ja olen aivan varma, että käyttävät julkaisemattomia rajapintoja tämän tuen saavuttaakseen. MSDN:n dokumentaatio on totaalisen perseestä koko NUMAn ja schedulerin osalta, myöskään Wininternals (joka on erinomaisen lavea joissain muissa asioissa) ei avaa tätä toiminnallisuutta mitenkään. Lisäksi Windowsissa on kaameita legacyrajoitteita koko schedulerin suhteen (koko Processor Group himmeli).
Intelin kääntäjän mukana tulee TBB, jonka pitäisi ratkoa näitä ongelmia, mutta enpä ole tästäkään kovin vakuuttunut.
Jos tarvitsee paljon säikeitä, valinta on selkeästi Linux. Jos/kun perinteiset UI-softat (kuten pelit) rupeavat vaatimaan 64+ säiettä, on Windows kusessa processor grouppeineen.
Eli Windowssilla on vielä paljon aikaa korjata tuotteensa kuluttajapuolella koska eihän niiden softaa juurikaan missään muualla käytetä. Siinä vaiheessa kun pelit alkavat käyttää 64+ säiettä voi kestää jokunen vuosi;)
Suosittelen joskus menemään töihin johonkin tuollaiseen suuryritykseen, karisee nopeasti suomut silmiltä että vaikka firma olisi markkinajohtaja niin että siellä olisi töissä ammattikunnan terävin kärki 😀
Voi kun vain voisi kertoa millaista shittiä sitä on nähnyt, mutta heitetään nyt pari täkyä, olen nähnyt kuinka IT alan PhD ei osannut vaihtaa näytön resoluutiota ja tuijotti sitä siksi 5cm etäisyydeltä tai että kuinka porukka koodaa Notepadilla ja valittaa ettei koodia voi refaktoroida koska muutaman muuttujan nimen vaihtamiseen koodista menee tunteja….
Itseasiassa Windowsin server-versiot scheduloivat oletuksena hieman eritavalla kuin desktop-versiot. Tätä voi toki muuttaa yhdellä täpällä System/advanced settings/performance osassa.
Sovellussäikeet saavat aina pienen aikaikkunan, jonka jälkeen säie rescheduloidaan prioriteetti ja jonotussääntöjen mukaan. Tämä aikaikkuna on desktop-windowseissa merkittävästi lyhyempi, kuin serveriversioissa. Tästä johtuen desktop-versiot ovat paljon alttiimpia context-switcheille kuin serveriversiot tilanteissa, joissa on paljon säikeitä odottamassa suoritusta.
Kyseessä on osittain legacy-juttu, juontaen yhden hw-säikeen koneista, joissa on haluttu UI-softien olevan vastaavampia käyttäjää kohtaan. Nykyisinkin desktop-koneilla on vähemmän samanaikaisuutta, joten ominaisuus puoltaa paikkaansa.
Runsas vääränlainen context-switchailu voi johtaa todella ikäviin tilanteisiin monen Numanoden koneilla, jos säie joutuukin seuraavalla scheduloinnilla vääriin välimuisteihin väärälle Numa-nodelle. Tästä seuraa memory barriereiden tarve tai välimuistisynkkaus, joka heikentää suorituskykyä roimasti. Schedulerin pitäisi yrittää välttää tällaisia tilanteita, mutta ilmeisesti jokin nimenomaan tässä bugittaa, ehkä Windows ei vain tajua Threadripperin Numa-rakennetta oikein.
Joku Threadripperin omistajahan voisi kokeilla tätä, laittakaa täppä "optimize for background services" päälle ja katsokaa miten suorituskyvyn käy?
Se että prioriteeteja pystyy muuttamaan ei tarkoita sitä että muuttaisi sitä miten se toimii siinä vain mutetaan sitä hetkä milloin se toimii.
Ei tällä ole mitään tekemistä prioriteettien kanssa vaan yhdelle säikeelle kerralla annettavan suoritusaikaikkunan pituuden kanssa. Prioriteetti vaikuttaa siihen kuinka usein säie päätyy suoritettavaksi.
Ks. Windows Internals 6th edition osa 1, sivut 423-429 "Quantums"
Yhtä huonosti toi pelasi Windows Serverilläkin, jossa oletettavasti tuo on päällä
A Quick Look At The Windows Server vs. Linux Performance On The Threadripper 2990WX – Phoronix
Eli mitään yksinkertaista asetussäätöä tämän ongelman ratkaisuun ei ole, muuten se olisi jo todennäköisesti löydetty Microsoftin, AMD:n tai jonkun testaajan puolesta.
Enpä näin kyllä uskonutkaan, ongelma on edelleen sama, vaikka säie jatkaisikin pidempään ennen reschedulointia, tällöin säie on vain pidempään oikeassa/väärässä paikassa kerrallaan.
No kuten jo aiemmin kirjoitin, Windowsin scheduleri on Numan kanssa tosi kuppainen. Kaipaisi isompaa remonttia, mutta harmittavasti scheduleri on käyttiksen yksi oleellisimmista osista ja sen isompi ronkkiminen ilman tarpeeksi hyvää syytä ei ole hyvä idea ihan pienestä syystä.
Yksi syy miksi monet korporaatiot käyttävät Windowsia Linuxin sijaan palvelimissa on nimenomaan legacytuki vanhoille jutuille. Käytännössä voit olettaa minkä vain Win32 softan toimivan edelleen ilman mitään ongelmia uusimmissakin windowseissa – ja oikeastaan myös uusimman softan voi olettaa toimivan vanhoissa, jos olet vain pitäytynyt vanhassa apitasossa. Tätä ei haluta rikkoa.
Linux on tässä mielessä vähän ankea, koska pienikin kernel/libc päivitys voi rikkoa ABI yhteensopivuuden, pääsääntöisesti tosin vain taaksepäin, mutta käy välillä toisinkin päin. Tästä syystä meilläkin töissä käännämme softaa vielä Rhel4:llä ja roikutamme Redhat9 imageja virtuaalikoneina. Ja kääntöpuolena uusimman softan pitää olla sitten jotenkin semi-uutta (muttei liian), koska vanha ei sitten toimi (oikein) uusimpien kanssa. Eli konservatiivisessa windows mallissa on myös puolensa – ja tämä on muuten sama syy miksi Redhat on Linuxina niin suosittu yritysten käytössä.
Se että suoritusaikaikkunan pituuden pystyy muuttamaan ei tarkoita sitä että muuttaisi sitä miten se toimii siinä vain mutetaan sitä hetkä milloin se toimii.
AMD Comments on Threadripper 2 Performance and Windows Scheduler
Nostetaan tämä taas uudelleen eloon, kun Phoronix oli testannut Windows 10:n tuoreella 1903-versiolla asiat uudestaan
Linux Still Yields Better Multi-Threaded Performance On AMD Threadripper Against Windows 10 May 2019 Update – Phoronix
Eli parannusta on tapahtunut joiltain osin, esim. Geekbenchin multithread-tulos noussut 25 % ja XZ-pakkaustesti nopeutui noin 6 sekuntia (41.76 -> 35.86), mutta esim. Blenderin osalta muutosta ei ole tapahtunut, ja Ubuntu on edelleen reilusti nopeampi.