Dual socket G34
Napsal: sob 12. říj 2013, 22:21
Zdravim, mam zhruba půl roku systém s dual socket G34 Opteronama, 2x 12 ti jádrové Interlagos engineering samply. Deska je Asus KGPE-D16. ( http://www.asus.com/Commercial_Servers_ ... /#overview ). Paměti bylo 16GB ( platforma má 8 kanálů takže je to 8x 2GB) Před půl rokem jsem dělal pro flankera ňáké benchamrky systému tak je postnu i sem.
Takže celkové zhodnocení je takovéto: By default to suxxuje a je to hrozný. Už se nedivim proč FX v serverech dostala na prdel ještě víc jak v desktopu, je to opravdu špatný. Stejně jak dektopová FX to throtluje aby se to udrželo ve svém TDP. Na svejch psanejch defaultních 2,5Ghz to jede jen při běžné práci, full load = throttling jednotlivejch jader random na 2,1Ghz. Něco jako desktopová FX3850 co má psané 4Ghz ale spusťte si na ní prime a nebude mít 4 Ghz, pokud člověk nevypne C6E či nezapne APM master mode (za cenu citelného překročení TDP) bude to ve full loadu fluktovat mezi 3,2 - 3,6Ghz. Suxx, výkon taky suxx, když si to se SW sedne tak naúrovni jednoho LGA2011 8 jádrového Xeonu. Když ne tak pod. Doteď jsem si myslel že na AM3+ to byly zabugované biosy ale EE ona je to vlastnost, ne chyba, protože i na serverovejch deskách se to děje a bios mam poslední.
Proč jsem si to nakonec nechal, je to že "turionpowercontrol" s tím funguje, a jde to i taktovat, měnit voltáže, násobiče, naprosto libovolně na obouch CPU. A hlavně jde i forcnout powerstate což odstraní i ten hroznej trhottling. Forcnutí powerstate je celkem zásadní, protože win by default na non-multithread heavy operacích hážou thready z jádra na jádro a ty pak u tohodle stroje strávěj pomalu více času probouzenim a uspávánim se než samotnou prací, je třeba aby jelo vše furt naplno, pak to začne bejt fajn.
OC které se nakonec udrží než safe-shutdownuje napájecí kaskáda je 4,2Ghz 1,35v při modul disabled (1 thread na modul 12 celkem) a nebo 3,6Ghz 1,25v všech 24 threadů enabled. Ideálních výkon vs spotřeba je 3,4Ghz 1,2v. To je oproti defaultním 2,5 ( 2,8 - 3,2 turbo, 2,1 throttling) dost velkej posun, a po těhlech úpravách to začalo podávat nádherné výkony.
Nicméně většina programů stejně neškáluje dobře nad 4 thready. Do těch 8 je to ještě celkem OK ale pak už je to bída. Třeba cinebench 10 mizérie, ale 11.5 škáluje zase krásně.
Aida paměť( ta si s tim vůbec nesedne ):
http://i.imgur.com/4x6GSIH.jpg
Aida hashing naopak ale....
http://i.imgur.com/2RpnmbN.jpg
Sandra super škáluje na pamětech, je to tam krásně vidět, naměřil jsem schválně od singlu až po 8-kanál.
http://i.imgur.com/XVAZ5xv.jpg
Pro mě nic neříkající 3Dmakry ( v systému byl Radeon 5850 ):
http://i.imgur.com/nuK7C0i.jpg
http://i.imgur.com/kRW9zpQ.jpg
Cinebenche (u 11.5 je vidět 2500, 2800, 3700, 3800Mhz):
http://i.imgur.com/Yg2OwlD.jpg
http://i.imgur.com/SrfutLB.jpg
http://i.imgur.com/Za3jhU8.gif
Winrar:
http://i.imgur.com/j556sxN.jpg
x264 (vytěžoval OK)
http://i.imgur.com/OCDaUMj.jpg
http://i.imgur.com/vC7o162.jpg
h264 (nevytěžoval OK)
http://i.imgur.com/zZkbqAL.jpg
Wprime:
http://i.imgur.com/5NlF0Pe.jpg
http://i.imgur.com/3HIEdu2.jpg
Takže sečteno a podtrženo, je to o SW. Pro běžnou práci bych i vypnul SMT a nechal to běžet 1 modul 1 thread, neni pak kolísavej výkon na thread. Jen v hrstce aplikací bych nechal běžet vše ( nastavení jader se dá ovládat v biosu). Ale jednou z nich je můj open broadcaster a real-time x265 enkóding ze zachytávací karty. Ten si s tim sedne parádně, využívá CPU na 100% a kvalita vs komprese vs bitrate které dosahuji je oproti staré I5 -760 @ 3,8Ghz což byl doteď nahrávací PC naprosto nesrovantelná.
Spotřeba. - Velice pozitivní překvapení v idlu. 90W idle, 280W full load na defaultu. 500W po OC, měřeno na zásuvce. Jednalo se o čistě CPU load na integrované grafice.
Takže shrnutí, nádherná ač postarší (PEG 2.0, saty jsou také jen 2.0, atd.) platforma, deska fajn. (hlavně podpora ram, sežere od cheapest DDR3 po ECC registered), 16 slotů 256GB max, deska, ale by default jsou ty CPU shit. Až když to člověk vyladí, přetaktuje, pohraje si s power profily, tak je to bomba. Pokud se AMD povede další generace (hlavně výrobní proces), půjde to stále točit a deska s tím bude stále kompatibilní (neni důvod aby ne pokud AMD zachová G34 a nepřesune se už na DDR4 což zatím nevypadá), tak by se to mohlo stát mým primárním PC, zatím jím zůstane I7 3820@ 5Ghz, protože je více univerzální a enkóring a recording bude dělat tahle megastrojovna.
Můj osobní komentář: G34 je stará platforma. Původně vyvinutá pro Opterony magny-cours (12 jádrové K10). Ve své době se jí dařilo průměrně. Fungovala dobře, konkurenceschopné ceny i výkon, Nehalem based 45 a 32nm Xeony však nepokořila a nepodařilo se jí v serverech dobýt zpět pozice které AMD ztratila v době Core 2 a prvních Nehalemů. Po příchodu FX architektury žádné nové desky nepřišly. Bylo možné po upgradu biosu do těchto starejch desek osadit krmě původních Opteronů 6100 (magnycours), také 6200 (Interlgagosy), a 6300 (Abu Dhabi).
Průser je že Interlagos byl fail. FX buldozer architektura v serverech propadla ještě více jak v desktopu. Obecné zhoršení IPC, velká leakage = malé frekvence, throttling kvůli těsnému TDP (kterým K10 magnycoury netrpěly) způsobily že 16 jádrovej interlagos byl tak plichta vůči 12 jádrovejm magnycourům (jediné v čem vyhrál byla spotřeba v idlu), Xeony byly kdesi v dáli. CPU byly sice levné ale to v tomhle segmentu nic neznamená. Je sice hezké že 16 jádrovej optron měl výkon jak 6 jádrovej Xeon a lepší cenu, ale tam nabídka Intelu teprve začínala. Abu dhabi (serverová variante piledriveru) už nic nezměnil. Platforma nedovedla konkurovat LGA 1567 Intelu. V sučasné době to bohužel vypadá dle roadmap že AMD zrušila budoucí výkonné opterony kompletně. Intel nyní vytáhnul IB-E a Ivy bridge EP, ala první upgrade jejich server platformy od doby 32nm Nehalemů (sandy bridge se tam nikdy nepodíval), což je obrovskej výkonnostní boost na kterej už bohužel neni odpověď.
Další problém je numa architektura. Numa znamená neunifikovanej paměťovej prostor, že každej CPU má svou vlastní paměť a komunikace s jinou částí paměti na jinym CPU je problematická (rozumněj pomalá). Jednotlivé CPU jsou slepence dvou klasických desktopových CPU, mezi sebou komunikujou HT na dvojnásobném taktu. Problém je komunikace s chipsetem a dalšími CPU. Tam je obyčejné HT, to HT které by na AM3+ deskách neuživilo PCI-E 3.0 sloty zde zprostředokovává komunikaci s polovinou paměti. Jakmile se přistupuje k paměti co je na druhém CPU, je zde tento limit, kterej u SW náročném na prostupnost může způsobovat bottleneck. U dual CPU je to ještě fajn. Ale jakmile jde o 4 CPU je to už těžkej průser. Numa aware softwaru kterej by se tomu vyhnul (dovede si alokovat paměť na své procesy podle CPU na kterém běžej) je naprosté minimum.
Intel má oproti tomu UMA paměťovej prostor. Jejich CPU nejsou slepence, maj nativní die s 10 (nyní už 12) jádry. A CPU spolu komunikujou přes QPI, které je dost rychlé nejen na to aby nic nebrzdilo, navíc se prostupnost může sčítat (i když prostuopnost quadchannelů už by default neni bottleneckem), takže čím více CPU, tím větší maj výhodu kdežto u AMD je to naopak.
Další problém obecně těcho OP strojů (bez ohledu na výrobce), je že na běžnej provoz jsou celkem nevhodné. SW obecně zatim stále suxxuje v multithreadu, a ten o kterém se říká že mu to jde zde padá do kolem. SS obvykle škáluje fajn do 8 threadů. Nad 8 threadů je to už obvykle problém. V extrémních případech výkon i klesá, kdy režie sežere víc výkonu než další thready přidaj (viz starej cinebench R10). Uspěly výpočetní programy na to optimalizované, uspěly nové cinebenchy, uspěl x264 enkodér (zde ale strašně záleží na použitém softu). Propadly herní enginy (i když i zde jsou vyjímky, takovej Cry engine 3 na 12 thradech když se vypnou moduly a dá se 4,2Ghz uuuuhmmm neni vůbec zlej.). Pokud jsem do OS nedal netlimiter, nešlo plynule přehrávat youtube. Flash si řekl, jo mam 24 jader... jo, h24 dekodér a SW render je maj... ale buffer je singlethread... takže video se škubalo protože data po 120Mbit UPC lince šla tak rychle že buffer to nestíhal a zadělalo to celej falsh (můj druhej PC s I7 3820 to stíhal easy). To jest příklad jak se špatně optimalizovanj rádoby multithread SW obsahující singlethread bottlenecky a špatnou režii postaví k věci.
Dobrej příklad naopak je open broadcaster, SW na nahrávání či streamování videa lokálně či ze zachytávacích zařízení. Zde je perfektní škálování a i využití CPU. Jelikož toto (a funkce jako sekundárního PCt obecně) je primární účel ohoto PC, tak tam jsem spokojen. Hlavní důvod ale je, že CPU jdou taktovat (to se na Xeonech nestane, to opravdu ne, Intel si na sabotování OC dává opravdu záležet od LGA115 už i v desktopu). A po odstranění trhotlingů a OC (oboje přes turionpowercontrol), se z toho stává bestie (size za cenu 500W load při výkonu na kterej Xeony potřebujou polovic), ale to je full load, idle je jen 90W). Takže po tuně tweaků + OC a srandy je to krásnej stroj. (a pokud se prosadí mantle či obecně optimalizace na 8+ threadů + AMD CPU v budoucnu i pekelnej herní stroj) Ale na defaultech tfuj a seriózní server bych na tom nikdy nepostavil. Xeony by žraly míň a předvedly mnohem víc.
Takže celkové zhodnocení je takovéto: By default to suxxuje a je to hrozný. Už se nedivim proč FX v serverech dostala na prdel ještě víc jak v desktopu, je to opravdu špatný. Stejně jak dektopová FX to throtluje aby se to udrželo ve svém TDP. Na svejch psanejch defaultních 2,5Ghz to jede jen při běžné práci, full load = throttling jednotlivejch jader random na 2,1Ghz. Něco jako desktopová FX3850 co má psané 4Ghz ale spusťte si na ní prime a nebude mít 4 Ghz, pokud člověk nevypne C6E či nezapne APM master mode (za cenu citelného překročení TDP) bude to ve full loadu fluktovat mezi 3,2 - 3,6Ghz. Suxx, výkon taky suxx, když si to se SW sedne tak naúrovni jednoho LGA2011 8 jádrového Xeonu. Když ne tak pod. Doteď jsem si myslel že na AM3+ to byly zabugované biosy ale EE ona je to vlastnost, ne chyba, protože i na serverovejch deskách se to děje a bios mam poslední.
Proč jsem si to nakonec nechal, je to že "turionpowercontrol" s tím funguje, a jde to i taktovat, měnit voltáže, násobiče, naprosto libovolně na obouch CPU. A hlavně jde i forcnout powerstate což odstraní i ten hroznej trhottling. Forcnutí powerstate je celkem zásadní, protože win by default na non-multithread heavy operacích hážou thready z jádra na jádro a ty pak u tohodle stroje strávěj pomalu více času probouzenim a uspávánim se než samotnou prací, je třeba aby jelo vše furt naplno, pak to začne bejt fajn.
OC které se nakonec udrží než safe-shutdownuje napájecí kaskáda je 4,2Ghz 1,35v při modul disabled (1 thread na modul 12 celkem) a nebo 3,6Ghz 1,25v všech 24 threadů enabled. Ideálních výkon vs spotřeba je 3,4Ghz 1,2v. To je oproti defaultním 2,5 ( 2,8 - 3,2 turbo, 2,1 throttling) dost velkej posun, a po těhlech úpravách to začalo podávat nádherné výkony.
Nicméně většina programů stejně neškáluje dobře nad 4 thready. Do těch 8 je to ještě celkem OK ale pak už je to bída. Třeba cinebench 10 mizérie, ale 11.5 škáluje zase krásně.
Aida paměť( ta si s tim vůbec nesedne ):
http://i.imgur.com/4x6GSIH.jpg
Aida hashing naopak ale....
http://i.imgur.com/2RpnmbN.jpg
Sandra super škáluje na pamětech, je to tam krásně vidět, naměřil jsem schválně od singlu až po 8-kanál.
http://i.imgur.com/XVAZ5xv.jpg
Pro mě nic neříkající 3Dmakry ( v systému byl Radeon 5850 ):
http://i.imgur.com/nuK7C0i.jpg
http://i.imgur.com/kRW9zpQ.jpg
Cinebenche (u 11.5 je vidět 2500, 2800, 3700, 3800Mhz):
http://i.imgur.com/Yg2OwlD.jpg
http://i.imgur.com/SrfutLB.jpg
http://i.imgur.com/Za3jhU8.gif
Winrar:
http://i.imgur.com/j556sxN.jpg
x264 (vytěžoval OK)
http://i.imgur.com/OCDaUMj.jpg
http://i.imgur.com/vC7o162.jpg
h264 (nevytěžoval OK)
http://i.imgur.com/zZkbqAL.jpg
Wprime:
http://i.imgur.com/5NlF0Pe.jpg
http://i.imgur.com/3HIEdu2.jpg
Takže sečteno a podtrženo, je to o SW. Pro běžnou práci bych i vypnul SMT a nechal to běžet 1 modul 1 thread, neni pak kolísavej výkon na thread. Jen v hrstce aplikací bych nechal běžet vše ( nastavení jader se dá ovládat v biosu). Ale jednou z nich je můj open broadcaster a real-time x265 enkóding ze zachytávací karty. Ten si s tim sedne parádně, využívá CPU na 100% a kvalita vs komprese vs bitrate které dosahuji je oproti staré I5 -760 @ 3,8Ghz což byl doteď nahrávací PC naprosto nesrovantelná.
Spotřeba. - Velice pozitivní překvapení v idlu. 90W idle, 280W full load na defaultu. 500W po OC, měřeno na zásuvce. Jednalo se o čistě CPU load na integrované grafice.
Takže shrnutí, nádherná ač postarší (PEG 2.0, saty jsou také jen 2.0, atd.) platforma, deska fajn. (hlavně podpora ram, sežere od cheapest DDR3 po ECC registered), 16 slotů 256GB max, deska, ale by default jsou ty CPU shit. Až když to člověk vyladí, přetaktuje, pohraje si s power profily, tak je to bomba. Pokud se AMD povede další generace (hlavně výrobní proces), půjde to stále točit a deska s tím bude stále kompatibilní (neni důvod aby ne pokud AMD zachová G34 a nepřesune se už na DDR4 což zatím nevypadá), tak by se to mohlo stát mým primárním PC, zatím jím zůstane I7 3820@ 5Ghz, protože je více univerzální a enkóring a recording bude dělat tahle megastrojovna.
Můj osobní komentář: G34 je stará platforma. Původně vyvinutá pro Opterony magny-cours (12 jádrové K10). Ve své době se jí dařilo průměrně. Fungovala dobře, konkurenceschopné ceny i výkon, Nehalem based 45 a 32nm Xeony však nepokořila a nepodařilo se jí v serverech dobýt zpět pozice které AMD ztratila v době Core 2 a prvních Nehalemů. Po příchodu FX architektury žádné nové desky nepřišly. Bylo možné po upgradu biosu do těchto starejch desek osadit krmě původních Opteronů 6100 (magnycours), také 6200 (Interlgagosy), a 6300 (Abu Dhabi).
Průser je že Interlagos byl fail. FX buldozer architektura v serverech propadla ještě více jak v desktopu. Obecné zhoršení IPC, velká leakage = malé frekvence, throttling kvůli těsnému TDP (kterým K10 magnycoury netrpěly) způsobily že 16 jádrovej interlagos byl tak plichta vůči 12 jádrovejm magnycourům (jediné v čem vyhrál byla spotřeba v idlu), Xeony byly kdesi v dáli. CPU byly sice levné ale to v tomhle segmentu nic neznamená. Je sice hezké že 16 jádrovej optron měl výkon jak 6 jádrovej Xeon a lepší cenu, ale tam nabídka Intelu teprve začínala. Abu dhabi (serverová variante piledriveru) už nic nezměnil. Platforma nedovedla konkurovat LGA 1567 Intelu. V sučasné době to bohužel vypadá dle roadmap že AMD zrušila budoucí výkonné opterony kompletně. Intel nyní vytáhnul IB-E a Ivy bridge EP, ala první upgrade jejich server platformy od doby 32nm Nehalemů (sandy bridge se tam nikdy nepodíval), což je obrovskej výkonnostní boost na kterej už bohužel neni odpověď.
Další problém je numa architektura. Numa znamená neunifikovanej paměťovej prostor, že každej CPU má svou vlastní paměť a komunikace s jinou částí paměti na jinym CPU je problematická (rozumněj pomalá). Jednotlivé CPU jsou slepence dvou klasických desktopových CPU, mezi sebou komunikujou HT na dvojnásobném taktu. Problém je komunikace s chipsetem a dalšími CPU. Tam je obyčejné HT, to HT které by na AM3+ deskách neuživilo PCI-E 3.0 sloty zde zprostředokovává komunikaci s polovinou paměti. Jakmile se přistupuje k paměti co je na druhém CPU, je zde tento limit, kterej u SW náročném na prostupnost může způsobovat bottleneck. U dual CPU je to ještě fajn. Ale jakmile jde o 4 CPU je to už těžkej průser. Numa aware softwaru kterej by se tomu vyhnul (dovede si alokovat paměť na své procesy podle CPU na kterém běžej) je naprosté minimum.
Intel má oproti tomu UMA paměťovej prostor. Jejich CPU nejsou slepence, maj nativní die s 10 (nyní už 12) jádry. A CPU spolu komunikujou přes QPI, které je dost rychlé nejen na to aby nic nebrzdilo, navíc se prostupnost může sčítat (i když prostuopnost quadchannelů už by default neni bottleneckem), takže čím více CPU, tím větší maj výhodu kdežto u AMD je to naopak.
Další problém obecně těcho OP strojů (bez ohledu na výrobce), je že na běžnej provoz jsou celkem nevhodné. SW obecně zatim stále suxxuje v multithreadu, a ten o kterém se říká že mu to jde zde padá do kolem. SS obvykle škáluje fajn do 8 threadů. Nad 8 threadů je to už obvykle problém. V extrémních případech výkon i klesá, kdy režie sežere víc výkonu než další thready přidaj (viz starej cinebench R10). Uspěly výpočetní programy na to optimalizované, uspěly nové cinebenchy, uspěl x264 enkodér (zde ale strašně záleží na použitém softu). Propadly herní enginy (i když i zde jsou vyjímky, takovej Cry engine 3 na 12 thradech když se vypnou moduly a dá se 4,2Ghz uuuuhmmm neni vůbec zlej.). Pokud jsem do OS nedal netlimiter, nešlo plynule přehrávat youtube. Flash si řekl, jo mam 24 jader... jo, h24 dekodér a SW render je maj... ale buffer je singlethread... takže video se škubalo protože data po 120Mbit UPC lince šla tak rychle že buffer to nestíhal a zadělalo to celej falsh (můj druhej PC s I7 3820 to stíhal easy). To jest příklad jak se špatně optimalizovanj rádoby multithread SW obsahující singlethread bottlenecky a špatnou režii postaví k věci.
Dobrej příklad naopak je open broadcaster, SW na nahrávání či streamování videa lokálně či ze zachytávacích zařízení. Zde je perfektní škálování a i využití CPU. Jelikož toto (a funkce jako sekundárního PCt obecně) je primární účel ohoto PC, tak tam jsem spokojen. Hlavní důvod ale je, že CPU jdou taktovat (to se na Xeonech nestane, to opravdu ne, Intel si na sabotování OC dává opravdu záležet od LGA115 už i v desktopu). A po odstranění trhotlingů a OC (oboje přes turionpowercontrol), se z toho stává bestie (size za cenu 500W load při výkonu na kterej Xeony potřebujou polovic), ale to je full load, idle je jen 90W). Takže po tuně tweaků + OC a srandy je to krásnej stroj. (a pokud se prosadí mantle či obecně optimalizace na 8+ threadů + AMD CPU v budoucnu i pekelnej herní stroj) Ale na defaultech tfuj a seriózní server bych na tom nikdy nepostavil. Xeony by žraly míň a předvedly mnohem víc.