AMD Zen

[hkultala]

Device vendor toisessa Intel, toisessa AuthenticAMD. Testissä EI pysty valitsemaan että kenen math libillä testi ajetaan.

Device vendor on se, kenen OpenCL-ajoympäristöä(eli siis käytännössä OpenCL-kääntäjää) käytetään. Tällä ei ole mitään tekemistä cpuid:n kanssa.

Käytännössä:
Intelin OpenCL-ajoympäristö osaa käyttää kaikkia x86-prossuja ja Intelin iGPUita
AMDn OpenCL-ajoympäristö osaa käyttää kaikkia x86-prossuja ja AMDn GPUta
nVdian OpenCL-ajoympäristö osaa käyttää nVidian GPUita. (CUDA-wrapperin kautta)

 

[JiiPee]

Kyllä tuossa tällä hetkellä kaikki viittaa siihen että ainut oikea ero että toinen käyttää Intelin OpenCL-ajuria, toinen AMD:n. Se, miten prosessori sitten saadaan käyttämään Intelin ajuria on kysymysmerkki

Ajamalla windowsia virtuaali ympäristössä esim linuksissa xenin alla ja feikkaamalla CPUID kuten olen nyt koittanut kertoa jo useamman viestin ajan.

 

[hkultala]

Ajamalla windowsia virtuaali ympäristössä esim linuksissa xenin alla ja feikkaamalla CPUID kuten olen nyt koittanut kertoa jo useamman viestin ajan.

Edelleen olen jo kaksi kertaa osoittanut että mitään cpuid:tä ei ole feikattu koska se näkyy aivan oikein tuossa CL_DEVICE_NAME:ssa.


Jos nyt yrittäisit perehtyä vähän paremmin siihen, miten OpenCL toimii.


pieni vihje: Luonnoin TTYllä kurssia, jolla opetetaan OpenCL-ohjelmointia. (TIE-51257: Parallel Embedded Computing)

 

[JiiPee]

Edelleen olen jo kaksi kertaa osoittanut että mitään cpuid:tä ei ole feikattu koska se näkyy aivan oikein tuossa CL_DEVICE_NAME:ssa.


Jos nyt yrittäisit perehtyä vähän paremmin siihen, miten OpenCL toimii.


pieni vihje: Luonnoin TTYllä kurssia, jolla opetetaan OpenCL-ohjelmointia. (TIE-51257: Parallel Embedded Computing)

Saat luennoida ihan vaikka valkoisessa talossa. Jos et halua faktoja nähdä niin se ei ole minun ongelma. Testiohjelmassa EI voi valita kenen tekemää OpenCL rajapintaa käytetään ja ohjelma on käännetty intelin kääntäjällä. Ainoa keino vaihtaa sitä kenen CL:llä ajellaan on valehdella CPUID ja family joka käy selväksi jos olisit viitsinyt lukea sen linkin jonka laitoin jossa myös kerrotaan hyvin selväksi MIKSI ohjelmat käyttäytyvät eri tavalla kun käytetään Intelin kääntäjää.

 

[hkultala]

Se, miten prosessori sitten saadaan käyttämään Intelin ajuria on kysymysmerkki

Asennetaan se koneelle.

CPUn kanssa kyse ei ole samalla tavalla ajurista kuin näyttiksen, CPUlla pyörivän OpenCL-ajoympäristön ei tarvi tehdä mitään sellaisia matalan tason juttuja, mihin esim. normaalikäyttäjän oikeudet eivät riitä, se on oikeastaan kirjasto(joka sisältää kääntäjän) eikä ajuri.

Tämän jälkeen OpenCL:n clGetPlatformIDs -metodi palauttaa listan, jossa näkyy yhtenä valmistajana Intel. Kun tälle kutsuu clGetDeviceIds-metodia, näkyy siellä CPU-laitte , riippumatta siitä minkä merkkinen se CPU oikeasti on.

edit: korjattu hiukan yksityiskohtia

 

[hkultala]

Saat luennoida ihan vaikka valkoisessa talossa. Jos et halua faktoja nähdä niin se ei ole minun ongelma.

Tiedän faktat aika paljon sinua paremmin tästä.

Testiohjelmassa EI voi valita kenen tekemää OpenCL rajapintaa käytetään

OpenCL-ohjelmat kutsuvat aina alussa ohjelman metodia, jolla haetaan koneessa olevat OpenCL-ajoympäristöt, ja ohjelma voi näistä valita haluamansa.

clGetPlatformIDs

Tämän jälkeen haetaan lista sen ajoympäristön tukemista laitteista:

clGetDeviceIDs

ja ohjelma on käännetty intelin kääntäjällä.

Slllä, millä host-ohjelma on käännetty ei ole mitään väliä.

OpenCL-ajoympäristö kääntää sen OpenCL-koodin käytännössä aina sen ohjelman ajamisen aikana. (tai no, on olemassa myös keinoja joilla sen käännetyn OpenCL-ohjelman voi myös tallentaa ja ladata myöhemmin, joten AINA oli hiukan liian vahva sana. Mutta mitään ohjelmaa ei toimiteta valmiiksikäännetyn OpenCL-koodin kanssa, jos käännös tallennetaan, se tehdään sitten asennuksen jälkeen ekalla käynnistyskerralla tms.)

Ainoa keino vaihtaa sitä kenen CL:llä ajellaan on valehdella CPUID ja family

clGetPlatformIDs

Mitäs tämä OpenCL:n metodi sitten tekee?

Tai jos koneelle on asennettu vain AMDn OpenCL-ajoympäristö muttei Intelin OpenCL-ajoympäristöä, kummankohan softa löytää? Siinä ei paljoa cpuid paina.

Sama toisinpäin.

joka käy selväksi jos olisit viitsinyt lukea sen linkin jonka laitoin jossa myös kerrotaan hyvin selväksi MIKSI ohjelmat käyttäytyvät eri tavalla kun käytetään Intelin kääntäjää.

Kyseinen linkkisi ei liity millään tavalla OpenCL:ään josta olet pihalla kuin lumiukko.

Tuo testi sen sijaan oli OpenCL-testi, ja siinä on täysin irrelevanttia, millä kääntäjällä se host-koodi on käännetty, kun kaikki suorituskykykriittinen koodi käännetään sillä ajoympäristön kääntäjällä.

 

[jsa]

Ainut tietty se että jos se Intelin CPU toteutus barffaa jos sitä ajaa AMD:llä ilman CPUID:n vaihtoa. Totahan voi joku viitseliäs testata miten se näkyy jos Ryzenille asentelee sekä Intelin että AMD:n CPU runtimet.

 

[hkultala]

Ainut tietty se että jos se Intelin CPU toteutus barffaa jos sitä ajaa AMD:llä ilman CPUID:n vaihtoa. Totahan voi joku viitseliäs testata miten se näkyy jos Ryzenille asentelee sekä Intelin että AMD:n CPU runtimet.

Tuolla nimenomaan on ne benchmark-tulokset molemmilla.

Ja Ryzenilla, intelin OpenCL-ajoympäristöllä tulos on selvästi parempi kuin AMDn OpenCL-ajoympäristöllä.

(Syynä käytännössä se, että Intelillä on OpenCL-ajoympäristössään parempi kääntäjä, joka tekee myös Ryzenille parempaa koodia kuin AMDn OpenCL-ajoympäristön kääntäjä, AMD on enemmän keskittynyt kehittämään kääntäjää GCN:lle kuin x86lle, ja Intelillä on muutenkin enemmän resursseja kääntäjän kehittämiseen)

Että jos intelin OpenCL-ympäristö on jotain AMDn prossulla ajettaessa cripplannut, se on ollut aika "ovela" cripplauksessaan kun on sitten cripplannut tarpeeksi vähän, että tulos on silti paljon parempi kuin AMDn omalla OpenCL-toteutuksella

 

[Sparru]

Tuohan nyt olis suhteellisen helppo testata ajamalla tuo testi Ryzenillä ja Intelin ajurilla ilman spoofaamista ja verrata noihin muihin tuloksiin.

 

[hkultala]

Tuohan nyt olis suhteellisen helppo testata ajamalla tuo testi Ryzenillä ja Intelin ajurilla ilman spoofaamista ja verrata noihin muihin tuloksiin.

Juuri se tuolla on tehty. Ajettu Ryzenillä, käyttäen sekä AMDn omaa, että intelin OpenCL-implementaatiota. Ei tuolla ole kukaan spooffannut yhtään mitään.

 

[JiiPee]

Juuri se tuolla on tehty. Ajettu Ryzenillä, käyttäen sekä AMDn omaa, että intelin OpenCL-implementaatiota. Ei tuolla ole kukaan spooffannut yhtään mitään.

Ja ihan huvikseen vain ilmoittaa "Compute Performance of Intel® Ryzen 7 1800X Eight-Core Processor"
HUOM Processor, processor != API minun tietääkseni.

 

[Kaotik]

Ja ihan huvikseen vain ilmoittaa "Compute Performance of Intel® Ryzen 7 1800X Eight-Core Processor"
HUOM Processor, processor != API minun tietääkseni.

Lue ne laitteen tiedot sieltä, ihan AMD Ryzen siellä lukee.
Tuntemattomasta syystä CompuBench ottaa alkuun firman nimen OpenCL-ajurista eikä laitteesta

 

[jsa]

Ja ihan huvikseen vain ilmoittaa "Compute Performance of Intel® Ryzen 7 1800X Eight-Core Processor"
HUOM Processor, processor != API minun tietääkseni.

Detaileissa mainitaan:

CL_DEVICE_VENDOR Intel
CL_DEVICE_NAME AMD Ryzen 7 1700X Eight-Core Processor

Vs

platform 0: vendor 'Intel(R) Corporation'
device 0: ' Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz'
platform 1: vendor 'Advanced Micro Devices, Inc.'
device 0: 'Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz'

Tossa taas toiste päin, käyttiksen ollessa eri.

 

[Merri]

Vaikuttaisi siis että CL_DEVICE_VENDOR on hämmentävästi nimetty, mikäli se edustaa OpenCL-ajurin valmistajan nimeä eikä nimensä mukaisesti laitteen valmistajan nimeä. Tosin eipä tuo kovin epätavanomaista ohjelmoinnin maailmassa ole, että asioiden nimet ei aina ihan korreloi sen kanssa, mitä tieto edustaa

 

[Dygaza]

AMD julkaisi ohjeen eri muistinopeuksien, latenssien ja asetuksien vaikutuksista käyttännön suorituskykyyn.

Gaming: Memory OC Showdown: Frequency vs. Memor... | Community



Tämähän oli jo pitkälti tiedossa varsinkin ylikellotusthreadissa, mutta varmaan hyvä pitää monella mielessä kun threadripperitkin kohta ovat testeissä.

Geamdown mode:

Spoileri

BankGroupSwap:

Spoileri

Single rank vs Dual rank:

Spoileri

Automatic timings vs tuned:

Spoileri

Timings vs Frequency:

Spoileri

Yleiskatsaus:

 

[miiksu]

Geardown jäänyt päälle vaikka vaan 1% suorituskykylisä tulee. Mutta missä single vs dual rank muistitestit parhaimmilla asetuksilla.

 

[Dygaza]

Geardown jäänyt päälle vaikka vaan 1% suorituskykylisä tulee. Mutta missä single vs dual rank muistitestit parhaimmilla asetuksilla.

Tossa sivulla mainittiin että SR oli nopeampi sillonkun oikeasti alettii kiristämään asetuksia, autolla DR oli nopeampi.

• Conclusion #1a: But the increased overclocking headroom of single rank modules was more than enough to overpower the benefits of rank interleaving, so manually-tuned single rank DDR4-3200 and 3466 won the day (dark blue and green).

 

[Deleted member 3664]

Hieno yhteenveto. Koska tuossa noi 2 kärkipäätä eroaa siinä että "huonompi" 3200 tuunatuilla asetuksilla mutta geardownmode = ON häviää vain hiukan 3466 tuunatuilla asetuksilla geardown = OFF joten jos molemmissa se olisi OFF ne olisivat hyvin pitkälti tasoissa.

Eli samaa vanhaa ympyrää mennään: 3200Mhz jälkeen skaalaus ei nouse kovinkaan paljoa ja eniten saa irti aliajoituksia kiristämällä sekä single rank muistien kanssa BGS ja GDM = OFF. 3200Mhz kireillä asetuksilla on käytännössä yhtä hyvä kuin 3466 kireillä asetuksilla ja 3520 kireillä asetuksilla koska korkeampien kellojen kanssa aliajoituksia ei voi kiristää niin paljon. Ja hyvillä muisteilla 3200Mhz on vielä mahdollista ajaa CL12 kun taas 3466Mhz (saati yli) se ei ole millään järkevillä 24/7 volteilla mahdollista.

Tuleeko @The Stilt mitään deja vu fiiliksiä?

 

[miiksu]

Tossa sivulla mainittiin että SR oli nopeampi sillonkun oikeasti alettii kiristämään asetuksia, autolla DR oli nopeampi.

Nojuu. Ei sitä älypuhelimella päässy mihinkään. Muutenkin työpäivä, ei ollut aikaa. Geardown offilla sain 3dmark sky divessa noin 1% parannuksen yhdistelmätuloksessa. Noin 33800 pistettä Nano näytönohjaimen kanssa. Ennen oli noin 33500 pistettä.

 

[aleksejjj]

AMD julkaisi ohjeen eri muistinopeuksien, latenssien ja asetuksien vaikutuksista käyttännön suorituskykyyn.

Gaming: Memory OC Showdown: Frequency vs. Memor... | Community

*snip*

@Kaotik Tämän voisi kai ihan etusivullakin julkaista, kun olet aiemminkin uutisoinut näistä jutuista

 

[Kaotik]

@Kaotik Tämän voisi kai ihan etusivullakin julkaista, kun olet aiemminkin uutisoinut näistä jutuista

Eiköhän se sinne saada

 

[Dygaza]

Laitellaas mindfactory.de päivitettyjä myyntitilastoja jälleen (uusin 13.7)

Listaltahan puuttuu vielä Skylake-X prosessorit, mutta hyvin näyttävät Ryzen pohjaiset tekevän kauppaa kyseisessä puljussa.

CPU_Marketshare

Broadwell-E
Units/day 2,1%
Revenue/day 3,4%

Kabylake
Units/day 40,7%
Revenue/day 43,8%

Ryzen-5
Units/day 37,9%
Revenue/day 29,0%

Ryzen-7
Units/day 19,4%
Revenue/day 23,8%

Yhteenlasketut:
Intel
Units/day 42,8
Revenue/day 47,2%

AMD
Units/day 57,3
Revenue/day 52,8%

Kyseessähän ei ole mikään pikkupulju.

 

[Primusol]

Laitellaas mindfactory.de päivitettyjä myyntitilastoja jälleen (uusin 13.7)

Listaltahan puuttuu vielä Skylake-X prosessorit, mutta hyvin näyttävät Ryzen pohjaiset tekevän kauppaa kyseisessä puljussa.

CPU_Marketshare

Broadwell-E
Units/day 2,1%
Revenue/day 3,4%

Kabylake
Units/day 40,7%
Revenue/day 43,8%

Ryzen-5
Units/day 37,9%
Revenue/day 29,0%

Ryzen-7
Units/day 19,4%
Revenus/day 23,8%

Yhteenlasketut:
Intel
Units/day 42,8
Revenue/day 47,2%

AMD
Units/day 57,3
Revenue/day 52,8%

Kyseessähän ei ole mikään pikkupulju.

Täytyy toivoa että mobiili Ryzen lyö sitten vielä lisää löylyä. Olisi suotavaa että AMD pääsee hieman keräilemään itseään ja saadaan kunnon kilpailu pystyyn.

 

[Dygaza]

Ryzenin pääarkkitehti, Mike Clarke gamersnexuksen haastattelussa. Aiheina mm. Micro-OP cache ja IPC parannukset.

This is an "old" video from the ~February press event for Ryzen. We were placed under embargo on releasing the interview and, by the time the embargo lifted, we had gotten so buried in other content that we figured we'd save it for Ryzen 3. Hopefully the content release schedule has thinned out enough right now that folks can enjoy this without it being buried by review releases

mielenkiintoista kuunneltavaa kiinnostuneille. Allekirjoittanut ei ainakaan asioita ollut aikaisemmin kuullut.

 

[BOT]

Vieläkö tulee lisää AGESA-päivityksiä vai jääkö muistituki suppeaksi nykyisillä Ryzeneillä?

 

[Jahve3]

Vieläkö tulee lisää AGESA-päivityksiä vai jääkö muistituki suppeaksi nykyisillä Ryzeneillä?

Käsittääkseni 1.0.0.7 on tekeillä.

 

[JiiPee]

Käsittääkseni 1.0.0.7 on tekeillä.

Jospa tuossa olisi saatu korjattu Linuxissa havaitut ongelmat jos on mikrokoodilla edes korjattavissa.

 

[Nerkoon]

Käsittääkseni 1.0.0.7 on tekeillä.

Netistä sai kuvan, että joku versio tuosta olisi jo emovalmistajien biostiimeillä käsittelyssä. Enkä suoraan sanoen usko, että tuokaan versio on viimeinen. Eiköhän niitä tule vielä ainakin muutama, että saavat hiottua biosit viimeisen päälle trimmiin. Kannattaa muistaa, että ei se DDR4 tuen toimivuus Intelin puolellakaan tullut kuin taikasauvasta heilauttamalla.

 

[aleksejjj]

Vieläkö tulee lisää AGESA-päivityksiä vai jääkö muistituki suppeaksi nykyisillä Ryzeneillä?

Se olisi jo järjenvastaista AMD:ltä jättää mikrokoodi päivittämättä. Ryzen on monelta kantilta katsottuna kultakaivos, joten sille varmasti allokoidaan paljon miestyötunteja. AGESA-päivityksiä on varmasti tulossa useita, mutta niiden aikataulusta ei ole tietoa.

 

[Beaver6]

 

[hsalonen]

..mutta Linuksen Cinebench oli vähemmän (-8%) - ja sillä ainakin semmoinen oli.

 

[Beaver6]

..mutta Linuksen Cinebench oli vähemmän (-8%) - ja sillä ainakin semmoinen oli.

Joutuivat vaihtamaan muistit koneeseen. Mun linkkaamassa oli 3200mhz muistit käytössä.

 

[hsalonen]

Joutuivat vaihtamaan muistit koneeseen. Mun linkkaamassa oli 3200mhz muistit käytössä.

Se voisi kyllä selittää eron.

 

[Lagittaja]

Olettaisin että tuo LamboTechnologyn prosessori on julkaisu versio kun kerta Cinebench tunnisti sen oikein eli 1950X nimellä.
Linusin Area 51:ssäkin oli se ES prossu task managerin ja Cinebenchin mukaan eli ZD1840A8UGAF4.

Eli olikohan tuo Linusin videossa pyöritetty testi kyseisen prossun vakiotaajuuksilla (Esim Videocardz mukaan 3.4/3.7) vai oliko se ylikellotettu johonkin?
Siinä kohtaa kun tehtävienhallintaa näytettiin niin kellotaajuus pyöri 3.57/3.60/3.64/3.74Ghz välillä kun kone idlaili.
Aiemminhan kun tuota oli esitelty niin se oli ylikellotettu 3.8Ghz https://www.io-tech.fi/uutinen/alienwarelta-ryzen-threadripper-kokoonpano-myyntiin-27-heinakuuta

Oli miten oli niin 2866 tulos minun mielestäni on todella hyvä (hieman enemmän kuin R7-1700*2 á la Anandtech ja 2400C15 muistit) ja tuo 3200C15 ajo 3100 pistettä vielä hienompi.
Tuoko 33% (olettaen 2400 Linusin testissä) korkeampi muistitaajuus 8% lisää pisteitä Cinebenchissä? En usko, tottakai se selittää osan tuosta erosta mutta en jaksa uskoa että se selittäisi sen kokonaan. Ja kun kerta on ES vs retail niin there you go..
Esim Tommsin Ryzen OC artikkelissa Cinebench R15 MT tulokset pomppasi hurjat 1.4% kun muistit vaihtui 2400 > 3200 (en tiedä latensseista).
"Mutta kun infinity fabric..." No joo mutta tähän voi vastata että mutta kun Cinebench. Ei käytännössä reagoi muistikaistaan tai latenssiin ja jokainen ydin tekee omaa juttuaan.

Edit: Näköjään muitakin videoita tuolla LamboTechnology tyypillä.

1700X 3200C15 1567CB
1700X 2400C15 1541CB (AT)
Eli ero 1.68%

1920X 2400C15 2477CB
Kun taas
1950X 3200C15 3102CB

Siinä vähän food for thought, pistää mietityttämään. Virallisia TR revikkoja odotellessa.

 

[JiiPee]

Se voisi kyllä selittää eron.

Cinebenchillä alkaa tulla aika vaihtelevia tuloksia isoilla coremäärillä, en tiijä että vaikuttaako viel tuolla coremäärällä mut täs näkee hyvin mite tulee 20% heittoja.

 

[Dygaza]

16 corea tuskin vielä tarpeeksi on että sillä aletaan saamaan isoja vaihteluja. Ja tuossa quad chipillä on vielä sockettien yli keskustelua corejen välillä.

 

[Lagittaja]

4P 112C/224T ja Cinebench hajoaa kun testikuva on niin pieni että testi on valmis vain muutamassa sekunnissa ja säikeiden alustamiseen menee melkein yhtä paljon aikaa
=
sama tapahtuu myös 16C32T masiinalla joka renderöi testiä sen kolme neljä kertaa kauemman



P.S. STH:lla on myös muita videoita olemassa kuten esimerkiksi Haswell-EX 4P 72C/144T "crushing Cinebench" ja tulokset vaihtelee ~2.5%, Broadwell-EX 4P 96C/192T ja tulokset vaihtelee ~5%.

 

[Stephen Elop]

Linux puolella ongelmia kovalla kuormalla. Nyt saatavilla Ryzen test, jolla ongelma saa toistettua alle kahdessa minuutissa Ryzen-Test & Stress-Run Make It Easy To Cause Segmentation Faults On Zen CPUs - Phoronix

Ongelmaa ei ilmeisesti ole Ryzen 5 prossuilla. Threadripper ja EPY vielä kysymysmerkkejä. Toivottavasti AMD:llä ollaan hereillä tuosta virheestä. JOs ongelma ei toistu Threadripperillä, niin sitten toi b2 stepping todennäköisesti on korjannut ongelman. Sitten jääkin enää kysymys, miten AMD hoitaa asian niiden kanssa, jotka ovat jo ostaneet Ryzen 7 prossun.

 

[Mechanical Man]

Onko threadripper edes b2? Ettei olisi suset b1:set joista piti tulla epycejä.

 

[tonkar]

Kyllä toi ongelma on myös Ryzen 5 -prossussa. Mulla on 1600 ja ohjelmien kääntäminen kaatuu silloin tällöin. Liittyy ilmeisesti ytimien väliseen cacheen ja yksi purkkafixi on disabloida OPCache UEFIssa (luin, että alentaa suorituskykyä ~7%). En ole testannut vielä tuota.

 

[Nerkoon]

Onko threadripper edes b2? Ettei olisi suset b1:set joista piti tulla epycejä.

Kuulema ainakin ekat Threadripperit olisivat B1. Tosin niistä kiersi juttua, että AMD olisi valinnut niihin parhaat 5% piireistä.

 

[JiiPee]

Ongelmaa ei ilmeisesti ole Ryzen 5 prossuilla. Threadripper ja EPY vielä kysymysmerkkejä. Toivottavasti AMD:llä ollaan hereillä tuosta virheestä. JOs ongelma ei toistu Threadripperillä, niin sitten toi b2 stepping todennäköisesti on korjannut ongelman. Sitten jääkin enää kysymys, miten AMD hoitaa asian niiden kanssa, jotka ovat jo ostaneet Ryzen 7 prossun.

Kyllä se on kaikilla ryseneillä, Threadripperistä ei tietoa eikä EPYC:stä. Ja Threadripper on edelleen B1, ainoastaan EPYC on B2. AMD on tietoinen tuosta ongelmasta ja AMD:n forumilla jotkuu on saanu AMD:ltä suoraan RMA:n kautta toimivan CPU:n jotka on edelleen B1. Joku valitteli että RMA:sta tullut olisi seqfaultannu kanssa.
Onhan rysenin kanssa toinenkin ongelma linuksilla ainakii. Joillain kone jäätyy tai boottaa idlenä randomisti. Jotkuu on sitä mieltä että nää liittys toisiinsa, toiset on sitä mieltä että eri ongelmia.

 

[Threadripper]

Koska Windowsissa ei ole laajamittaisesti tuollaista ongelmaa, voi vika olla myös Linuxissa itsessään. Siihen ei välttämättä auta Ryzenin päivitykset. Huonolla softalla saa hyvin helposti prosessorin/koneen kaatumaan.

 

[Stephen Elop]

Koska Windowsissa ei ole laajamittaisesti tuollaista ongelmaa, voi vika olla myös Linuxissa itsessään. Siihen ei välttämättä auta Ryzenin päivitykset. Huonolla softalla saa hyvin helposti prosessorin/koneen kaatumaan.

Mitä Phoronixin keskustelua asiasta luin, niin kaatuu myös winukan WSL:llä (tarkoitan sitä windowsin linux konsolia/mikä lie). Mutta BSD:llä olisi kerneliin tehty joku patchi jolla ongelma vähenee.

Mutta koska sama kerneli toimii Intelillä ja vanhemmilla AMD:n prossuilla, niin Ryzenissä on jokin ongelma (ehkä). Hieman epämääräistä tuo teksti tuolla Phoronixin foorumilla. Kovinkaan monen käyttäjän osalta ei voi olla täysin varma että muistit toimivat ja poweri on riittävä ja emo on OK ja että kiintis ei vetele viimeisiään.

 

[Stephen Elop]

AMD on tietoinen tuosta ongelmasta ja AMD:n forumilla jotkuu on saanu AMD:ltä suoraan RMA:n kautta toimivan CPU:n jotka on edelleen B1.

Tuo ei käsittääkseni ole mahdollista, ellei AMD:lle lähetetty prossu ole ollut suoraan viallinen. Nykyään taitaa vain olla aika hankalaa saada ostettua liikkeestä viallista prosessoria. Prossussa voi olla suunnitteluvirhe, jolloin kaikki valmistuneet prossut kärsivät samasta ongelmasta, mutta se että vakiona toinen prossu toimii ja toinen ei, kun käytetään juuri samoja komponentteja, niin tälläistä ilmiötä ei taida nykypäivänä tulla vastaan.

 

[JiiPee]

Koska Windowsissa ei ole laajamittaisesti tuollaista ongelmaa, voi vika olla myös Linuxissa itsessään. Siihen ei välttämättä auta Ryzenin päivitykset. Huonolla softalla saa hyvin helposti prosessorin/koneen kaatumaan.

Windowsissa ongelmaa ei ole huomattu koska windowsilla on melko vähän henkilöitä jotka oikeasti raskasta kuormaa ajaisi. Tuo ongelma alkoi esiintyä nimenomaan Gentoo käyttäjien keskuudessa koska Gentoo on distro jossa käyttäjä käytännössä kääntää kaikki ohjelmat itse eikä asentele valmiiksi käännettyjä paketteja kuten lähes kaikissa muissa distroissa tehdään. BSD taitaa olla kanssa sellainen että paketit käännetään sorsista itse.
Ongelma on xBSD:llä ja linuksilla ja noilla ei niin kovin paljon yhteistä ole niin en oikein jaksa uskoa että olisi Linux/BSD ongelma koska noi rysen testit Intelin prossuilla ja muilla AMD prossuilla toimii ongelmitta.

Kääntäminen on todella raskasta kuormaa, olisi kiva nähtä mitä tämänkin palstan kellottelijoiden "vakaille" koneille kävisi kun asennettaisiin Gentoo ja laitettaisiin kone oikeisiin töihin.

 

[JiiPee]

Tuo ei käsittääkseni ole mahdollista, ellei AMD:lle lähetetty prossu ole ollut suoraan viallinen. Nykyään taitaa vain olla aika hankalaa saada ostettua liikkeestä viallista prosessoria. Prossussa voi olla suunnitteluvirhe, jolloin kaikki valmistuneet prossut kärsivät samasta ongelmasta, mutta se että vakiona toinen prossu toimii ja toinen ei, kun käytetään juuri samoja komponentteja, niin tälläistä ilmiötä ei taida nykypäivänä tulla vastaan.

Miksei olisi? Jokainen prosessori on yksilö. Jos ne kaikki olisi samanlaisia, niin silloinhan ne kaikki myös kellottuisi täysin samoin.
Vai tarkoititko että RMA ei ole mahdollinen? AMD on osalle tarjoutunut lähettämään jopa prossan etukäteen.

 

[Threadripper]

Mitä Phoronixin keskustelua asiasta luin, niin kaatuu myös winukan WSL:llä (tarkoitan sitä windowsin linux konsolia/mikä lie). Mutta BSD:llä olisi kerneliin tehty joku patchi jolla ongelma vähenee.

Mutta koska sama kerneli toimii Intelillä ja vanhemmilla AMD:n prossuilla, niin Ryzenissä on jokin ongelma (ehkä). Hieman epämääräistä tuo teksti tuolla Phoronixin foorumilla. Kovinkaan monen käyttäjän osalta ei voi olla täysin varma että muistit toimivat ja poweri on riittävä ja emo on OK ja että kiintis ei vetele viimeisiään.

Eihän saman kernelin toimiminen prosessorilla X tarkoita 100% toimivuutta prosessorilla Y. Ensin pitäisi oikeasti sulkea softabugi pois ja sen jälkeen voitaisiin todeta vian olevan raudassa. Joka tapauksessa toivottavasti ongelman saa ratkaistua softapohjaisesti.

Windowsissa ongelmaa ei ole huomattu koska windowsilla on melko vähän henkilöitä jotka oikeasti raskasta kuormaa ajaisi. Tuo ongelma alkoi esiintyä nimenomaan Gentoo käyttäjien keskuudessa koska Gentoo on distro jossa käyttäjä käytännössä kääntää kaikki ohjelmat itse eikä asentele valmiiksi käännettyjä paketteja kuten lähes kaikissa muissa distroissa tehdään. BSD taitaa olla kanssa sellainen että paketit käännetään sorsista itse.
Ongelma on xBSD:llä ja linuksilla ja noilla ei niin kovin paljon yhteistä ole niin en oikein jaksa uskoa että olisi Linux/BSD ongelma koska noi rysen testit Intelin prossuilla ja muilla AMD prossuilla toimii ongelmitta.

Kääntäminen on todella raskasta kuormaa, olisi kiva nähtä mitä tämänkin palstan kellottelijoiden "vakaille" koneille kävisi kun asennettaisiin Gentoo ja laitettaisiin kone oikeisiin töihin.

Kiinnostaisi tietää vähän tarkemmin mikä on tällainen "oikeasti raskas kuorma". Siinä ei ole myöskään mitään kovin ihmeellistä että sama ohjelma toimii tietyllä prosessorilla muttei toimi jollakin toisella.

Kaikesta huolimatta käyttöjärjestelmänkin saa kaatumaan ohjelmallisesti hyvin helposti, esimerkiksi noin #16801 (Running a Virtual Machine when Windows Hyper-V is enabled should NOT Crash Windows) – Oracle VM VirtualBox

Tuossakin voidaan kysyä onko vika raudassa, Virtuaboxissa, Windowsissa, BIOS:ssa tmv vai kaikissa edellisissä.

 

[peksi]

Jos kyseessä on suorittimessa oleva tilabugi niin sen triggeröiminen voi riippua tosi monesta asiasta, kuten käyttiksen skeduloinnista ja siitä mitä kuormaa ajetaan ja näiden yhdistelmästä. MSVC millä Windowsilla useimmiten käännetään natiivikoodia on ihan eri codebase kuin clang tai gcc joten ongelmaa ei välttämättä esiinny.

Se että Linuxilla tulee korruptiota ja kaksi eri BSD-varianttia joutuu lisäämään workaroundeja kerneliin Ryzenille kertoo että jotain on todennäköisesti pielessä raudan puolella.

Kaikesta huolimatta käyttöjärjestelmänkin saa kaatumaan ohjelmallisesti hyvin helposti, esimerkiksi noin #16801 (Running a Virtual Machine when Windows Hyper-V is enabled should NOT Crash Windows) – Oracle VM VirtualBox

Tuossakin voidaan kysyä onko vika raudassa, Virtuaboxissa, Windowsissa, BIOS:ssa tmv vai kaikissa edellisissä.

Tietenkin saa. Kernel spacessa hölmöillessä saa käyttiksen kaatumaan varmasti, bugiset ajurit lienee tuttuja kaikille pidempään atk:ta naputelleille.

 

[Stephen Elop]

Miksei olisi? Jokainen prosessori on yksilö. Jos ne kaikki olisi samanlaisia, niin silloinhan ne kaikki myös kellottuisi täysin samoin.
Vai tarkoititko että RMA ei ole mahdollinen? AMD on osalle tarjoutunut lähettämään jopa prossan etukäteen.

JOkainen prossu testataan ennen myyntiä. Ja testin pitäisi olla riittävät kattava, ettei vakiona ajettaessa pitäisi olla ongelmaa. Jos vakiona esiintyy myyntiin päässeiden prossujen toiminnassa eroja, niin AMD testaus ei ole riittävää, tai sen toteutuksessa on jotain mätää.

Ja kaikessa mitä valmistetaan on pieniä eroja toisiinsa nähden. jossakin mettallimutterissa on taatusti eri määrä atomeja kuin toisessa samanlaisessa samassa paikassa valmistetussa mutterissa, mutta kyseinen mutteri kuitenkin vastaa ja toimii sille asetetuissa spekseissä. Näin myös näiden Ryzen prossujenkin pitäisi toimia niille asetetuissa spekseissä. Kellotettu prossu ei kuulu tähän asiaan ollenkaan.