A Sun törölte a Rock processzort

Sun Microsystems

Jelek már korábban is voltak arra, hogy a késhet a Sun "Rock" kódnevű, következő generációs, nagyvállalati rendszerekbe szánt processzora és az csak valamikor 2009 első felében kerülhet az ügyfelekhez. Most azonban úgy fest, hogy a Sun Microsystems több mint öt év fejlesztés után sutba dobta a Rock kódnévre hallgató, 16 magos, UltraSPARC RK processzorának fejlesztését.

( trey | 2009. 06. 16., k – 13:11 )

Gondolom felerősödnek majd a hangok, amelyek úgy vélik, hogy az Oracle-nek nem kell a Sun hardver üzletága, bármit is mondott Ellison. A SEC-hez benyújtott jelentésből állítólag kiderül, hogy az Oracle-nek eredetileg nem volt szándékában megvenni a Sun hardver üzletágát.

"By the way, as Sun revealed in filings with the Securities and Exchange Commission, Oracle didn't originally want Sun's hardware business."

--
trey @ gépház

Nincs kérdőjel, és nem állítólag, hanem tényleg csak a szoftvereket akarta először.

"Az Oracle március 12-én tett egy javaslatot, melynek értelmében felvásárolná a Sun egyes szoftvereit, kisebbségi befektetést tenne a cégben, és további stratégiai megállapodásokat kötne. A Sun elutasította ezt az ajánlatot, és folytatta megbeszéléseit az IBM-mel."

http://href.hu/x/9ak3

A végén a link a SEC filingra.

---------------
mpu.buzz.hu

Értem, hogy nincs kérdőjel, de azon kívül, hogy

"A faithful source - a former Sun employee who requested anonymity and who still has deep ties with the server maker - said that he was told by a high-ranking Sun exec this morning that the Rock chip was canceled. The New York Times is also running a story that cites two people familiar with Sun's plans (and who also requested anonymity) as saying that Sun has canceled the Rock chip project."

Van valami hivatalosabbnak látszó? Mert én még nem találtam. Ezek elég másodkézből származó infók. Nyilván lehetnek igazak is - sőt majdnem biztos, hogy azok - de hát amíg ezt hivatalosan meg nem erősítik...

--
trey @ gépház

( prygme | 2009. 06. 16., k – 13:13 )

kár érte. kiadhatnák a korábbi niagara processzorokhoz hasonlóan a verilog forrást, isa specet, és eddig elkészült szimulációs rock cuccokat gpl alatt. hátha majd egyszer valaki...

________
61>09

( tr3w v | 2009. 06. 16., k – 13:22 )

Niagarák hogy fogytak? Egyáltalán volt rá esély (a jelen gazd. helyzetben), hogy a fejlesztés megtérül?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

biztosan, ugyanakkor az elmúlt négy negyedévben ~1 milliárd dollárnyi Niagara-gépet adtak el, kozenkvensen 300M/negyedév felett. ez azért már nem a tévedés kategória. a Niagara még a válság alatt sem csökkent eddig, a növekedésből stagnálás lett "mindössze".

---------------
mpu.buzz.hu

Csak az általam ismert esetekből ítélve számtalan olyan példát látok, ahol ilyeneket vettek, és nem is tudják, hogy hülyeséget csináltak.
Sőt, ha elmondod nekik, még téged néznek idiótának, mert hát lehet, hogy alig bírom kivárni, míg lefut az a tar, de majd amikor szarrá lesz terhelve a gép, akkor majd igazán durván fogja tolni!

Ja, de addig is, meg akkor is 4-5-ször akkora válaszidővel, mint egy ötödannyiba (kiszámoltuk) kerülő x86-os gépen.

suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Nem értetted meg. Azt érzik, hogy a gépen minden lassabban történik (tar), de anélkül, hogy egyáltalán mértek volna bármit, elhiszik, hogy ha szarrá lesz terhelve, akkor sem lesz szarrá terhelve, mert ez mindent kibír, nyolc inteles gép helyett dolgozik.
Közben meg a legtöbb helyen még ez is csak legfeljebb 40-60%-on pörög, a válaszidő (amit meg nem néznek) meg jóval lassabb, mint x86-on.

Van olyan, ahol ez a CPU nagyon jó, de a helyzet az, hogy azon helyek közül, ahol én eddig ilyet láttam nem ilyen volt. Jobban (pénzben, teljesítményben) jártak volna egy PC szerverrel.

suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Nem úgy általában a SPARC, hanem a T1/T2. Ezeknél a CPU-knál az egymagos teljesítmény nem túl jó, akkor tudja igazán kipörögni magát a proci, ha sok szálon terhelik (vagy ha a spéci fícsörjeit használod).
De egy lekérdezés (tranzakció) ma még nem túl gyakran tud több szálon párhuzamosan futni, így leginkább a válaszidőben látszik a különbség, maximális terhelésben a TPS hasonló értékeket mutat, mint egy ötödannyiba kerülő Intelen.
A Fujitsu más irányt választott, a SPARC Vx ugyanúgy "kevés" magos, mint az x86-os vonal (bár már ott is vannak 6-8 magos CPU-k), de a magok önmagukban sem lassúak.

suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

"De egy lekérdezés (tranzakció) ma még nem túl gyakran tud több szálon párhuzamosan futni, így leginkább a válaszidőben látszik a különbség, maximális terhelésben a TPS hasonló értékeket mutat"

Van erről valami teszt? Nem kötözködésből, csak érdekel.

T2-n még csak fordítottam több szálon. A gmake -j 60 elég fun tud lenni bizonyos fordítási munkáknál. :)

Ez egy T6320 blade, normál esetben még csak egy appszerver fut rajta (bea), meg valami telkós szarság, de alig terheli ki.
Később talán még kerül rá pár dolog, de nemtom mi.
Igazából ami érdekel, hogy mondjuk egy appszerver (vagy egy LAMP jellegű szerver) esetén mennyit változik egy user session válaszideje X szeres terhelés esetén. (Mekkora az a szorzó, ahol jelentősen romlani kezd a teljesítmény.)

Tudom, hogy alkalmazásfüggő, viszont pl. egy apache prefork+php esetén is kb. párhuzamos kiszolgálás van. (Mondjuk egy session válaszideje relatíve lassú, mert a php szereti a gyors cpu-t...)

Nézzük, a ping szerint gigabites linken az RTT 200-300 ms körül van. Mennyi ez egy unix socketen, amelynek a másik végén a MySQL van?

Ha a gép megfelelően van méretezve, kifejezetten hasznos, ha az alkalmazás és az adatbázis ugyanabban a kernelben fut, összehasonlíthatatlanul nagyobb a sávszélesség, és alacsonyabb a késleltetés.

Az említett gépnek meg azért van ereje, csak terhelés kell, hogy előjöjjön.

suckIT szopás minden nap! Sun X4540 teszt

A legtöbb esetben nem kivitelezhető.
Pl: webszerver DMZ-ben, adatbázis szerver intraneten.
Komolyabb cégeknél, álltalában ez van, igaz, nem feltétlen mysql, de ez most lényegtelen.

Ráadásul egy appszerver és egy db szerver teljesen más workload, és ha egyébként nagyobb terhelésre csinálod a rendszert már csak azért is érdemes szétszedni, hogy az egyiket az appszerverre hangold, a másikat az adatbázis szerverre.

Megérne az is egy misét, hogy megnézzük, melyik a jobb megoldás (persze ilyen sincs, feladatfüggő).
Szerintem ha egy gép képes elvinni a terhelést, jobb eredményt kell kapj azzal, ha a DB helyben van, persze ha nem bírja, az megint más kérdés.

A különválasztás egyébként rendben van, rengeteg minden indokolhatja amúgy is.

Más workload, viszont ebből eredően akár jól meg is férhetnek egymás mellett.

suckIT szopás minden nap! Sun X4540 teszt

Mérd ki, és ha teheted, oszdd meg, annál okosabbat senki sem fog tudni mondani. Nem tudom mik futnak az alkalmazásszerveredben, de ha pld. userek által cibált webes dolgok (mondjuk egy HUP :), akkor ott nagyon nem lesz mindegy, hogy 1 ms, vagy 3 s.

Én próbáltam egy móricka alkalmazást anno, és az Intelen mért 40-50 ms-os válaszidőhöz képest a SPARC-nak 200-250 ms-os időket is sikerült produkálnia (egy szálon). Értelemszerűen ezen az sem segít, ha 2000 user húzza a fülét, mert attól, hogy az aggregát áteresztőképesség jó lesz, a usernek még homokórázik a cucc.

suckIT szopás minden nap! Sun X4540 teszt

Ez fordítva is elő szokott fordulni, hány olyanra emlékszem, hogy te, ez a sample lekérdezés csak 6% -al gyorsabb, miért kerül ez a gép ennyibe? - Azért, mert 8 ilyen processzorod van. - ??? -Egyszerre nyolc ilyen lekérdezésed futhat. - Whata? - Ez még akkor, amikor nem vagdostak hozzád dual meg 4 magos x86 procikat (de Niagara se volt) Azóta már igen, de ugyanazok az emberek azóta se értenek ennyit se a "multithread feldolgozáshoz". Szóval az a lényeg, hogy vannak emberek, akiknek teljesen mindegy. El lehet adni egyiknek PC-t, másiknak Niagarát. Utóbbi jobb üzlet, nem?

( cheeky v | 2009. 06. 16., k – 15:41 )

Nagyon helyes. A Sparc döglött ló már hosszú évek óta...

A Solaris leginkább csak SPARC-on ér valamit, x86-on szerintem még mindig felejtős, főleg ha a Linux támogatásával, teljesítményével, elterjedtségével hasonlítom össze.
Akkor tehát ha a SPARC döglött, a Solaris is az? (ezt persze befolyásolhatja az, ha a fenti észrevétel csak a sajátom :)

suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

sztem azert van boven lehetoseg x86on is solarisnak

ha elfut a HW-en (marpedig sun x86os gepein elfut) akkor tud sokkal __kenyelmesebb__ megoldas lenni mint binux enterspajz kernel+random osszevalogatott userland

eleg ha csak zfs altal nyujtott dolgokat nezed meg vagy a zonakat pl.

--
.

Ebben igazad van (bár én például nem találom kényelmesnek a Solarist, és hiába erőszakolják a will-it-be-11-esbe (osol) a GNU szarokat, nem csak ezen múlik), csak hát kellemetlen, amikor az x86-os Solaris azért rendszeresen rohad, vannak vele kompatibilitási problémák (pld. recommended patchek felrakása után a gép nem bootol, lehet visszaállni), ellenben SPARC-on ezek azért nem annyira mindennaposak.

suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Igen, a Solaris is döglött, IMHO. Legalábbis évek óta kellemetlen érzésem van tőle, és sajnos volt pár szép összeomlása a hiperbiztonságos, ultrastabil kernel api-ra épülő überoprendszernek, tehát a Solaris felsőbbrendűsége akár egy ún. "dzsunkalinux"-szal szemben is, tekinthető bátran városi legendának. Mindkettő pont ugyanolyan kellemetlenül képes hátbaszúrni akkor, amikor az épp a legfájdalmasabb.
Tehát a válasz ezek alapján az, hogy biz lassan a Solaris is döglöttnek tekintendő.

Sokféleképpen lehet használni egy "80 SPARC berendezésből álló" gépparkot. Lehet úgy is, hogy nem piszkálod, ha nem kell, meg lehet gentoo linux stílusban is, napi upgrade, bleeding edge, mit tudom én. Nem sokan szokták úgy, de lehet. És marha gáz, amikor több napos atom szívás, panic, stb után behatárolod és reprodukálhatóvá teszed a hibát, aztán az egész tetves interneten nem találsz mást, mint a Sun fórumon 1 db bejegyzést valakitől ugyanarról a hibáról - válasz nélkül. Persze, mert mindenki más úgy használja a Solarist, hogy csak akkor nyúl hozzá, ha ütik :) Vacak Linux esetén legalább nem érzed magad annyira egyedül, bug van, de legalább nem csak nálad, konkrétan Sun Cluster vs ZFS témában olyan... jelenségek? bugok? voltak (vannak?), hogy a mai napig kételkedem benne, hogy bárki más használná..

Próbáljuk meg ezt és a kapcsolódó dolgokat: 6583425

Leírva lehet, hogy nem tűnik durvának, de amikor összeraknál 2 db X4600 + némi adalék (hozzá való) ethernet kártya, és nem megy, és olyan hibákat produkál, hogy a hajad égnek áll, és már mindent kicseréltél, aztán megtalálod a jelenséget a Sun fórumokon több embertől különféle körülmények között, no reply, ... Nem reprodukálható, a f***t nem, bármikor megmutatom.

A másik olyan probléma, hogy resource group, zpool-on, rajta 1 db sczbt resource, a zpool SAN-on van. Kicsit nagyobb az _olvasási_ terhelés a zpool-on, (elég nagy), akkor a zpool kissé beállhat, a scz check script eltimeout-ol, a framework migrációt kezdeményez, (zóna leálltás, zpool export, stb lenne a folyamat), ez a gyakorlatban sose ér véget, néha reboot a vége, workaround = scriptekbe belepiszkálás, de annyi erővel már lassan ubuntu linux is lehetne, végleges megoldás UFS használata amivel érdekes módon a korábban 3-4 perc migration is 5 mp lesz, meg be se lassul, amúgy ez a probléma is fent van a Sun fórumokon és meg nem láttam semmi értelmes választ, a környezet HP EVA-n ZFS HAStoragePlus, zone resource, abban DB2 instance, de nem hiszem, hogy számít mivel mások, akik reportolták 6140-el tapasztalták és valami teljesen random alkalmazással, de ez is olyan hogy bármikor elő tudom hozni, ha kell, csak már a hányinger kerülget, ha csak rágondolok.

Megkérdezném, hogy egyetlen ilyen hiba megtalálásához hány év kellett (vö: kollegának 15 év alatt egy sem volt), de a ZFS eleve értelmetlenné teszi a feltételét.

Mondjuk csaltál, mert SPARC-ról volt szó, azon biztos nem jönne elő. :)

suckIT szopás minden nap! Sun X4540 teszt

Ha rosszindulatú akarnék lenni, azt mondanám, a ZFS cucc sparcon csak azért nem jön elő, mert nem jutna el odáig az alkalmazás, hogy úgy meghúzza az EVA-t. ;)

De nem vagyok rosszindulatú, szóval maradjunk annyiban hogy V445-ön simán volt a másik bug, de az már részben javítódott

Nem az oprendszer tehet arról, hogy egy fos, taknyolt architektúrán kell futnia. Értsd: x86, és itt pl. nem feltétlenül az ISA-ra gondolok, hanem arra a szörnyűségre, ami x86-on egy bootfolyamat alatt lezajlik. A SPARC és az OFW sokkal letisztultabb.

Mondjuk lehet, hogy az EFI ezen változtatna, de róka fogta csuka: senki nem tér át rá, csak az Apple merte megtenni (de ők is csak azért, mert a userek kognitív disszonanciája úgyis elnyomja az ellenkezésüket :))).

--
"How do you work in a team situation when all the other team members are fools and idiots?"

EFI-ről volt szó, a nextgen BIOS-ról, melyet az Itaniumhoz dolgozott ki az Intel, majd kiterjesztették máshova is. Nem ISA-hoz kötődik, támogatást az OS felől kell kapnia, hogy kihasználhasd az előnyeit.

http://en.wikipedia.org/wiki/Extensible_Firmware_Interface

---------------
mpu.buzz.hu

Nem, nem EFI-ről volt szó, hanem arról, hogy az x86-ok bootfolyamat még mindig taknyolt, 20 éves gány. Az EFI segíthetne ezen, de _x86_-on senki nem tér át rá, mert nem mernek.

Saabi a "senki"-hez szólt hozzá, de a téma szempontjából a !x86 Itanium irreleváns. Az is, hogy az EFI platformfüggetlen elvileg. Attól még x86-on ugyanaz a gány van.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Bocs, félreértettem hogy mi mire volt válasz. Szóval nem tudom, mint technológiai felhasználót, kit érdekel, hogyan bootol fel az x86. a cégek láthatóan megoldották, az IBM Nehalem gépei pl. már UEFI-vel érkeznek, nyilván visszafelé kompatibilis a BIOS-szal. A Windows Server 2008 támogatja pl, az RHEL csak a 6.0-tól, tudtommal.

UPD: persze máshol is vannak UEFI-s gépek, pl. a Dellnél is a nehalemes gépek.

---------------
mpu.buzz.hu

( praetor | 2009. 06. 16., k – 15:52 )

hat akkor varhatunk tovabb az elerheto tranzakcionalis VMre :-(

( trey | 2009. 06. 16., k – 17:39 )

Cím frissítve. Egy neve elhallgatását kérő forrás állítja, hogy 100%.

--
trey @ gépház

( Yorirou | 2009. 06. 16., k – 22:18 )

Így műlik el a világ dicsősége :(