Sun Ultrasparc T2: cool threads op herkansing

Stroomverbruik en conclusie

De door ons geteste Ultrasparc T2-server gebruikte in rust 288W en onder belasting 330W. Dat is ongeveer honderd watt meer dan de T1-machine die twee jaar geleden op de testbank lag, maar een verzachtende omstandigheid is dat de T2-server dubbel zoveel geheugen had en relatief warme fb-dimms gebruikt in plaats van standaard ddr2-geheugens.

Een directe vergelijking is dus moeilijk te maken, maar de Ultrasparc T2 heeft in ieder geval meer stroom nodig dan zijn voorganger. Is het niet puur vanwege het hogere tdp, danwel vanwege de fb-dimms. Toch loopt het verbruik zeker niet de spuigaten uit: het is nog steeds vergelijkbaar met dat van een machine met twee x86-chips, wat gezien de prestaties in sommige tests een verre van slechte verhouding oplevert.

Prestaties

De Ultrasparc T2 is duidelijk geslaagd in zijn doelstelling om de prestaties van zijn voorganger te verdubbelen. Niet door alleen het aantal threads nog een keer op te schroeven, maar ook door de core krachtiger en flexibeler te maken. Benchmarks waar Sun de T1-processor niet eens aan mee wilde laten doen worden nu gewonnen door de T2, wat zonder meer een knappe prestatie is. Opmerkelijk is dat de rek er bij 64 threads nog niet uit is. Koppel twee processors aan elkaar en sommige benchmarks laten nog eens ruim 90% hogere scores zien. Nog opvallender is dat ze dit doen zonder extra geheugenbandbreedte.

Toch heeft het concept van Niagara nog steeds valkuilen. Een belangrijke benchmark waar Sun vooralsnog niet aan mee doet is de databasetest TPC-C. Ook in onze eigen databasetest is de T2 nog niet overtuigend: hij presteert weliswaar een stuk beter dan zijn voorganger, maar nog steeds onder het niveau van de Xeon in Mysql en vér daaronder in Postgresql.

De belangrijkste valkuil is dat de hele mooie prestaties die Sun neerzet alleen behaald kunnen worden als alle threads ook daadwerkelijk benut worden. Dat vereist goed schaalbare software, veel gelijktijdige gebruikers en in sommige gevallen ook een riante hoeveelheid ondersteunende hardware, zoals geheugen en harde schijven.

Net als moderne x86-chips ondersteunt de Ultrasparc T2 hardwarematige virtualisatie, wat het makkelijker maakt om het maximale uit de machine te slepen. Als webserver zal de chip waarschijnlijk nog steeds het makkelijkst effectief ingezet kunnen worden, maar voor andere applicaties zullen de resultaten wisselend zijn, zeker in kleinere bedrijven waar een dergelijke machine niet met tientallen dingen tegelijk bezig is.

Conclusie

De Ultrasparc T1 was een product dat zijn tijd wellicht iets te ver vooruit was. Daarbij kwam dat het een eerste generatie ontwerp was, waar altijd nog wel een aantal zwakke punten in opduiken. De tweede generatie strijkt een hoop van die kreukels recht en biedt daarnaast dubbele prestaties per socket, plus de mogelijkheid om er twee in een machine te gebruiken voor nog meer rekenkracht. Veel meer valt er niet te verwachten van een opvolger.

Hoewel de filosofie van 'heel veel threads op een chip' ondertussen al wat breder aan lijkt te slaan en de software zich er langzaam maar zeker op toespitst, is de Ultrasparc T2 nog zeker geen all-rounder. Sowieso blijft het een Sparc-architectuur waardoor Windows draaien uit den boze is. Kennis op het gebied van Linux of Solaris, of op zijn minst de bereidheid om die op te doen, is dus een eerste vereiste voor degenen die interesse hebben. De relatieve prestaties ten opzichte van een Xeon of Opteron kunnen daarnaast ver uiteenlopen afhankelijk van het soort en de hoeveelheid belasting. Wie interesse heeft in de aankoop van een T2-machine doet er dus goed aan om een (gratis) proefperiode aan te vragen, want een eenduidig advies valt simpelweg niet te geven.

Dankwoord

Dit artikel is mede tot stand gekomen met hulp van Arjen van der Meijden en Hylke Witjens van Tweakers.net. Verder gaat onze dank uit naar Sun Nederland, Robert van Maasdijk en Bart Muijzer voor het beschikbaar stellen van de hardware en in het bijzonder naar Hans Nijbacker, die een paar dagen bij ons op locatie heeft gezeten om het maximale uit Mysql te slepen.

Eerdere artikelen in deze serie

5-3-2007: 8-voudige AMD Opteron 2,6GHz
12-12-2006: Intel Xeon 'Clovertown' 2,66GHz
13-11-2006: Intel Xeon 'Woodcrest' 3,0GHz (Apollo 5)
4-9-2006: Intel Xeon 'Woodcrest' 2,66GHz
30-7-2006: AMD Opteron Socket F 2,4GHz
27-7-2006: Sun UltraSparc T1 vs. AMD Opteron
19-4-2006: Xeon vs. Opteron, single- en dualcore

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (40)

zie je dan in de task manager ook 64 cpu's? Of gewoon 8? Geen idee eigenlijk of de threads puur op de hardware zitten, maar het lijkt me dat het OS de logische processen/threads over de cores zal verdelen... Is het net zoiets als Hyperthreading in het kwadraat, of werkt het heel anders?

[Reactie gewijzigd door _Thanatos_ op 14 juli 2008 20:25]

Als Windows op Sparc zou draaien (wat niet het geval is) dan zou je inderdaad 64 grafieken te zien krijgen in task manager. Op een lager niveau weet de kernel van een operating systeem wel welke logische cores bij welke fysieke (sub)cores horen, zodat hij daar rekening mee kan houden bij het verdelen van de taken.

Is het net zoiets als Hyperthreading in het kwadraat, of werkt het heel anders?

SMT (=HyperThreading zoals het in Pentium 4 en Nehalem zit) is bedoeld is voor cores die meerdere instructies per kloktik uit kunnen voeren, bijvoorbeeld 3 of 4. Binnen 1 thread kan lang niet altijd zoveel parallellisme worden gevonden, dus er zijn vaak ongebruikte eenheden die kunnen worden gevuld met instructies uit een tweede thread.

Terwijl SMT dus een overvloed aan rekenkracht als uitgangspunt heeft, schept de T2 juist expres een tekort: 4 threads staan te wachten tot ze 1 rekeneenheid mogen gebruiken (in principe om de beurt). Door veel taken tegelijk vast te houden is er bijna altijd wel iets te doen voor de core, waardoor de bescheiden rekenkracht die hij heeft wel optimaal wordt gebruikt. Hierdoor krijg je een efficiente processor met een hoge doorvoer, ondanks lage prestaties per individuele thread.

Uiteindelijk komt het op hetzelfde neer (meer efficientie) maar de aanpak van SMT met een slimme en brede core is wel heel anders dan die van Niagara met een groter aantal smalle en simpele cores.

[Reactie gewijzigd door Wouter Tinus op 14 juli 2008 21:40]

Je ziet 64 processoren op een T5220 of 128 op een T5240. En je moet het een beetje vergelijken met hyperthreading ja, maar wel flink on steriods.

Het OS doet alsof het echte processoren zijn en hoeft dus geen dure context switches te doen om de physieke processor aan de praat te houden. Want de processor doet dit door registers te hebben voor elke virtuele processor en kan dus heel snel in hardware switchen tussen verschillende virtuele processoren en zo de physieke processor optimaal te benutten.

Let wel op dit is het verhaal in een notendop en er zit nog meer achter, maar de T2 is pas een glimp van wat de T3 en de Rock1 en Rock2 gaan brengen.

and unlike hyperthreading this actually works...
van HT werd je PC alleen maar trager.

en HT was er alleen maar zodat developers hun applicaties klaar konden maken voor een SMP toekomst, het was er niet om het dingen op de P4 sneller te maken maar voor de toekomstige Core/Xeon (dual/quad) markt dingen sneller te maken.

dit van sun daarentegen maakt dingen nu werkelijk sneller.

[Reactie gewijzigd door stewie op 14 juli 2008 22:12]

Onzin. Heb je daar een bron van? Want HT was er weldegelijk om efficienter gebruik te maken van de resources in de CPU, bijv. tijdens branche en cache misses en data dependency stalls. Op de P4 pakte dat echter niet geheel goed uit, en kon ervoor zorgen dat de twee hardware threads de hele tijd op elkaar stonden te wachten. Dit is echter een specifiek probleem van het design van de P4. HT wordt ook gebruikt in de Atom, en zal ook weer terugkomen in de Nehalem.

[Reactie gewijzigd door .oisyn op 14 juli 2008 22:27]

Ja de pc werd zo traag dat het nu weer in de Atom en Nehalem processors gebruikt gaat worden...

Task Manager? In Solaris?

Maar ja, tijdens het booten krijg je 64 logische cpu's over je scherm en met de command line tools voor cpu-stastieken en beheer zie je er ook 64. En dat is best een lange lijst dan inderdaad.

Ja waarom niet? Solaris heeft ook vast wel een grafische schil waarom je die grafiekjes tevoorschijn kunt toveren

Ik begrijp niet dat Sun vandaag de dag überhaupt nog bestaat. Bij workstations was het altijd zo dat Sun een factor 5 langzamer is en tegelijkertijd een factor 5 duurder als de PC. Tijdens mijn studie heb ik de practica altijd thuis onder Linux gemaakt en later alleen op de Sun gesubmitted.

Ook met een Sun fileserver/gateway heb ik alleen maar slechte ervaringen. Ook hier is prijs/kwaliteitsverhouding veel beter bij een Intel.

Ik begrijp ook niet dat Sun nog niet failliet is. Meestal is de IT-industrie wel redelijk efficient in het verwijderen van zinloze bedrijven (DotCom bubble). Na Google, wat volledig productloos en doorgeslagen is, komt Sun bij mij op nummer 2 van slechtste bedrijven aller tijden in de IT-industrie.

De redenen dat Sun überhaupt nog bestaat zijn waarschijnlijk dat de diegenen die beslissen over de hardware aanschaf niet de mensen zijn die er verstand van hebben (managers) en Sun heeft waarschijnlijk financiele injecties gekregen van goedlopende bedrijven (Microsoft).

[Reactie gewijzigd door b_visser op 15 juli 2008 08:43]

Voordat je dit soort wilde dingen roept, ga je eens snel verdiepen in wat SUN allemaal doet. Komt bij dat ze volgens mij hun geld voor een groot deel uit licenties/patenten halen.

Sun hardware is van een hele andere orde dan x86, je kunt dit beter vergelijken met Power van IBM en de Itanium van Intel/HP. Of dit voor jou (je bedrijf) nuttig is moet je zelf bepalen, maar als dit niet zo is niet gelijk bestempelen als zinloos.

Ik ben het er anders wel mee eens, wij werkten ook met o.a. Sun (naast HPUX, Linux op x86 en Itanium, FreeBSD en 1 verdwaalde OS X machine), en hoewel het absoluut een feit is dat die machines degelijk zijn, is het m.i. inmiddels overbodige hardware waar je veel en veel te veel voor betaalt, met een OS dat weliswaar een hoop interessante technologie bevat maar wel vreselijk is om op te werken of te onderhouden, vooral als je meerdere Solaris versies tegelijk wilt beheren. Het OS is wat mij betreft gewoon een chaos, binaries staan op 20 verschillende plekken, Sun binaries, GNU binaries, backwards compatibility binaries, Sun Studio binaries, linux compatibility binaries, allemaal in verschillende mappen. Nog irritanter is dat commerciele Sun software het daarom ook vaak wel prima vind om zichzelf in nog meer non-standard eigen mappen te installeren. Een zootje dus. Daarbij klopt Sun zichzelf altijd op de borst dat ze backwards compatibility zo belangrijk vinden, maar als je software gaat ontwikkelen met Sun Studio dan heeft elke versie weer zijn eigen bugs, quirks en problemen. Zelfs de nieuwste versie is bijvoorbeeld niet in staat om fatsoenlijk de meeste Boost onderdelen te compileren, sommige oude compiler versies compileren er meer van dan nieuwe, etc. Als je C++ wilt programmeren ben je haast gebonden aan de incomplete, ontzettend brakke en niet meer doorontwikkelde Sun stdlib implementatie (libCstd), want Sun vind het niet nodig om die up to date te maken (omdat dit oude rommel zou kunnen breken). Sun support half om half het alternatief (libstlport4), maar omdat het letterlijk onmogelijk is om dat in een commerciele omgeving te gebruiken omdat binaries met libCstd niet kunnen worden gecombineerd met libraries (dynamisch of statisch) met libstlport4 en vice versa, ben je als ontwikkelaar veroordeeld tot een crippled C++ omgeving waar je continu workarounds moet programmeren omdat 100% geldige code niet werkt: bijna alle commerciele tools en libraries zijn namelijk (als veilige keus) alleen met libCstd gemaakt... Ik werkte zelfs makkelijker op de oude HPUX doos dan op de nieuwste Solaris 10 bak die we hadden staan, en dat zegt veel want op die HPUX machine draaide een letterlijk 10 jaar oud OS en compiler.

Als ontwikkelomgeving is het dus echt waardeloos, en als server hardware overbodig, er zijn (zoals de review al aangeeft) alternatieven die even snel zijn, veel goedkoper en met een veel flexibeler en dynamischer OS (linux).

Ik denk dat Sun idd alleen overeind gehouden wordt door de technologie die ze ontwikkeld hebben en de patenten/licenties en support daarop, maar vooral door de grote klanten die hele serverparken vol met Sun hardware hebben staan als erfenis uit het verleden. Bijvoorbeeld in de semiconductor industrie (waar ik zelf in werkzaam ben) wordt nog heel veel Solaris gebruikt, zelfs op megaslome UltraSparc II hardware met SunOS 5.6 erop. Dat soort bedrijven ziet het niet zitten om al hun software en systemen ineens te switchen en blijft dus Sun hardware en support afnemen.

Ik zou in ieder geval geen aandelen Sun meer kopen, met concurrentie als IBM en Intel die ook zeer interessante nieuwe hardware klaar hebben staan denk ik dat de rol van Sun in de toekomst zal marginaliseren.

[Reactie gewijzigd door johnbetonschaar op 15 juli 2008 13:44]

Inderdaad, de "gewoonte" factor is zeker een reden dat Sun vandaag nog bestaat. "We hadden altijd al Sun en het is te veel werk naar Linux te migreren". Dat dit op te lange termijn veel meer kost dan migreren en dat de performance bij Sun veel lager ligt en ook altijd lager zal liggen wordt daarbij blijkbaar genegeerd.

Toch raar, dat in de zich snel ontwikkelende hardware industrie, een dinosaurus als Sun zich staande houden kan. De dinosaurus SGI is trouwens terecht wel helemaal verdwenen. Elke quad core pc met een GT200 of Radeon RV770 is ook vele malen sneller als een 100k SGI workstation.

Ben het niet helemaal eens met de stelling dat SGI verdwenen zou zijn, kijk maar eens in de TOP500 list van supercomputers.
SGI is nu eigenlijk meer een Supercomputer/Supercluster ontwikkelaar geworden, met als extra een Visualization module maker.

Als maker van "gewone" mid tot highend servers zijn ze inderdaad overleden....

Je hebt gelijk, in de SuperComputer sector zijn ze nog actief. Ik bedoelde ook inderdaad de "normale" workstation markt.

Het alternatief is om alle binaries maar in 1 directory zoals /usr/local/bin te installeren. Wordt wat lastig als je meerdere versies van dezelfde software naast elkaar wil draaien. Voor binaries is er naast /usr/bin voor OS binaries niet echt een standaard plaats om te installeren. Een simpele setting van je PATH env. variabele kan dit trouwens voor je oplossen.

Wat betreft C++ heb je ten dele gelijk. Het is inderdaad niet mogelijk om libraries gelinkt met libCstd en stlport4 te combineren, maar dit is zoals je zelf al aangeeft gedaan om binaire compatibiliteit met oudere software te garanderen. In jouw geval geef je daar blijkbaar niet om, maar de meeste Sun klanten zullen dit waarderen.

De problemen met C++ komen ook voort uit het feit dat C++ lange tijd geen standaard was. De STL library is pas later geintroduceerd toen Sun al gekozen had om de C++ library op de ARM van Stroustrup te baseren.

Mocht het niet mogelijk zijn om alle software met stlport4 te linken, dan kan je altijd een commerciële versie van de STL library kopen bij Roguewave of de versie van Apache downloaden.

Trouwens, het is KDE wel gelukt om Boost 1.34.1 te compileren met STDCXX. Zie http://mail.opensolaris.o...007-September/000138.html

[Reactie gewijzigd door Paridaen op 15 juli 2008 16:35]

Het alternatief is om alle binaries maar in 1 directory zoals /usr/local/bin te installeren. Wordt wat lastig als je meerdere versies van dezelfde software naast elkaar wil draaien. Voor binaries is er naast /usr/bin voor OS binaries niet echt een standaard plaats om te installeren. Een simpele setting van je PATH env. variabele kan dit trouwens voor je oplossen.

Niets mis met netjes /bin en /sbin voor systeembinaries, /usr/bin en /usr/sbin voor package installed binaries en /usr/local/bin voor user-installed spulletjes, kan je subdirs maken voor verschillende versies, eventueel commerciele dingen in /opt, etc. Zo werkt het op bijna elk modern *nix systeem. Op Solaris had ik /bin, /usr/bin, /usr/sfw/bin, /ucb/bin, /gnu/bin, /usr/local/bin, /SunWPro/bin (ook al zo'n lekker duidelijke naam voor de compiler) en misschien nog wel wat. Het is gewoon een rommeltje en een crime om fatsoenlijk bij te houden en te upgraden, en nog irritanter is dat je aliasing krijg voor allerlei binaries als je de gnu binaries installeert (wat wel zo handig is). Erg leuk voor shell scripts ook omdat de binaries van standaard commandline tools van Sun allemaal andere opties nemen dan de gnu varianten. De ellende is compleet als je dan shell scripts wilt maken die op verschillende *nixen moet werken...

Wat betreft C++ heb je ten dele gelijk. Het is inderdaad niet mogelijk om libraries gelinkt met libCstd en stlport4 te combineren, maar dit is zoals je zelf al aangeeft gedaan om binaire compatibiliteit met oudere software te garanderen. In jouw geval geef je daar blijkbaar niet om, maar de meeste Sun klanten zullen dit waarderen.

De problemen met C++ komen ook voort uit het feit dat C++ lange tijd geen standaard was. De STL library is pas later geintroduceerd toen Sun al gekozen had om de C++ library op de ARM van Stroustrup te baseren.

Eerlijk gezegd zou ik als klant liever zien dat verouderde technologie op het gegeven moment wordt uitgefaseerd, maar dan *met* behoud van backwards compatibility. Dat zou ook mogelijk moeten zijn, Sun had de oude Cstd kunnen blijven doorontwikkelen en een oudere versie meeleveren voor legacy software. Of een emulatielaag kunnen maken of whatever om stlport4 binaries met Cstd libraries te kunnen linken, lijkt me ook niet onmogelijk. Wat uiteindelijk de reden ook is, de situatie is nu in ieder geval zo dat ik als professioneel C++ ontwikkelaar het liefst met een wijde boog om Solaris heenloop omdat het garant staat voor een hoop ellende en beperkingen die je op andere unix systemen niet hebt.

Mocht het niet mogelijk zijn om alle software met stlport4 te linken, dan kan je altijd een commerciële versie van de STL library kopen bij Roguewave of de versie van Apache downloaden.

Dat zal weinig helpen want volgens mij kan ik dan nog steeds mijn eigen software niet met die STL library (of stlport4) linken als er een 3rd-party static library zonder sources meegelinkt moet worden. Als je je eigen libraries ook nog eens wilt verkopen ben je helemaal ver van huis want niet iedereen heeft die Roguewave STL library

Trouwens, het is KDE wel gelukt om Boost 1.34.1 te compileren met STDCXX. Zie http://mail.opensolaris.o...007-September/000138.html

Dat zal niet met de door Sun geleverde libCstd en Sun Studio 12 zijn dan, want 2 maanden geleden was er nog vrijwel niets van boost dat te compileren was.

Sun levert ondertussen al een paar jaar dan ook x86 systemen, zoals de x4200 die wij een tijd terug van ze kregen. De nieuwere versies daarvan zijn behoorlijk innovatief (hoeveel 1U-servers kan jij vinden die 8 hdd's kwijt kunnen, of 2U-servers met 16 hdd's, 6 pci-sloten, 16 dimm sloten, etc...).
Ondertussen biedt Sun bij de kleinere systemen een generieke behuizing waar je min of meer naar keuze 1-4 Opterons, Xeons of 1 of 2 Ultrasparc T2's in kan stoppen. Verder is de bouwkwaliteit in onze ervaring behoorlijk in orde en werkt een en ander gewoon goed. Dus ik kan me prima voorstellen dat mensen die lager in de markt (5000-15000 dollar/euro) zoeken, hun hardware bij Sun inkopen. Dat die mensen geen Sparc meer kopen omdat ie langzaam is, zegt dus niet dat ze dan maar helemaal niet meer bij Sun terecht kunnen he?

En de diverse benchmarks tonen wel aan dat deze T2 behoorlijk potent is, ondanks dat het een Sparc is.

En voor de enterprise-omgevingen boeit de single-threaded cpu-performance een stuk minder, maar wil je vooral schaalbaarheid en stabiliteit gecombineerd met een hoop service. Of die van Sun daar beter is dan die van HP, IBM etc weet ik niet, maar dat is een heel ander soort markt.

[Reactie gewijzigd door ACM op 15 juli 2008 12:32]

"Sun levert ondertussen al een paar jaar dan ook x86 systemen". Ja, maar is dit niet iets wat juist tegen Sun spreekt? Hiermee geven ze toe dat de x86 oplossing beter is en dat de klant er om vraagt.

Mijn eigene ervaringen, met een SUN fileserver zijn heel erg slecht, vooral op gebied van performance. Ik heb dan ook altijd lokaal gewerkt. Als de users al lokaal "moeten" werken, wat is überhaupt dan de zin van een server?

[Reactie gewijzigd door b_visser op 15 juli 2008 13:40]

Ze gaan met de tijd/markt mee. Waarom zouden ze uitsluitend aan een dure eigen architectuur blijven vasthouden als blijkt dat aan een groot deel van de gebruikerswensen al met de veel goedkopere x86 voldaan kan worden. Blijkbaar is voor jou 'Sun' nog synoniem met Sparc en Solaris, maar dat is het ook al jaren niet meer. Dus wat dat betreft heb jij ook nog steeds een verouderd beeld van Sun.

Het alternatief was waarschijnlijk om vast te blijven houden aan dat alles, maar dan ten onder te gaan of veel kleiner te worden. En ik betwijfel of dat een prettige keus was voor Sun

En dat één fileserver traag is, maakt nog niet alle Sun-hardware sloom, sterker nog, de x86-hardware is natuurlijk per definitie min of meer evensnel als dat van de concurrentie. Bovendien is Sun niet een leverancier van uitsluitend fileservers, maar kan je net als bij de concurrenten veel meer met hun hardware.

Nee waarom zou dat tegen ze spreken? IBM levert ook over de hele range meerdere architecturen. Ieder zijn meug danwel wat voor die specifieke oplossing het beste werkt. Zo kan je meer klanten bedienen.

Hoe je het ook went of keert, ze maken wel kwaliteit, ik heb hier een machine staan, die al 14 jaar non-stop draait (los van stroom uitval, verhuizing, etc.). De performance is niet geweldig, maar de HD en alles draait nog prima. De fan's, er is niks aan vervangen. Ik heb geen x86-hardware gezien waar je dat van kan zeggen. Het is een sparcstation 4 (109.36 Bogomips, ik ben vergeten hoeveel Mhz hij heeft: niet veel !)

Ze Maakten kwaliteit..., toen ze de aparatuur voor een groot gedeelte nog uit "specialistische" hoeken vandaan haalden. Dus de oude SparcStation / SparcServer / Sparc Classic / IPX. De Ultra 1 en Ultra2 Enterprise totaan de eerste Ultra III processor.

Nu, met bijvoorbeeld de low tot midend Fire V100 / V120 / V210 / V240 is dit echt niet meer zo.
Metname de harde schijven (OEM Sun labeled Seagate en Fujistu schijven) vallen bij bosjes om. Ook de "inhoud" van de machines laat behoorlijk te wensen over.

Toen SBus werd vervangen voor PCI ging het zo'n beetje mis met de kwaliteit (mijn eigen mening).

Oh.. @Lennie : de SparcStation 4 maakte gebruik van een SuperSparc processor, meestal van Ross Technologies of van Texas Instruments, met een snelheid van 70 MHz tot 125 MHz.

[Reactie gewijzigd door BWzes03 op 15 juli 2008 11:30]

Dan vermoet ik dat het een 110 Mhz is, maar volgens /proc/cpuinfo is de CPU wel een Fujitsu en niet van TI of Ross

Dat heb ik ook meegemaakt, hele oude Sun machines die het nog steeds doen. Op zich is dit niet iets dat voor Sun spreekt. De economische levensduur van een computer ligt rond de 3 jaar, ook al is de technische levensduur veel langer.

"Kwaliteit" zou ik het niet willen noemen, de Sun beeldschermen waren altijd al van hele slechte kwaliteit. Ik kreeg er altijd koppijn van. Dat de hardware langer meegaat komt volgens mij alleen maar omdat alles veel langzamer is en dus ook minder warm wordt.

Met de sterke opkomst van Linux en de huidige performance van x86 hardware heeft Sun geen bestaansrecht meer.

Je denkt toch niet dat hier ook nog Solaris of zelfs SunOS op staat ? Hier staat al heel lang Linux op.

Die na een paar jaar aanstaan wazig geworden en verkleurde Sony Trinitron bakken werden ook door bijvoorbeeld HP gebruikt voor hun oude werkstationlijn (heb ik ooit nog CAD practicum op zitten doen)... Op zulke rotzooi kan je de computer zelf niet afrekenen, maar dat was schijnbaar in die jaren aantrekkelijk spul om OEM in te kopen.

[Reactie gewijzigd door mae-t.net op 17 juli 2008 00:05]

misschien stomme vraag of ik heb eroverheen gelezen. Maar welk besturingssysteem word hier mee geleverd en is dit getest. een solaris versie?

De laatste officiele Solaris 10 die op het moment van testen beschikbaar was, ik meen 11/07 of 04/08 oid.

Dat kan alleen Solaris 10 update 5 (04/08) zijn of update 4 (11/07) met patches om goed met de architectuur om te kunnen gaan.

Dan was het 04/08
Hmm, nu twijfel ik. We hebben de meeste tests wel ruim voor april 2008 gedaan. Maar volgens mij zijn de MySQL- en PostgreSQL-resultaten die je hier ziet allemaal van april 2008. En kort daarvoor hebben we een verse Solaris dvd van Sun gekregen.

[Reactie gewijzigd door ACM op 14 juli 2008 22:42]

Dan zal het update 4 zijn aangezien update 5 toen nog op de pijnbank lag. En als ik me niet vergis werden ze toen ook met update 4 uitgegeven. Niet dat het veel uitmaak aangezien het voornamelijk aansturing van hardware foutdetectie enzo gaat en om de dual en quad sockets beter van dienst te zijn. De juiste Sun Studio of Java virtual machine helpt redelijk veel. Wat wel interessant is, is om een keertje te kijken naar de T5240 of T5440. Zeker omdat dit systemen zijn die hardware technisch wat redundanter zijn dan zeg de T5120 of T5220.

Wat me trouwens wel opvalt is dat je duidelijk het verschil ziet tussen hoe MySQL en PostgreSQL werken. Attribuut lockin vs MVCC. Je ziet ook wel een redelijke indicatie dat MySQL zich wat anders gaat gedragen wanneer het aantal gebruikers een meervoud van 8 heeft met zeg -1 en +1 als afwijking. Ik gok dat dit gedrag op de Victoria Falls serie alleen maar duidelijker zichtbaar gaat worden.

Het is stof tot nadenken voor zowel de beheerders, developers en mensen die de hardware maken. En een punt kan misschien zijn dat lockin in deze vorm wel zijn langste tijd heeft gehad, maar dat zal de tijd ons leren.

Solaris 10_508 is inderdaad de laaste maar met 10_807 kan het ook met wat extra patches voor de T2's...(geloof dat 127111-11 en 120011-36 de belangrijkste zijn, maar pin me er niet op vast, laaste Solaris 10 (u5 van 0508) gebruiken is het makkelijkste...

Heb net een T5240 staan hier... (lekker hoor... :-) )

Wat staat er uit op de horizontale as van de grafieken? Misschien handig om dat er bij te zetten (geen idee waarom dat weggelaten is eigenlijk).

En in het tabelletje op pagina 3 staat 1.2 GHz bij elke T2 terwijl in het artikel verder overal 1.4GHz staat.

[Reactie gewijzigd door Jaaap op 14 juli 2008 18:11]

Op horizontale as is het aantal gelijktijdige gebruikers uitgezet, wat op zich ook goed uit de tekst valt op te maken. Het had er inderdaad ook wel expliciet bij mogen staan, maar dat is meer een aandachtspuntje voor de volgende keer dan reden om alles opnieuw te uploaden .

En in het tabelletje op pagina 3 staat 1.2 GHz bij elke T2 terwijl in het artikel verder overal 1.4GHz staat.

Volgens mij wordt 1,4GHz alleen maar genoemd bij "Benchmarks van derden" en die zijn dus niet door ons zelf gedraaid. Onze eigen tests zijn op 1,2GHz-versie uitgevoerd. Als dat ergens wordt tegengesproken dan hoor ik het graag, want dat zou echt een fout zijn.

[Reactie gewijzigd door Wouter Tinus op 14 juli 2008 18:46]

Zijn de getallen die op de x-as staan ook de daadwerkelijke testpunten, of is er bijv getest op 16/32 etc gebruikers en heeft jullie graphing progje er willekeurige schaalverdelingen onder gezet? Page 4 staat naast de grafiek dat de prestaties "na 32 gebruikers" inzakken, terwijl het meetpunt volgens de grafiek zelf op 30 heeft gelegen.

Ik loop achter, FBD-ram?

FullyBuffered DIMM , zou volgens de specs sneller moeten zijn dan "normale" DDR2 DIMMs, maar metname door de hogere voltage die het nodig heeft verstookt het meer vermogen en wordt behoorlijk veel warmer. Hierdoor heeft het ook weer meer ventilatie nodig. Wat je zal zien is dat er een extra fan dedicated op het geheugen staat.
Wordt ook in verschillende Intel-based servers gebruikt.
Het is uiteraard ook ECC registered geheugen voor hardware based detectie van fouten.

In het overzicht staat max 123W en in de conclusie 300W. Wordt hier met 2 maten gemeten of snap ik het niet?

Het ene gaat vast over enkel de processor en het andere over de complete server En die 123W is overigens het maximaal mogelijk opgenomen vermogen, wat je in de praktijk zelden tot nooit zal tegenkomen.

[Reactie gewijzigd door ACM op 17 juli 2008 17:39]