Sun Ultrasparc T2: cool threads op herkansing

Introductie

Bijna twee jaar geleden publiceerde Tweakers.net een review van de Ultrasparc T1, een eigenwijze serverprocessor van Sun die met zijn 8 cores maar liefst 32 threads tegelijk kan afhandelen - een wapenfeit waar de concurrentie vandaag nog steeds niet aan kan tippen. Destijds waren we echter niet heel erg onder de indruk van de als revolutionair bestempelde chip. Het was zonder meer een vooruitstrevende architectuur, maar de benchmarkresultaten bleven na verschillende tweaks door onze eigen experts en die van Sun onder de maat. We vroegen ons dan ook hardop af of de T1 niet té vooruitstrevend was.

Ondanks de vrij negatieve conclusies die getrokken moesten worden heeft Sun onze review van toen beloond met een Fire X4200, die sinds vorig jaar als mailserver in het rek meedraait. Dit is een lovenswaardig gebaar, want het komt helaas niet vaak voor dat kritiek met open armen wordt verwelkomd. In dit artikel zullen we gaan bekijken hoe het bedrijf het commentaar op het origineel heeft vertaald naar verbeteringen in de tweede generatie, de Ultrasparc T2.

De T2 wordt sinds oktober 2007 geleverd in servers, wat hem bijna twee jaar nieuwer maakt dan de sinds december 2005 leverbare T1. Door over te stappen van 90nm- naar 65nm-productie zag Sun kans om 224 miljoen extra transistors te integreren en de chip tegelijk ongeveer tien procent kleiner te maken. De meest in het oog springende nieuwe feature is het feit dat een T2 nog eens twee keer zoveel threads ondersteunt als zijn voorganger: 64 per socket.

Op de volgende pagina zullen we de originele manier bespreken waarop Sun deze verdubbeling heeft bereikt en uit de doeken doen wat er nog meer vernieuwd is in de Ultrasparc T2. Daarna werpen we een blik op de servers zelf en zullen we onze eigen benchmarkresultaten presenteren, alsook die van anderen.

64 threads op een chip

Om het aantal threads van de Ultrasparc T1 te verdubbelen heeft Sun een interessante aanpak gekozen. In plaats van zestien cores op een chip te integreren of acht threads om de aandacht van dezelfde eenheden te laten vechten is gekozen voor een hybride oplossing. Iedere core beheert twee groepen van vier threads, waarbij iedere groep bepaalde hardware exclusief voor zichzelf heeft. Onder meer de instructiedecoder, het registerbestand en de integerpipeline zijn dubbel uitgevoerd: voor iedere groep één.

Een hoop andere hardware, waaronder de geheugentoegang en het L1-cache wordt echter nog steeds gedeeld tussen alle acht threads. Je zou een threadgroep dus als een soort 'subcore' kunnen omschrijven. Als zodanig zijn ze overigens ook zichtbaar voor de software, zodat een besturingssysteem dat zich bewust is van het bestaan van de groepen kan proberen de threads er optimaal over te verdelen.

Links: UltraSparc T1-core | Rechts: UltraSparc T2-core

Bandbreedte

Om acht threads te kunnen voeden is een hoop bandbreedte nodig. Binnen de core is dat op twee manieren te merken: de verbinding tussen het L1-instructiecache en de threadgroepen is verdubbeld in breedte, waardoor hij meer opdrachten tegelijk kan ophalen. Verder is er een direct kanaal aangelegd tussen de load store unit en de crossbar. In de Ultrasparc T1 liep al het dataverkeer tussen een core en andere onderdelen van de chip via het L1-datacache. De T2 heeft echter een kortere route met twee keer zoveel capaciteit tot zijn beschikking.

Buiten de core zelf heeft Sun ook flink huisgehouden. De crossbar die alle cores en andere onderdelen van de chip aan elkaar knoopt is in capaciteit verdubbeld en ook de geheugenbandbreedte is ruim twee keer zo hoog. Dat is bereikt door over te stappen van vier kanalen ddr2-geheugen naar acht fbd-kanalen. Opmerkelijk is dat de socket van Niagara 2 ondanks deze forse uitbreiding minder pinnen heeft dan die van zijn voorganger: fully buffered geheugen heeft dus niet alleen maar nadelen. Tot slot is het L2-cache vergroot van 3MB naar 4MB en verdeeld over acht fysieke banken in plaats van vier, wat betekent dat er meer gelijktijdige lees- of schrijfacties op plaats kunnen vinden.

Integratie

De Ultrasparc T2 heeft ook een paar interessante nieuwe dingen in zijn mars op het gebied van integratie. Om te beginnen heeft iedere core voortaan zijn eigen fpu met ondersteuning voor de Sparc-tegenhanger van ssex aan boord: VIS 2.0. Toegang tot de lokale fpu is meer dan zes keer sneller dan een excursie naar de enkele gedeelde eenheid van de T1, die tot overmaat van ramp nog niet eens alle VIS 1.0-instructies ondersteunde. Samengevat: snel rekenen met kommagetallen was haast niet te doen op de vorige generatie, maar werkt prima op de nieuwe chip.

Ook de encryptie-hardware is bij de Ultrasparc T2 in de core getrokken en flexibeler gemaakt. Ondersteuning voor een aantal populaire coderings- en hashing-algoritmes zoals AES, SHA256, Elliptic Curve, CRC32 en 3DES zijn nieuw toegevoegd, terwijl de functionaliteiten uit de T1 (RSA, DSA en DH) natuurlijk zijn behouden.

De encryptiehardware is speciaal ontworpen om data uit een derde integratiepronkstuk te kunnen verwerken: twee 10Gbit-ethernetcontrollers, samen goed voor ruim 2GB/s netwerkverkeer dat zonder zuchten of stoten ge(de)codeerd moet kunnen worden. De controllers zijn strak geïntegreerd met het threading- en virtualisatiemodel van de T2, zodat de datastroom ook onder zware belasting nog soepel door de chip heen kan lopen. Tot slot heeft Sun zijn 3,1GB/s Jbus-interface ingeruild voor een standaard PCI Express x8-link die 4GB/s op en neer kan schuiven.

Gezien de grote verbeteringen die zijn aangebracht op core- en chipniveau is het geen wonder dat de kloksnelheid niet verhoogd kon worden. De chip blijft steken op dezelfde bescheiden 1,4GHz als zijn voorganger. De verkleining van 90nm naar 65nm kon zelfs niet voorkomen dat het tdp ruim de helft omhoog moest. Met 123W is de Ultrasparc T2 echter nog steeds geen extreme heethoofd, zeker niet als Suns claim dat het 'typische' vermogen maar 16 procent is gestegen (van 72W naar 84W) in de praktijk waar wordt gemaakt. Hieronder de belangrijkste specificaties op een rijtje:

	Ultrasparc T1	Ultrasparc T2
Cores	8	8
Threads per core	4	8
Procédé	90nm	65nm
Kloksnelheid	1,0 - 1,4GHz	1,0 - 1,4GHz
Aantal transistors	279 miljoen	503 miljoen
Grootte totaal	378mm²	342mm²
Grootte core	11mm²	12mm²
Pipeline lengte (integer)	6 stappen	8 stappen
Pipeline lengte (float)	N.v.t.	12 stappen
Max. instructies per klok	1	2
L1-cache (per core)	8KB data, 16KB instructie	8KB data, 16KB instructie
L2-cache (gedeeld)	3MB	4MB
Geheugencontroller	4x DDR2-533 (17,1GB/s)	8x FBD-667 (63GB/s)
Interne crossbar	134GB/s	268GB/s
Aantal pinnen socket	1933	1831
Maximumverbruik	79W	123W
Typisch verbruik	72W	84W

De systemen

Net als de vorige generatie komt de Ultrasparc T2 in 1U- en 2U-servers, waarmee de klant keuze krijgt tussen hogere dichtheid in het rek of meer uitbreidingsmogelijkheden. De T5120 is het goedkoopste model, 1U hoog met maximaal 64GB geheugen, vier sas-schijven en drie low-profile pcie-kaarten. Dit model wordt van prik voorzien door een 650W-voeding met redundantie-optie. De 2U hoge en iets duurdere T5220 heeft ruimte voor acht schijven, zes kaarten en 750W-voeding(en).

Sinds april is er een versie van de processor beschikbaar die samen kan werken met een tweede socket, de Ultrasparc T2 Plus. Om dit mogelijk te maken moesten de 10Gbit-ethernetcontrollers worden vervangen door coherentie-eenheden. Machines met deze chip vallen dus weer terug op een externe netwerkchip. Bovendien wordt de helft van de geheugenbandbreedte opgeofferd om met de andere processor te kunnen praten, waardoor 128 threads in een dubbelloops T2-server uiteindelijk evenveel tot hun beschikking hebben als 64 threads in een enkelvoudige uitvoering. Toch heeft Sun een aantal benchmarks laten zien waarin de T2 Plus zeer goed schaalt. Daarover later meer.

De T2 Plus komt ook in twee smaken. De 1U hoge T5140-server met twee processors biedt net als de single-cpu T5120 plaats aan vier schijven, drie pcie-kaarten en 64GB geheugen. Alleen de voeding is met 720W iets sterker gemaakt. De T5240 is wel duidelijk een maat zwaarder dan zijn enkelvoudige tegenhanger: deze heeft ruimte voor 128GB geheugen, zestien schijven en 1100W-voedingen.

Server	Sockets	Max. Ram	Schijven	Pcie-slots	Startprijs	Startconfiguratie
T5120	1	64GB	4	3	€7200	4 cores, 1,2GHz, 4GB
T5220	1	64GB	8	6	€8700	4 cores, 1,2GHz, 4GB
T5140	2	64GB	4	3	€11900	2x 4 cores, 1,2GHz, 8GB
T5240	2	128GB	16	6	€14300	2x 6 cores, 1,2GHz, 8GB

De systemen die Tweakers.net testte waren een T5120 en een T5220, beide voorzien van een 8-core processor op 1,2GHz en 32GB geheugen. De catalogusprijzen van deze configuraties zijn respectievelijk 18.700 en 19.500 euro. Vier van onze eigen 150GB Raptors werden in een ZFS-stripe gehangen voor de opslag.

Mysql-benchmarks

Net als in vorige artikelen over serversprocessors zullen we ook hier weer gaan kijken naar onze zelf ontwikkelde benchmark gebaseerd op de database van Tweakers.net zelf. Een omschrijving van onze testmethodieken is hier te vinden. Net als in vorige artikelen testen we ook weer twee databases: Mysql en Postgresql.

In het verleden zijn we steeds tegen problemen aangelopen bij het opschalen van Mysql naar grote aantallen gelijktijdige gebruikers. Alle machines die we tot nu toe hebben getest bereikten hun piek om en nabij het punt waarop het aantal gebruikers gelijk was aan het aantal hardwarematige threads. Dat is op zich nog logisch, maar minder voor de hand liggend was dat de prestaties bij méér gebruikers drastisch daalden, iets waar de concurrerende Postgresql-database geen last van had.

Diverse experts van onder meer Sun en Mysql zelf waren destijds niet in staat om dit probleem op te lossen, hoewel ze wel bijzonder geïnteresseerd waren in de resultaten en druk speculeerden over verbeteringen voor toekomstige versies van de software en compiler.

Ondertussen zijn er een aantal nieuwe ontwikkelingen te melden: Sun heeft het bedrijf achter Mysql gekocht waardoor een hoop expertise op hard- en softwaregebied bij elkaar is gevoegd. Hoeveel concreet resultaat daar al uit is komen rollen is niet duidelijk, maar er zijn in ieder geval al een aantal nieuwe versies verschenen. De Ultrasparc T1 werd nog getest met versie 5.0.20, voor het vorige artikel in deze reeks over de achtvoudige Opteron was deze al bijgewerkt naar 5.0.32, maar dit keer zullen we 5.0.51 aan de tand voelen.

Mysql is gecompileerd met de door Sun aanbevolen instellingen op hun eigen Studio-compiler, inclusief een minimale broncodewijziging ten opzichte van de officiële release. Deze fix maakt de software makkelijker te optimaliseren voor de compiler door bepaalde functies te 'inlinen'. Wie dit als hocus-pocus in de oren klinkt hoeft niet te vrezen: deze versie kan net als andere voor Sun-platformen geoptimaliseerde software gedownload worden vanaf de Sun Source-site. Het enige verschil is dat Tweakers.net zelf een 64bits-versie heeft gebouwd. Deze is onder gelijke omstandigheden iets trager dan de officiële 32bits-release, maar compenseert dat met ondersteuning voor grotere geheugens en buffers.

Benchmarks

In de eerste grafiek zien we direct een schokkend verschil tussen de Ultrasparc T1 en de T2. De eerste piekt bij 248 requests per seconde en zakt bij meer dan 32 gebruikers als een baksteen naar beneden. De tweede piekt pas bij 631 requests per seconde, een ruime verdubbeling van de prestaties. Hoewel ook deze nog een kleine dip te verwerken krijgt bij meer dan 64 gebruikers, blijft de lijn uiteindelijk toch nog redelijk stabiel.

Hoewel het grootste deel van de prestatiewinst te danken zal zijn aan de nieuwe hardware, is de bijdrage van de verbeteringen die in Mysql zijn doorgevoerd ook onmiskenbaar. Behalve dat men de daling na de piek onder controle heeft gekregen, ziet ook het schaalgedrag in het algemeen er beter uit. In onze T1-resultaten zien we bij een vergelijking van de pieken slechts 33% verbetering tijdens de stap van vier naar acht cores, terwijl we daar in de T2-benchmarks 59% uitslepen.

Wanneer we de prestaties van de Ultrasparc T2 vergelijken met die uit eerdere reviews kunnen we een iets beter referentiekader geven. We zien hier dat een server met een stel 2,66GHz quadcore Xeons een piek haalt van 616 requests per seconde, bijna even hoog als die van de T2. Het verschil is dat deze standaard x86-machine al optimaal presteert met ongeveer 8 gelijktijdige gebruikers, terwijl de Sun-machine echt met 64 dingen tegelijk bezig moet zijn.

Wanneer de software in zoverre brak is dat de prestaties inzakken na de piek dan wordt de beste keus bepaald door de verwachte belasting. Mysql gedraagt zich nu echter al een stuk beter dan toen we deze Xeon op de pijnbank hadden liggen. Bovendien zal een Barcelona of Harpertown naar verwachting beter scoren dan de Clovertown, waardoor het goed mogelijk is dat x86-chips het inmiddels weer over het hele spectrum kunnen winnen in deze test. We hebben het dan wel over twee Xeons of Opterons tegenover één Ultrasparc T2, maar dat is qua prijsklasse nog wel te verantwoorden.

Mysql heeft de afgelopen maanden een dusdanige verbetering ondergaan dat we de resultaten ook wilden vergelijken met die van Postgresql. In de vorige artikelen uit deze serie moest steeds weer geconcludeerd worden dat deze eveneens als open source beschikbare 'conculega' op het vlak van schaalbaarheid en prestaties beter werkte, maar die achterstand is ondertussen in ieder geval deels ingehaald: Mysql 5.0.51 presteert gemiddeld 25 procent beter dan Postgresql 8.3.1 op de T2-machine. Het antwoord op de vraag of dit ook voor andere architecturen geldt dan Sparc moeten we de lezer helaas verschuldigd blijven, maar op de volgende pagina gaan we de tweede database in ieder geval wel uitgebreid bekijken.

Postgresql-benchmarks

Ook de programmeurs van Postgresql hebben het afgelopen jaar niet stil gezeten. Waar we in eerdere artikelen met ontwikkelbuilds van versie 8.2 aan de slag moesten, konden we voor dit artikel de officiële 8.3.1-release gebruiken. We compileerden de software zelf met de Studio-compiler van Sun, waarbij dezelfde optimalisatie-opties werden gebruikt als voor Mysql. Er werden hier echter geen aanpassingen aan de code gedaan. In dit geval was er nauwelijks een prestatieverschil meetbaar tussen de 32bits- en 64bits-versies, ook niet met de grotere buffers die laatstgenoemde mogelijk maakt.

In de eerste grafiek zien we een opmerkelijk resultaat: de prestaties van de Ultrasparc T1 en T2 zijn vrijwel identiek bij een gelijk aantal threads. Dit is minder vanzelfsprekend dan het wellicht lijkt, omdat de gelijke score bij de T2 steeds de helft van het aantal cores gehaald wordt. Dit geeft aan dat Sun de balans tussen de kracht van de cores en het aantal threads dat er op draait in stand heeft weten te houden, wat zeker geen vanzelfsprekendheid is. Andere implementaties van multithreading leveren hoogstens enkele tientallen procenten winst op bij een verhouding tussen fysieke en logische cores van 1:2, terwijl Sun met een verhouding van 1:8 nog de volle mep pakt.

Om te illustreren dat de ene thread de andere niet is zetten we in de volgende grafiek verschillende manieren om hetzelfde aantal threads te bereiken naast elkaar. Zo zien we dat 16 threads verdeeld over acht cores draaien ruim de helft betere prestaties oplevert dan 16 threads op twee cores gooien. Met 32 threads zien we ongeveer een derde betere prestaties op acht cores ten opzichte van hetzelfde aantal op vier cores.

De beste prestaties per thread worden logischerwijs bereikt door twee threads per core te laten lopen. Beide subcores worden dan bezig gehouden zonder dat threads op elkaar moeten wachten - tenzij ze bijvoorbeeld de fpu willen gebruiken, maar dat is hier niet van toepassing. Het is duidelijk te te zien dat het opvoeren van het aantal threads per core tot mindere prestaties per thread lijdt, maar zoals eerder opgemerkt is de Ultrasparc T2 een chip die goed in balans is: wat op de individuele prestaties moet worden ingeboet kan dubbel en dwars worden terugverdiend op het vlak van doorvoer.

Maximum requests per seconde per thread
8 cores, 16 threads	15,4
8 cores, 32 threads	12,5
2 cores, 16 threads	9,8
4 cores, 32 threads	9,6
8 cores, 64 threads	9,1

De laatste grafiek van deze pagina is enigszins ontnuchterend. We hebben net bijna voorbeeldig schaalgedrag en keurig verdubbelde prestaties ten opzichte van de vorige generatie geconstateerd, maar nu blijkt dat de T2 in zijn absolute prestaties zwaar tekortschiet. Een ondertussen redelijk verouderde Clovertown piekt ruim dertig procent hoger dan de Sun-processor. De Xeon presteert bovendien al optimaal bij ongeveer 20 gebruikers, terwijl de Ultrasparc er 80 nodig heeft voor hij volledig benut wordt.

Benchmarks van derden

Omdat onze eigen databasetest slechts een van de vele mogelijke (soorten) taken van een server dekt willen we in dit artikel wat extra perspectief bieden door gepubliceerde scores van een aantal gestandaardiseerde benchmarks mee te nemen. Deze scores zijn niet door ons zelf gemeten maar door verschillende derde partijen. Hierdoor zijn ze vaak niet perfect te vergelijken, bijvoorbeeld omdat er andere software gebruikt wordt of de hoeveelheid geheugen afwijkt. Toch kan er grof gezien wel vanuit gegaan worden dat iedere fabrikant zijn beste beentje voor probeert te zetten.

In Specweb2005 zien we een indrukwekkende score: de T2 scoort in zijn eentje dertig procent beter dan twee Xeons of Opterons en ruim 2,5 keer beter dan zijn voorganger. De voornaamste redenen dat de T2 hier zo sterk is zijn waarschijnlijk de ondersteuning voor een grote hoeveelheid gelijktijdige threads en de geïntegreerde hardware om zowel gewone als beveiligde netwerkverbindingen af te handelen. De chip voelt als een vis in het water als hij een website met tienduizenden gelijktijdige bezoekers mag serveren.

SPECweb2005
1x	Ultrasparc T2	1,4GHz	41847
2x	Opteron	2,3GHz	30007
2x	Xeon	3,16GHz	29591
1x	Ultrasparc T1	1,4GHz	16407

In de Java-applicatietest Specjbb2005 zien we wederom een forse verbetering van de Ultrasparc T2 ten opzichte van zijn voorganger: hij scoort bijna precies twee keer zo hoog. Hiermee komt Sun erg dicht in de buurt van de score van twee AMD Opteron-quadcores. Wanneer twee 64-threaders aan elkaar worden geknoopt blijkt zelfs de Xeon een makkelijke prooi te zijn, terwijl die bekend staat om zijn goede prestaties in deze test.

SPECjbb2005
2x	Ultrasparc T2+	1,4GHz	373405
2x	Xeon	3,16GHz	323172
2x	Opteron	2,3GHz	214587
1x	Ultrasparc T2	1,4GHz	192055
1x	Ultrasparc T1	1,4GHz	96523

In SAP-SD is het weer hetzelfde verhaal: de T2 is twee keer zo snel als de T1 en komt in zijn eentje in de buurt van de beste scores die met twee x86-chips worden gehaald. 128 samenwerkende threads laten ook hier alle andere systemen met twee sockets in het stof bijten.

SAP-SD 2-tier
2x	Ultrasparc T2+	1,4GHz	4170
2x	Xeon	3,16GHz	2449
1x	Ultrasparc T2	1,4GHz	2175
2x	Opteron	2,3GHz	2102
2x	Power6	4,7GHz	2035
1x	Ultrasparc T1	1,4GHz	1100

Specfp_rate_peak2006 is een test waarin een chip zonder bruikbare fpu bij voorbaat al kansloos is. Sun heeft voor de Ultrasparc T1 met zijn halfslachtige gedeelde eenheid dan ook nooit een score ingestuurd. De T2 is echter een op spectaculaire manier de lijst binnengekomen door de 4,7GHz IBM Power6 van de troon te stoten. Hoewel een enkele T2 nog wel zijn meerdere moet erkennen in een koppel Xeons of Opterons, is dit toch een sterk staaltje spierballen spannen van Sun.

SPECfp_rate_peak2006
2x	Ultrasparc T2+	1,4GHz	119
2x	Power6	4,7GHz	116
2x	Opteron	2,5GHz	89,9
2x	Xeon	3,2GHz	88,7
1x	Ultrasparc T2	1,4GHz	62,3
2x	Itanium 2	1,66GHz	55,8

Voor Specint_rate_peak2006 geldt ongeveer hetzelfde als bij de vorige test, alleen is het hier niet de Power6 maar Intels Xeon die zijn gouden medaille moet inleveren. In de praktijk blijken dit soort scores op een 'gewoon' systeem echter toch moeilijk te bereiken. Om maximaal te scoren moet op iedere hardwarethread een instantie van de Specfp- of Specint-benchmark draaien, waar ongeveer 1GB geheugen per stuk voor nodig is. Op alle concurrerende systemen in deze grafiek is 8GB dus voldoende, maar de Sun-machines hebben respectievelijk 64GB en 128GB nodig. Met onze eigen kopie van de Spec-suite konden we niet eens bij deze resultaten in de buurt komen, omdat we 'maar' 32GB hadden.

SPECint_rate_peak2006
2x	Ultrasparc T2+	1,4GHz	157
2x	Xeon	3,2GHz	147
2x	Power6	4,7GHz	122
2x	Opteron	2,5GHz	106
1x	Ultrasparc T2	1,4GHz	85,5
2x	Itanium 2	1,66GHz	62,8

Toekomst: duizenden threads?

Steeds vaker duikt de stelling op dat programmeurs moeten leren omgaan met tientallen, honderden of duizenden threads. Sun heeft met de Ultrasparc T2 laten zien dat dat een hele kudde relatief trage threads in veel servertests effectiever kan zijn dan een paar hele snelle, mits deze voldoende gebruikt worden.

Op dezelfde lijn gaat men voorlopig nog even door. Recent is aangekondigd dat de opvolger van de T2 maar liefst 256 threads krijgt verspreid over 16 cores. Al langer bestaat het plan om servers met vier en acht sockets uit te brengen, wat betekent dat het voor het eerst mogelijk wordt om relatief kleine servers met 2048 threads te bouwen.

Hoewel de "T3" op 45nm gebakken zal worden, is het bijna onmogelijk dat Sun het aantal threads kan verviervoudigen zonder het verbruik opnieuw te verhogen en/of in te boeten op de prestaties per thread. Het zal interessant zijn om te zien wat voor compromissen het bedrijf heeft gesloten om deze volgende stap te zetten en hoe zich dat laat vertalen naar prestaties.

Slimme steen

Zelfs Sun is echter niet van mening dat ieder probleem opgelost kan worden met meer threads. De 'Rock'-processor, die in 2009 moet verschijnen, valt weer terug naar een bescheidener aanpak met vier cores, die ieder vier subcores hebben met twee threads, voor een totaal van 32 threads per chip. Daarnaast zijn er nog 32 zogenaamde 'scout threads' die proberen vooruit te lopen op de hoofdthreads om er voor zorgen dat data alvast in de caches wordt geladen. Naar verluidt kunnen de scouts ook verruild worden voor normale threads, zodat de software er 64 ziet.

Naast betere prestaties per thread door de hogere kloksnelheid van 2,3GHz en de scout threads zal Rock ook een feature introduceren die het samenwerken van de threads voor programmeurs makkelijker maakt: transactioneel geheugen. Dat houdt in dat de geheugencontroller een serie van lees- en/of schrijfopdrachten kan doen die pas zichtbaar worden voor andere threads zodra de hele serie is voltooid. Een half resultaat uitlezen is dus sowieso niet mogelijk en als twee transacties met elkaar conflicteren (bijvoorbeeld als ze naar dezelfde plek schrijven) wordt er één automatisch afgebroken en herstart.

Voor programmeurs is dit een uitkomst: in plaats van iedere keer dat twee threads elkaar kunnen kruisen de prijs van een 'lock' te betalen, zorgt transactioneel geheugen ervoor dat de prestaties alleen lijden op het moment dat het écht fout dreigt te gaan. Deze feature is geen eindoplossing voor de problemen die komen kijken bij het schalen naar meerdere threads, maar wel een stap in de goede richting die mogelijk ook zijn weg naar andere architecturen zal vinden.

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]