Az Ubuntu nem támogatja hivatalosan az UltraSPARC gépeket a Hardy-ban

Ubuntu

2006 tavaszán jelentette be a Canonical és a Sun Microsystems, hogy az Ubuntu 6.06-os LTS (kódnevén Dapper Drake) kiadása támogatni fogja a Sun Microsystems UltraSPARC(R) processzoros szervereit. Azóta az Ubuntu kiadások rendre támogatták a Sun SPARC gépeit. Azonban az Ubuntu Technical Board kedden úgy döntött, hogy hamarosan megjelenő, következő LTS kiadás, az Ubuntu 8.04 (kódnevén Hardy Heron) hivatalosan nem kínál majd telepítőt ezekhez a gépekhez. A Hardy kiadás által hivatalosan támogatott processzorarchitektúrák az i386 és az amd64 lesznek.

( lacika v | 2008. 03. 16., v – 10:50 )

Kell a fenének linux sparcra :)
Korábban sem értettem, miért is jó, hogy ubi futkos a sparc gépeken.
Igaz egyszer raktam fel én is V240 -re egy gentoo -t. "Vicces volt" :)

--
http://laszlo.co.hu/

( denes | 2008. 03. 16., v – 10:59 )

hat ez ertheto. ad 1) linux illetve az x.org nem is tamogatja per pillanat az ujabb sun workstationoket (Blade 1500, ultra 45), csak az osregieket. ad 2) a SPARC a desktopon evek ota halott ugy.

- Use the Source Luke ! -

Persze, az M5 -ös BMW is lassú egy kerékkel....
Mennyszer írjuk le, hogy ne hasonlíthasd a pc architektúrát a sparc -hoz!
Szerinted melyik bírja jobban a nagy terhelhetőséget? Hogy viselkedik egy pc 60-70 -es load mellett és hogy viselkedik szerinted ugyan ekkora terhelés mellett egy sparc? Ezt is vedd figyelembe ne csak a magok számát, meg az MHz -t! Ha már magok, mennyi szálat tud egyszerre kezelni egy quoad xeon és mennyit egy T2?? Szerinted ez sem számít?

--
http://laszlo.co.hu/

Ne csináljuk ezt, egy ultrasparc IIIi ugyanúgy viselkedik 60-70 load alatt, mint bármi más. Eltekintve attól, hogy ezt mondjuk 10-szer kisebb terhelés elő tudja belőle hozni, mint az Intel T7300 laptopomból :)

Tehát tényleg ne misztifikáljuk a SPARC-ot. Én kizárólag a Niagaráról beszéltem.

De nem HPC-re veszed. Ha csak 30-40% -kal gyorsabb, viszont feleannyi áramot fogyaszt, és a beépített lehetőségek miatt egyébként is kevesebb vas kell (SSL), akkor a végeredmény gyakran az, hogy kevesebbe kerül. Hogy egy mag lassabb, keveset számít egy tipikusan többszálú (pl. webes) workload esetén, főleg, hogy ezeket a CPU-kat pont arra tervezték, hogy többszálú terhelés, illetve túlterhelés alatt normálisan működjenek (CMT). Ha van olyan része az alkalmazásodnak, ami mindenképp nagy single thread teljesítményt igényel, akkor azt a részt x86-ról szolgálod ki, nem is kérdés, senki nem 1 szerveres rendszerről beszélt.. Elméletileg még a válaszidő is rosszabb lenne, mint x86-nál, 1 db lekérést nézve pl. Csak ne felejtsük el mi történik terhelés/túlterhelés alatt, a válaszidők jelentősen megnőnek, és ha azért kell plusz X db node-ot üzembe állítanod, hogy a kritikus kihasználtság alatt tartsd őket, akkor megint pénzbe került, míg a Niagara jól viseli az ilyet.

Valoban, az aramfogyasztas egy igen fontos szempont.

De amugy is en nem azt mondtam, hogy a T2 sz@r (legfeljebb bizonyos aspektusbol), en inkabb arra akartam volna fektetni a hangsulyt (es legeloszor is ezt mondtam), hogy olyan rohadt draga, hogy az ar/teljesitmeny mutatoja a rossz, legalabbis szerintem. Persze az aramfogyasztas es egyebb szempontok ezt is ellensulyozhatjak.

- Use the Source Luke ! -

Pont hogy nem. A T2 -t _csak_ az ár/teljesítmény aránnyal lehet eladni. (Mennyibe kerül nekem ennek és ennek a weboldalnak az üzemeltetése ennyi és ennyi látogatóval a következő 3 évre? Hogy a legolcsóbb?)

Ha meg a listaárból számoltad, azt gyorsan felejtsd el, azért van, hogy lehessen alkudni :) Niagara eseétén mondjuk a felére.

Alkalmazásfüggő. Volt, ahol még 2005-ben egy T2k-val 4 db akkor korszerű dual Xeon vasat lehetett kiváltani. Volt, ahol nagyon nem.

Olcsóság: Magyarországon (még?) nem olyan drága az áram, hogy meg lehessen annyit spórolni. A négyzetméter és a járulékos dolgok sem kerülnek annyiba, ezért a válaszom, a listaárakkal nem. Nyilván lehetne ez az ár negyedennyi is, de feltehetően az amerikai viszonyokhoz van belőve, ahol igen, jobban kijössz. (Más kérdés, hogy eszünkben sincs listaáron adni.)

Tudnék mondani számtalan projektet ahol olcsóbb+gyorsabb, egyik sem 1-2 szerveres nagyságrendű, és itt sajnos el is veszett a magyar piac jó része. Mondom: amerika más..

Gondolom a core 2 -ben is van gigabit sebességű SSL offloader, 10 gigabites interfészek, particionálhatóság, stb?

A Niagara nagyon sikeres, de nem Magyarországon, ennek nagyon egyszerű oka van, itt vagy nem indul be egy projekt, és akkor gond nélkül elég rá egy említett core 2 PC, vagy beindul, és akkor kell venni 10 PC-t. Esetleg egy rack-nyit. Ennyi. Amerikában, ha valami webes projekt beindul, akkor dollármilliós-tízmilliós beruházások következhetnek, és igencsak megnézik, mire költik.

"Gondolom a core 2 -ben is van gigabit sebességű SSL offloader, 10 gigabites interfészek, particionálhatóság, stb?"

azt nem tudom, de abban legalabb van normalis floating-point unit. egyebkent nekem akkor is az a gyanum, hogy itt a processzor a fo ar felhajto, mert ha megnezed pl. az ultra 45-ot abban nincs semmi (se ssl offloader - az amugy mi? -, se 10 gigabites interfesz), es megis tizszer annyiba kerul mint egy vele azonos teljesitmenyu 2.4 GHz-es celeron-os gep.

de tudod mit, ha az amerikaiak ezt veszik akkor te is vedd ezt!

- Use the Source Luke ! -

Pontosan. Javits ki, ha tevednek, de a legtobb szerver nem a processzorok media-enkodolo kepesseget hasznalja ki, hanem minden egyeb mast. Tessek mar megerteni, hogy normalis esetben a cel valaszt eszkozt es nem forditva. Nyilvan, ha mediat kell enkodolni, olyan szervert vesz az ember, ami abban eros, ha file-t kell tarolni, akkor olyat, ha adatbazisszerver kell, akkor meg annak valot vesz. A cel diktal es ez a lenyeg, innentol baromira nem ertem az egesz vitat.
Persze, ki lehet szolgalni P1-gyel is egy renderfarmot, csak baromi sok kell belole, meg baromi draga lesz a fenntartas, ennyi.

Eszembe jut egy történet, amikor az Opteron még újnak számított, és Opteronos Sun szervereket akartunk eladni. Elég kezdetleges volt akkor még minden, a fordítóktól az op. rendszerek amd64 támogatásáig. Így a tesztgép átadásakor meghagytuk, hogy ha performance probléma van, hívjanak és együtt megoldjuk. Többnyire így is lett. Egy helyről viszont visszaküldték a vasat: lassabban tömörítette be a divx-et, mint a referencia gép. Ha a megfelelő szoftverrel próbálkoztak volna, 3x olyan gyors lett volna, de ez nem számított, mert egyébként is web kiszolgáló lett volna (php/mysql), ugye azt pont singlethread divx tömörítéssel lehet a legjobban tesztelni..

Egy helyen egész konkrét igény merült fel, adatbázis szervernek szerettek volna vasat, szintén web. A követelmény az volt, hogy az akkori rendszerük teljesítményének a négyszeresét tudja. Kaptak egy teszt gépet, valami SPARC, mert akkor még nem voltak ilyen erős x64 vasak, és az aktuális rendszerük is elég nagy volt. Kinéztek egy szaftos query-t, lefuttatták. "Nem jó, ez csak 40%-al gyorsabb, mint eddig." El se jutott éles tesztig a dolog, mert nem értették meg, hogy ebben _több_ CPU van, hiába is terhelik egy teszt scriptből lekérdezésekkel 1 szálon. (igazából csoda, hogy 1 szálon is valamivel gyorsabb volt) Azt mondja, nem jó, mert ha 1 szálon nem gyorsabb 4x, akkor az oldal is lassú marad. Mondom nem marad, mert nem fogja a 9-es load lenullázni a teljesítményt. ...

6 orajel kutyat nem erdekli, esetleg
elegazasokkor lehet rossz, kb. ekkora buntetes x86 nel is szerintem.

Sparckon a vegrhajto egyseg ekkor sem fog unatkozni, mert akkor egy masik szal utasitasat hajtja vegre, hasonloan, mint cache missnel. (persze, ha minden szalon cache miss vagy elagazasi gondok vannak akkor nem :))

Nem egyeten taskos mukodesben fog sparck nyerni. Nem arra van.

szerk:
(1inst/clock felett, nehany altalanos utasitas van x86 on.)
De, AFIK rengeteg van ami 1 inst/clock felett van.

RISC eknel osi szokas , (kvazi)minden utasitas 1/clock, gyakori kivetel az ugrasok.

Az, hogy a VIS szar, meg mindig nem erv egy olyan processzor csaladnal, ami szerverre van kihegyezve, lasd pl. T1/T2. Ovatosan fogalmazva is baromsag. Eleg reg volt utoljara, mikor valamelyik idiota ebbol desktopot akart csinalni. Render farm sem igazan jo pelda, mert eleg specializalt terulet, a teljes felhasznalasra levetitve eleg jelentektelen hanyadot kepvisel. SUN vackait nem ilyen (es ilyesmi helyeken) szoktak hasznalni.

---
pontscho / fresh!mindworkz

Az IDC szerint az összes szerver eladás 19%-a, a szerver processzoroknak meg konkrétan 25% -a HPC projektre megy. Szóval ha nem is pont render farm, de nem nevezném jelentéktelen hányadnak.

Azt sem lehet mondani, hogy nem érdekli a Sun-t: amióta kitalálták, hogy újra beszállnak a HPC-be, szép csendben megvették a Lustre-t, megépítették a világ legnagyobb IB switch-ét, csináltak egy erre való blade platformot, és átadtak egy elég nagy "szuperszámítógépet", ami, ha jól számolom, első lenne a top500-on (504tflops), ha a Blue Gene/L -t közben nem bővítik ki (478->596tflops). Az egészből csináltak egy termékvonalat (Constellation), akár meg is lehet venni és építkezni. Az érdekes benne, hogy az utolsó csavarig Opteron node-okat tartalmaz, beleértve azokat is, ahol szó sincs számolásról (adatszerverek, data mover szerverek, stb).

Természetesen a Sun a seggét verné a földhöz, ha fel tudtak volna használni SPARC gépeket, ha máshol nem, az adatszervereknél. De az X4500 -ban is Opteron van, és nem T1/T2, vagy más. Valóban: célhoz az eszközt, de ne mondjunk olyat, hogy a Sun vackait nem ilyen helyeken szokták használni, szar duma. Akkor milyen helyeken? Ugyanott, ahol a Powert: legacy telepítések, vagy olyan alkalmazások esetén, ahol 1 gépen belül kell 16-32-64 stb CPU, de ha van is olyan, hogy most még nem találsz akkora x86 vasat, néhány év múlva fogsz. Még mindig a Sun tudja a legjobban eladni ezeket (a Unix szerverek területén piacvezető) de ez nem jelenti azt, hogy a technológiában hatalmas jövő van.

A Niagara más tészta, jól megy (sikeresebb, mint pl. az Itanium), de vegyük észre, hogy azért megy jól, mert olcsóbb (olcsóbban csinálsz meg vele X feladatot)

En csak a SIMD utasitasokrol beszeltem...

"(1inst/clock felett, nehany altalanos utasitas van x86 on.)"
throughput? hat eleg keves ilyen SIMD(MMX/SSE(2/3/4")) utasitas van core 2-n.

" De, AFIK rengeteg van ami 1 inst/clock felett van."
SIMD throughput core 2-n? hat nem.

"RISC eknel osi szokas , (kvazi)minden utasitas 1/clock, gyakori kivetel az ugrasok."
na most ez core 2-n is igy van, viszont sparc-on sem egeszen igy van, pl. ultrasparc 3 szorzasnal 5 orajelre leallitja a pipeline-t, es csak szoroz.

- Use the Source Luke ! -

Egy Opteront talaltam, az integer div eleg erdekes.

Valoban, /cycle eleg sokat visz.

Egy taskos mukodesben biztos jobb, az x86.
De sok szalas mukodesnel , nemi titkolozassal keverve (pl. SAMP+ipSec), akkar 16db x86 mag ellen is kilitanam T2 -versenyezni (nagyon nagy terheles, es adatbazis eseten) :)

Én óvatosabban fogalmaznék, főleg, ha még nem láttam ilyet működés közben.
Anno a T2000 esetében elmaradt az a hihetetlen teljesítményplusz, amit abban az időben ugyanígy beleképzeltek emberek ebbe a platformba: http://hup.hu/node/25442
De persze az is lehet, hogy csak én voltam béna, vagy csak nem MySQL-re és Solarisra való ez a cucc. :)

És mielőtt megjegyezné valaki, hogy de hát az a T1 volt, azóta van T2... Nos igen. A T1 után kijött a T2, a Sossaman után pedig... Mi is? Umm, a Woodcrest (max: 5160, 3G/1066MHz FSB dual core), a Clovertown (max: 3G/1333MHz FSB quad core) és a Harpertown (jelenlegi max: 3,4G/1600MHz FSB quad core).
Nem követem nagyon, mintha erre az évre akarnának még egy hat magos ráncfelvarrást, meg az új architektúrát a QPI-vel, 8 magig.

Érdekes lenne elfogulatlanul megvizsgálni a két vonal teljesítményét...

"To provide for better partial-die recovery,
OpenSPARC T2 can also be configured in 4-bank and 2-bank modes (with 1/2 and
1/4 the total cache size respectively)."

Nagyon ugy nez ki, hogy csak cache 1/4 -et hasznalja, ha csak ez egyik bank -ban van RAM.

Ahogy nezem, MYSQL test realtive egyszeru, mivel minden szal ugyan azt a tablat nezi, ugyan azzal a kulcs mezzovel, de kulonbozo kulccsal. (Igy a NUMA rendszereket sem szerencses tesztelni)

sparc realtive jol reagal cache missekre, ilyen keresesnel (nagy cache elonyben), relative keves lesz a miss, ez az elonye sem latszik igy igazan.

Nem is tudom, melyik hozzászólásnak írjam replynak, annyi hetet-havat összehordtok itt. Mind a T1, mind a T2 erőssége az kicsi I/O késleltetés és nagy throughput, a halála pedig az utasítás-végrehajtás - már csak azért is, mert az out-of-order utasítássorrend optimalizálást teljesen kispórolták a CPU-ból.

Tehát egy feladatban minél kevesebb kód kell az I/O -> feldolgozás -> I/O adat-életciklusban, annál jobban brillírozik a T1/T2. Tipikusan a tűzfalak, statikus tartalmat kiszolgáló webszerverek, fájlszerverek ezek. Ezzel szemben képesek már egy egyszerű kitömörítésen megizzadni ezek a procik.

Viszont a beépített MAU-k elég emberesen felveszik a versenyt egy még egy crypto-gyorsító kártyával is...

out-of-order utat az ia64 sem koveti, szerinted az is csak routernek valo ? Vagy a power6 ?

"out-of-order utasítássorrend optimalizálást teljesen kispórolták a CPU-ból."
Igen, mert magonkont 8 threadet jatszanak 'helyette'.

Es egy rohadt egyszalas kitomorites relative lassu lesz rajta, es ?

TILE64-el erdemes lenne versenyeztetni, I/O tulajdonsagai hasonloak.
(tile64 valoszinuleg 32 bites)

( Mico v | 2008. 03. 16., v – 11:57 )

Hogy a Technical Board mennyire nem technikai döntést hozott, látszik abból is, hogy SPARC támogatást emlegetnek, amikor olyan sose volt, egyedül a T1/T2 processzoros gépeket támogatták.

( sartek | 2008. 03. 18., k – 12:21 )

szoval valaki vonja mar le a kovetkezteteseket hogy most akkor mire jo a sparc es mire nem, plz