Ende Mai war sie endlich bei uns: die neue T2000 von Sun Microsystems. Bereits lange vorher war viel über das Chip-Multithreading und Niagara zu lesen; der praktische Test ist indes immer etwas anderes.
Für uns ging es bei den Tests hauptsächlich darum, zu überprüfen, ob diese neue Technologie und die damit einhergehenden Anpassungen am Betriebssystem für unsere Software irgendwelche Probleme nach sich zieht. Um die Antwort gleich vorwegzunehmen: Sie tut es nicht. Unsere Treiber berücksichtigen bereits seit der ersten Version für Solaris 7 das Multithreading im Kernel. Tatsächlich profitiert der Treiber ohne irgendwelche Änderungen sofort von den im Betriebssystem sichtbaren 32 virtuellen CPUs. Ein eindrucksvoller Beweis für die Stabilität und Zukunftstauglichkeit der Programmierschnittstellen in Suns Solaris.
Welchen Eindruck das System sonst hinterlassen hat, nachfolgend in aller Kürze:
Angenehm beim Einbau: Es werden nur 2 Höheneinheiten benötigt. Erfreulich auch: Endlich ein Metallgehäuse, das einen durch und durch soliden Eindruck macht. Leicht abbrechende Plastikteile (Blenden, Türen etc.) sind nicht aufgefallen.
Auch die Rückseite ist aufgeräumt. Sie bietet folgende Schnittstellen bzw. Steckplätze:
Die USB-Ports sind - wie bei allen bisher gesehenen Sparc-Systemen von Sun - 1.1-Ports. Damit sind sie bestenfalls für den Anschluss von Keyboard und Maus geeignet. Aber wer braucht diese an einem solchen System, das noch dazu keine Grafikkarte besitzt? Von den PCI-X-Plätzen war einer mit dem SAS-Controller für die eingebauten Festplatten belegt. Einer verblieb für den FC-Controller.
Ganz links im Bild die beiden leicht zu wechselnden Netzteile, darüber die dazugehörige "Lüfterkarte".
Das Gehäuse lässt sich sehr einfach und ohne Werkzeuge öffnen. Inzwischen bei Sun eine hilfreiche Tradition: Auf und unter der Abdeckung finden sich Skizzen, die die wichtigsten Handgriffe veranschaulichen. Etliche Teile, so z. B. Lüfter und Stromversorgungen lassen sich ebenfalls ohne Werkzeug tauschen.
Apropos Lüfter: Am deutlichen Arbeitsgeräusch dieser unentbehrlichen Teile hat Sun leider nichts geändert. Was bei den Workstations eigentlich verboten gehört, ist bei einem Server für das RZ zwar tolerierbar, aber trotzdem unschön.
Positiv hervorzuheben ist, dass man kaum mehr ein System ohne Remote-Management-Facility zu Gesicht bekommt. Der bei der T2000 verwendete ALOM kann entweder direkt via Ethernet oder auch über V24 angeschlossen werden. Im Foto rechts oben sind die Schnittstellen mit "SER MGT" bzw. "NET MGT" gekennzeichnet.
Elegant aber tückisch sind die nicht standardisierten RJ-45-Buchsen für serielle Schnittstellen. Leider kommen diese auch beim ALOM der T2000 zum Einsatz. Um die Ethernetschnittstelle am ALOM benutzen zu können, muss man diese zunächst über die serielle Schnittstelle konfigurieren. Nach zeitraubenden Versuchen mit vorhandenen Kabeln, teilweisen Erfolgen wie Lesen ohne Eingabemöglichkeit, Mc Gyver-Sessions, um anhand der Pin-Belegung alles wie gewünscht zu verschalten, kam am Ende doch noch der volle Erfolg: Der mitgelieferte Adapter setzt nicht einfach die Pins auf eine andere Physik um, sondern er kann mit Hilfe eines normalen Patchkabels den ALOM-SER-Port mit einem DB9-Ser-Port einer anderen Solaris-Maschine verbinden (vgl. Bild rechts unten). Und dann funktioniert alles wie gehabt (tip, cu u. a.). Ein Hinweis in der Dokumentation dazu wäre sicher sinnvoll (ein DB9-Port sowieso).
Einmal konfiguriert kommt dann aber Freude auf: komplette Bedienung aus der Ferne inkl. Power-On/Off.
Bis zu 4 Platten lassen sich einbauen. Im Testsystem waren es zwei.
Zum Einsatz kommen SAS-Platten im 2,5"-Format, von denen es heißt, sie seien klein, robust, stromsparend und schnell. Vermutlich die Technik der Zukunft auch für andere Server-Systeme.
Angenehm auch das Handling beim Austausch (rechtes Bild).
Dagegen wahrscheinlich nicht jedermanns Sache: Der "Einwurfschlitz" für DVD/CD (linkes Bild oben).
Wie erwartet war die Software in 3 Minuten installiert und lief sofort. Ein erster Blick mit dem Tool ndinfo zeigte denn auch 32 CPUs an:
# ndinfo DVSC node name: sun1 OS node name: sun1 Operating System: SunOS OS release: 5.10 hardware vendor: Sun_Microsystems hardware serial: 2212015304 CPU licence units: 4 number of (v)CPU's: 32 number of cores: unknown number of chips: 1 CPU ISA: sparcv9 CPU Type: sparcv9 FPU Type: sparcv9 CPU Clock (MHz): 1000 main memory (MByte): 16376 offline method: 0 offline arguments: ""
Das System kam freundlicherweise durch Sun vorinstalliert bei uns an. Leider war es nicht der aktuellste Solaris-Stand, so daß das OSL-eigene Diagnose-Tool keine Information zur Zahl der Cores finden konnte. Aktuellere Versionen von Solaris 10 sollen aber entsprechende Informationen liefern.
Ein zweiter Blick auf die Knotenliste des Clusters zeigt das Testsystem "sun1" im trauten Verbund mit weiteren Systemen von Sun (big-2 und sparcon) sowie FSC (big-1). Es fällt ein weiteres Detail auf: Der T1-Prozessor beherrscht nicht die vis/vis2-Erweiterungen im Instruction-Set.
# ndadmin -lvvv nodename id state os cpu-isa ncpu clock memory big-1 1 ONLINE SunOS 5.9 sparcv9+vis2 2 1100 2048 big-2 2 ONLINE SunOS 5.9 sparcv9+vis2 2 1062 4096 sparcon 3 ONLINE SunOS 5.10 sparcv9+vis 1 650 256 sun1 4 ONLINE SunOS 5.10 sparcv9 32 1000 16376
Ein Blick mit mpstat zeigt uns eine detaillierte Statistik der 32 für das Betriebssystem sichtbaren (virtuellen) CPUs:
# mpstat CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3 0 79 206 104 6 0 0 2 0 10 0 2 0 98 1 1 0 1 6 1 8 0 0 2 0 7 0 1 0 99 2 1 0 0 5 0 7 0 0 2 0 8 0 1 0 99 3 2 0 0 4 0 6 0 0 2 0 8 0 1 0 99 4 2 0 1 4 0 5 0 0 2 0 9 0 1 0 99 5 2 0 0 6 0 10 0 0 2 0 13 0 1 0 99 6 2 0 0 3 0 3 0 0 2 0 10 0 1 0 99 7 2 0 0 4 0 13 0 0 3 0 31 0 1 0 99 8 2 0 0 6 0 15 0 0 3 0 21 0 1 0 99 9 2 0 0 5 0 12 0 0 2 0 25 0 1 0 99 10 1 0 0 3 0 5 0 0 2 0 9 0 1 0 99 11 1 0 0 4 0 5 0 0 2 0 10 0 1 0 99 12 2 0 0 4 0 8 0 0 2 0 17 0 1 0 99 13 2 0 0 4 0 6 0 0 2 0 12 0 1 0 99 14 2 0 0 5 0 11 0 0 2 0 17 0 1 0 99 15 2 0 0 3 0 6 0 0 2 0 11 0 1 0 99 16 2 0 0 3 0 3 0 0 2 0 11 0 1 0 99 17 2 0 0 6 0 11 0 0 2 0 12 0 1 0 99 18 2 0 3 3 0 28 0 0 4 0 71 0 1 0 99 19 1 0 0 4 0 12 0 0 2 0 25 0 1 0 99 20 2 0 1 4 1 5 0 0 2 0 15 0 1 0 99 21 2 0 0 3 0 4 0 0 2 0 8 0 1 0 99 22 1 0 0 5 0 10 0 0 2 0 13 0 1 0 99 23 2 0 0 3 0 6 0 0 3 0 16 0 1 0 99 24 3 0 0 5 0 11 0 0 2 0 16 0 1 0 99 25 2 0 0 3 0 12 0 0 3 0 23 0 1 0 99 26 1 0 0 3 0 4 0 0 2 0 11 0 1 0 99 27 1 0 1 5 1 8 0 0 2 0 15 0 1 0 99 28 2 0 1 6 0 14 0 0 2 0 17 0 1 0 99 29 2 0 1 4 0 8 0 0 2 0 23 0 1 0 99 30 1 0 0 3 0 4 0 0 2 0 9 0 1 0 99 31 1 0 2 5 2 8 0 0 2 0 22 0 1 0 99
CPU 0 zeigte stets eine höhere Zahl von Interrupts an. Auch bei Last war das so. Zu den Details des Interrupt-Handlings haben wir jedoch keine weiteren Nachforschungen angestellt.
Diese Tests standen weniger im Mittelpunkt. Tests mit einem angeschlossenen FC-RAID-System erbrachten analoge Werte wie bei vergleichbaren Systemen (V440, PW250).
Ein flüchtiger zweiter Blick galt daher der IO-Performance auf den internen Platten. Das Diagnosetool des OSL Storage-Clusters zeigt uns 2 Fujitsu-Platten am internen Controller c1:
# dksetup -t
Please wait while examining disk entries . . .
symbolic controller no. 1, hw-no. 0, SCSI_CCS, driver: pci1000,50, flags: 0x08
c1t0d0|sd( 0/ 0)|FUJITSU MAV2073RCSUN72G |0545S00PFE |70007/69994MB
c1t1d0|sd( 1/ 8)|FUJITSU MAV2073RCSUN72G |0543S00GBW |70007/69994MB
symbolic controller no. 2, hw-no. 1, SCSI_CCS, driver: fp, flags: 0x08
c2t5000402101EC04F4d0|ssd( 18/ 1912)|NEXSAN SATABl(C0A82C6E) |6A6A46CE:"S; |61439/61424MB
c2t5000402101EC04F4d1|ssd( 17/ 1913)|NEXSAN SATABl(C0A82C6E) |6A6A4627:"S; |61439/61424MB
...
Interessant daher die Frage, ob hier bereits eine Sättigung eintritt: Es wurde also via Lesen mit dd (64k Bocksize) angetestet. In beiden Fällen (Lesen von einer und von beiden Platten zugleich) erreichten die Platten jeweils gut 60 MByte/s, mit 2 Platten also 120 MByte/s:
# dd mit 64k (Lesen, eine Platte)
SunOS sun1 5.10 Generic_118822-25 sun4v 06/09/2006
10:51:38 device %busy avque r+w/s blks/s avwait avserv
10:51:40 sd0 86 0.9 981 125598 0.0 0.9
# dd mit 64k (Lesen, beide Platten)
SunOS sun1 5.10 Generic_118822-25 sun4v 06/09/2006
10:53:09 device %busy avque r+w/s blks/s avwait avserv
10:53:11 sd0 87 0.9 978 125203 0.0 0.9
sd1 87 0.9 963 123251 0.0 0.9
Bezüglich der Integer-Performance herrschte die größte Unklarheit. Natürlich ließen die Meldungen aus dem Marketing Wunder erwarten, erste Praxistests und Detailinformationen (vgl. "SUN Tzu" in iX 5/2006) sorgten eher für Desillusionierung. So werkeln zwar 8 Kerne in der CPU, der Takt wird jedoch zwischen diesen aufgeteilt. Stutzig machte auch, daß noch keine Integer-Werte von SPEC vorlagen. Anzunehmender Grund: Alle Kerne teilen sich die Float-Unit und die SPEC-Benchmarks enthalten auch Floatpoint-Instruktionen. Für die meisten kommerziellen Anwendungen sollte das jedoch von untergeordneter Bedeutung sein.
Für Klarheit sollte der im OSL Storage Cluster integrierte RIP-Benchmark sorgen. Er liefert eine Bezugsgröße ausschließlich zur Beurteilung der Integer-Performance, und zwar getrennt nach 32 und 64 Bit. Die Skalierung im Multiprocessing kann ebenfalls beurteilt werden. Weitere Details zum RIP-Benchmark finden sie hier.
Nachfolgend eine Übersicht der Ergebnisse im Vergleich zu einer SunBlade 150, einer V440 mit 2CPU sowie zu einem Opteron-System.
Für die Multi-Process-Meßwerte gibt die Spalte Procs an, mit wievielen Prozessen die maximale Gesamt-Performance erreicht wird.
| Hersteller/Modell | CPU | Single Process | Multi Process | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Typ | Takt (MHz) | Anzahl | RIP32 | RIP64 | RIPmix | Procs | RIP32 | RIP64 | RIPmix | |
| Sun SunBlade 150 | UltraSPARC IIi | 650 | 1 | 4,00 | 3,02 | 3,47 | 1 | 4,00 | 3,02 | 3,47 |
| Sun SunFire T2000 | UltraSPARC T1 | 1000 | 1 | 3,71 | 4,05 | 3,88 | 32 | 53,71 | 53,50 | 53,60 |
| Sun SunFire V20z | AMD Opteron 244 | 2191 | 2 | 14,15 | 9,96 | 11,88 | 2 | 28.30 | 19,77 | 23,65 |
| Sun SunFire V440 | SPARC IIIi | 1062 | 2 | 5,90 | 4,64 | 5,23 | 2 | 11,42 | 8,88 | 10,07 |
Bitte beachten Sie, daß die Tabelle die Systeme nicht vollständig beschreibt und sich je nach Konfiguration z.T. deutlich abweichende Werte ergeben können. Es ist für keines der Systeme eine besondere Kompilation des Benchmarks verwendet worden. OSL weist ausdrücklich darauf hin, daß damit Konsistenz und Fairness der Benchmarks nicht garantiert sind. Eine Verwendung der Werte außerhalb der Clustermechanismen von OSL Storage Cluster ist nur zu persönlichen Zwecken gestattet. Jede andere Verwendung - insbesondere für Wettbewerbsvergleiche - weicht von der Zielsetzung des Benchmarks ab und ist nur im Ausnahmefall mit vorheriger schriftlicher Genehmigung durch OSL zulässig. Von den jeweiligen Herstellern autorisierte andere Benchmarks mit einer exakten Beschreibung der Systemkonfiguration und der Testbedingungen finden Sie z. B. unter www.spec.org.i
Die Ergebnisse zeigen dreierlei:
Ein genauerer Blick auf die Skalierung zeigt folgendes Verhalten:
RIP64-MP mit 001 Prozessen: 4.05
RIP64-MP mit 002 Prozessen: 8.08
RIP64-MP mit 004 Prozessen: 16.17
RIP64-MP mit 008 Prozessen: 25.68
RIP64-MP mit 016 Prozessen: 45.29
RIP64-MP mit 032 Prozessen: 53.43
RIP64-MP mit 064 Prozessen: 53.43
RIP ^
60 |
| - -
50 |
| -
40 |
|
30 |
| -
20 |
| -
10 | -
|-
O------------------------------------------------------------------>
10 20 30 40 50 60
Erstaunlicherweise skaliert das System nicht nur bis zu 8 Prozessen, sondern bis hin zu 16 Prozessen sehr gut. Da es nur 8 Kerne gibt, hat sich das Konzept des Chip-Multithreading als erfolgreich herausgestellt. Über 16 Prozesse hinaus läßt die Skalierung zwar deutlich nach, immerhin wird aber dennoch ein signifikanter Leistungszuwachs bis hin zu 32 Threads erreicht.
Die Maschine verhält sich damit wie ein echtes symmetrisches Multiprozessorsystem. Dank der ausgewogenen 32/64-Bit-Performance wird sie im Gesamtdurchsatz bei geeigneten Anwendungen sogar etliche aktuelle Opteron-Systeme hinter sich lassen können. Dabei ist auch zu beachten, daß es die T2000 auch mit 1,2 GHz gibt (unser Testsystem hatte 1,0 GHz Taktung).
Bezieht man die kompakte Bauweise und den niedrigen Stromverbrauch mit in die Betrachtung ein, ist klar, daß die T2000 durchaus Beachtliches leistet. Im Gesamtdurchsatz kann Sie sich mit aktuellen 4-CPU-Systemen konventioneller Bauart messen.
Wichtig wird sein, daß die jeweiligen Anwendungen passen. Die Single-Thread Performance wird für Batchverarbeitung mit höheren Lastanforderungen oder beispielsweise aktuelle StarOffice-Versionen sicher zu schwach sein. Nicht alle Anwendungen lassen sich auf ein Multithreading-Modell umstellen. Auch die höhere Komplexität wird verhindern, daß ganze Anwendungen mit großer Begeisterung neu konzipiert werden: Bekanntlich ist Multithreaded Programming "die Kunst, sich gleichzeitig in beide Füße zu schießen". Dort, wo also einzelne Prozesse hohe Durchsätze erfordern, ist das System eindeutig falsch positioniert. Starke Einzel-CPUs lassen mehr Flexibilität (aber meist auch höhere Kosten) erwarten.
Für interaktive Sessions mit den meisten betriebswirtschaftlichen Anwendungen oder für Web-Server reicht die Single-Thread-Performance des T1 jedoch allemal. Was dann mit einer hohen Zahl paralleler Sessions an Gesamtdurchsatz zu erwarten ist, ist für ein derartiges System (Größe, Stromverbrauch, Preis) schon beeindruckend.