4-fach Opteron Server Review bei Ace's Hardware

[reunion]

In dem Review wurden ein 4-fach Opteron 848, ein Dual Opteron 248, und ein Dual 3.06 GHz Pentium 4 Xeon DP (1 MB L3) System miteinander anhand von Server Benchmarks verglichen.

"The Quartet system proves that the Opteron platform is completely ready - with regard to the hardware part - to make headway in the market against the Xeon and Itanium: it has all the RAS features that a modern server CPU must have and it comes with supreme processing power. Now it just needs better support from the software vendors."

http://www.aceshardware.com/read.jsp?id=60000275

mfg
reu

[Endorphine]

In der aktuellen iX ist auch ein Shootout dieses Evaluationsrechners gegen einen 4-Wege HP Alpha EV7 drin. :)

Zusammenfassung des Artikels bezogen auf die AMD-Maschine: sehr performant und ausbaufähig, dafür eingeschränkte Ausfallsicherheit und konzeptionell bedingte Leistungsschwächen durch die NUMA-Architektur. Die CPUs arbeiten nicht redundant, bei Ausfall von CPUs steht der gesamte Rechner. Selbst mit Linux 2.6 lässt sich wohl wegfallender Speicher nicht einfach wegkompensieren. ;) Zusätzlich wirkt NUMA an dieser Stelle kontraproduktiv, da der Speicher der nicht arbeitenden CPUs auch nicht angesprochen werden kann. Den Punkt sollte man bei einem Produktionsrechner schon berücksichtigen. Vier nicht redundant arbeitende CPUs bewirken auch eine niedrigere Verfügbarkeit.

Des weiteren arbeitete der Rechner mit zwei CPUs unter SPEC_CPU schneller als mit vier Prozessoren. Der Nachteil von NUMA: mit steigender Anzahl von Prozessoren nimmt auch der Traffic über Hypertransport immer weiter zu und die CPUs behindern sich je nach Software in ihrer Arbeit.

Das soll aber nicht darüber hinwegtäuschen, dass die Leistung natürlich ausgezeichnet ist. IMHO lohnt sich aber der Schritt von 2-Wege auf 4-Wege nicht wirklich, es sei denn, die Software ist explizit auf einen 4-Wege Opteron hin optimiert (Code/Daten-Lokalität für NUMA, sowie Parallelisierbarkeit der Aufgabe).

[Demirug]

Ein Quad Xeon skaliert wenn es um den Speicher geht ja auch nicht gerade glorreich.

Ausfallsicherheit ist sicherlich ein Punkt aber egal wie man es anstellt irgendwelche kritische Stellen hat man sowieso immer im System. Ich erinnere mich da gerne an das redundaten Netzteil bei dem dann die Backplane den Geit aufgeben hat.

Wenn die Verfügbarkeit wirklich das Kriterium ist braucht man sowieso ein vollständiges Backupsystem welches am besten noch in einem anderen Serverraum steht.

Ich gebe dir aber recht das ein Quad oder gar ein Achtfach System wirklich nur etwas ist wenn man auch Software hat die etwas damit anfangen kann. Selbst Dualsysteme sind als Applikationsserver ohne richtige Software schnell das falsche.

[GloomY]

Schöner Artikel =)

Jetzt habe ich endlich verstanden, was es mit diesen Aussagen auf sich hat, dass der L3 Cache des P4/Xeon nur teilweise inklusiv (http://www.aceshardware.com/read.jsp?id=60000276) sei. Prinzipiell ist er es bis auf ein paar Ausnahmen doch, das ist die eigentlich wichtige Aussage.

Es spricht natürlich auch für die C't, dass die Dual G5 Ergebnisse von Cinebench 2003 als Referenz herangezogen wurden :)

@Endorphine: Welche Systeme haben denn redundante CPUs?

[Endorphine]

Mit Linux 2.6 durch sysfs erst mal prinzipiell alle SMP-Systeme, bei denen der Speicher nicht von den CPUs selbst verwaltet wird. :) Der Kernel ermöglicht bereits CPU-hotplugging. Die Hardware hinkt hier den Möglichkeiten hinterher.

Generell natürlich auch andere SMP-OS. Bliebe nur zu klären, wie die auf Ausfall einzelner CPUs reagieren. Beim Opteron eine systemimmanente Schwäche der NUMA-Architektur. Speicher kann man schlecht redundant auslegen, ohne Daten/Code mehrmals pro CPU-Speicher abzulegen.

[GloomY]

Wenn es bei UMA möglich ist, die CPU während des Betriebs auszutauschen, dann sollte das prinzipiell bei NUMA auch kein Problem sein. Der einzige Unterschied hierbei ist eben noch, dass der Speicherbereich, der an dieser Node hängt, vom Betriebssystem gesperrt wird bzw. jeglicher Inhalt dort auf den Speicher anderer Nodes verteilt werden muss. Mittels virtueller Speicherverwaltung mit Paging/Segmentierung bekommen die Applikationen davon ja nichteinmal etwas mit. Diese benutzt imho nur virtuelle Adressen, wo das ganze dann aber nach der MMU im Speicher landet, sieht sie ja gar nicht.

Klar ist das ein größerer Aufwand, der auch erst noch implementiert werden müsste, aber unmöglich ist es sicher nicht.

[Endorphine]

Ausfälle geschehen normalerweise ungeplant, so dass man dort nichts geplant sperren kann. :)

Gut, ich hatte selbst etwas unglücklich zum hot plugging übergeleitet. Das hat aber nur indirekt etwas mit Ausfallsicherheit durch Redundanz zu tun.

Von der Hand weisen kann man diesen Nachteil des Opterons jedenfalls nicht. Deshalb hat die iX diesen Punkt ja auch angekreidet.

[GloomY]

Original geschrieben von Endorphine
Ausfälle geschehen normalerweise ungeplant, so dass man dort nichts geplant sperren kann. :)Ich meinte nur, dass man ins Betriebssystem eine Möglichkeit einbauen kann, mit einem bestimmten Befehl eine NUMA CPU samt Speicher zu sperren, die man dann auswechseln kann (statt bei einer UMA normalerweise nur die CPU allein zu sperren).

Der hot-plug Wechsel ist bei einer NUMA also nicht prinzipiell unmöglich, nur aufwändiger zu implementieren.
Original geschrieben von Endorphine
Gut, ich hatte selbst etwas unglücklich zum hot plugging übergeleitet. Das hat aber nur indirekt etwas mit Ausfallsicherheit durch Redundanz zu tun.Echte Redundanz wäre wenn man wirklich eine CPU zusätzlich einbaute, die bei Defekt automatisch dazugeschaltet würde. Imho gibt es sowas aber bei keiner momentanen Architektur. Daher auch meine obige Frage an dich. Wenn hier keine echte Redundanz möglich / verfügbar ist, dann ist natürlich hot-plug schon nützlich. Und das ist beim Opteron eben momentan (noch nicht) möglich.
Original geschrieben von Endorphine
Von der Hand weisen kann man diesen Nachteil des Opterons jedenfalls nicht. Deshalb hat die iX diesen Punkt ja auch angekreidet. *iX rauskram* ;)

Klar, der Wechsel kann momentan noch nicht im Betrieb gemacht werden. Das ist natürlich schon ein Nachteil, welcher aber prinzipiell in Zukunft auch nicht mehr gegeben sein muss.

edit: Rechtschreibung

[zeckensack]

Original geschrieben von Endorphine
Mit Linux 2.6 durch sysfs erst mal prinzipiell alle SMP-Systeme, bei denen der Speicher nicht von den CPUs selbst verwaltet wird. :) Der Kernel ermöglicht bereits CPU-hotplugging. Die Hardware hinkt hier den Möglichkeiten hinterher.

Generell natürlich auch andere SMP-OS. Bliebe nur zu klären, wie die auf Ausfall einzelner CPUs reagieren. Beim Opteron eine systemimmanente Schwäche der NUMA-Architektur. Speicher kann man schlecht redundant auslegen, ohne Daten/Code mehrmals pro CPU-Speicher abzulegen. Hotplugging ist ein planbarer Vorgang, Ausfall einer CPU eher nicht.

Die CPU kann ja mitten in einer (möglicherweise System-relevanten) Transaktion stecken, und wenn sie dann ausfällt, und weiterhin keine Möglichkeit gegeben ist, die Transaktion vollständig zu wiederholen, ist das Sys wohl oder übel im Eimer.

Auch über geplante Hotplugs muß man das System immer in irgendeiner Form informieren, sodaß die entsprechenden Komponenten 'heruntergefahren' werden können, um eben diesen Schaden durch verlorene Transaktionen zu verhindern.

Da unterscheidet sich der Opteron IMO nicht großartig von anderen Prozessoren. Aber ...
Original geschrieben von GloomY
Wenn es bei UMA möglich ist, die CPU während des Betriebs auszutauschen, dann sollte das prinzipiell bei NUMA auch kein Problem sein. Der einzige Unterschied hierbei ist eben noch, dass der Speicherbereich, der an dieser Node hängt, vom Betriebssystem gesperrt wird bzw. jeglicher Inhalt dort auf den Speicher anderer Nodes verteilt werden muss.Wenn der Prozessor richtiggehend ausfällt, dann geht das nicht. Du kannst auf den Speicher nicht mehr zugreifen, ergo kannst du ihn auch nicht woandershin retten.

Mir schwebt aber eine Lösung vor :naughty:
Man baue ein Ausfallsystem auf die Unterseite des PCBs, direkt unter den Prozessor-Sockel, und zwar einen Speichercontroller mit HT-Link(s). Natürlich nicht ganz so einfach, im Grunde müßte man die Teile des Opteron-Kerns, die mit Speicher und I/O in Verbindung stehen möglichst exakt duplizieren.

Dieses Ding sollte dann auf den HT-Links 'mithören', ob die Verbindung verloren gegangen ist, und sich dann im passenden Moment dazwischenhängen. Im laufenden Betrieb müßte der Chip allerdings mehr oder weniger komplett schlafen, um die Signale nicht negativ zu beeinträchtigen ...

[Demirug]

Dann komme ich doch mal mit meinem alten Fragenkatalog zum Thema verfügbarkeit. :D

1. Was ist mit Daten die zum Zeitpunkt des Ausfalls noch in der betroffenen Komponeten gespeichert sind? In unserem Fall also alles was in den Caches ist und noch nicht gespeichert wurde.

2. An welcher Stelle setzt die ersatz Komponete die unterbrochene Arbeit wieder auf? Soll heisen an welcher Stelle wird der unterbrochene Thread von der anderen CPU fortgesetzt?

3. Kann die betroffene Komponete ohne Deaktivierung des Gesamtsystems getauscht werden?

4. Sind redundant ausgelegte Komponeten durch weitere Komponeten verbunden die nicht redundant sind?

[GloomY]

Original geschrieben von zeckensack
Wenn der Prozessor richtiggehend ausfällt, dann geht das nicht. Du kannst auf den Speicher nicht mehr zugreifen, ergo kannst du ihn auch nicht woandershin retten.Das stimmt natürlich. :|
Zumal man ja auch nicht dazu kommt, den Prozessorzustand zu sichern, um den Thread dann später weiter auszuführen. Wenn die CPU weg kaputt ist, dann ist sie kaputt ;) Das gilt natürlich auch für UMAs.
Original geschrieben von zeckensack
Mir schwebt aber eine Lösung vor :naughty:
Man baue ein Ausfallsystem auf die Unterseite des PCBs, direkt unter den Prozessor-Sockel, und zwar einen Speichercontroller mit HT-Link(s). Natürlich nicht ganz so einfach, im Grunde müßte man die Teile des Opteron-Kerns, die mit Speicher und I/O in Verbindung stehen möglichst exakt duplizieren.

Dieses Ding sollte dann auf den HT-Links 'mithören', ob die Verbindung verloren gegangen ist, und sich dann im passenden Moment dazwischenhängen. Im laufenden Betrieb müßte der Chip allerdings mehr oder weniger komplett schlafen, um die Signale nicht negativ zu beeinträchtigen ... Imho zu teuer und/oder zu schwierig das technisch zu realisieren.
Original geschrieben von Demirug
Dann komme ich doch mal mit meinem alten Fragenkatalog zum Thema verfügbarkeit. :D

1. Was ist mit Daten die zum Zeitpunkt des Ausfalls noch in der betroffenen Komponeten gespeichert sind? In unserem Fall also alles was in den Caches ist und noch nicht gespeichert wurde.Die sind weg. Das gilt aber sowohl für NUMA als auch für UMA.
Original geschrieben von Demirug
2. An welcher Stelle setzt die ersatz Komponete die unterbrochene Arbeit wieder auf? Soll heisen an welcher Stelle wird der unterbrochene Thread von der anderen CPU fortgesetzt?Keine Ahnung, denn der Prozessor-State des defekten Prozessors konnte ja nicht gesichert werden...
Original geschrieben von Demirug
4. Sind redundant ausgelegte Komponeten durch weitere Komponeten verbunden die nicht redundant sind? Jep, der Chipsatz ist im Normalfall nur einfach ausgelegt. Wenn der oder andere Teile des Boards abrauchen, dann ist auch alle andere Redundanz unnütz. Der RAM ist auch nicht immer mit Chipkill o.ä. ausgestattet...

Eigentlich ergibt sich imho bei UMA nur der Vorteil der geplanten Auswechselung der CPU während des Betriebs, also z.B. wenn man den Prozessor upgraden will. Liegt ein richtiger Defekt vor, dann ist auch bei UMA nicht mehr viel zu retten.

[Plasmafusion]

Hmmm.

Warum gibt's eigentlich keine 4x CPU Mainboards mit 8x AGP & PCI (32-Bit) für normale Workstation User ?

Ein 4x Opteron System als Dual-XEON Konkurrenz wäre IMHO billiger als ein 4x XEON MP System und dennoch in Reichweite eines 2x XEON (DP) Käufers, welcher eben noch mehr Power als nur 2x XEONs haben will.

[Endorphine]

Weil 4-way SMP noch viel weniger Sinn macht als 2-way. Die allerwenigsten Aufgaben lassen so gut parallelisieren, dass sich das auch nur ansatzweise lohnt. Auf NUMA muss beim Opteron auch Rücksicht genommen werden. NUMA birgt durch die theoretisch lineare Speicherbandbreitenskalierung mit der Anzahl der CPUs grosses Potential, kann aber auch schnell zur Bremse werden, wenn die Software wenig Rücksicht auf NUMA nimmt und die CPUs ständig damit beschäftigt sind, auf den Speicher zuzugreifen, den eine andere CPU verwaltet.

Leistungsmaximierung heisst immer, zuerst aus den einzelnen CPUs das maximale herauszuholen, wenn das nicht mehr möglich ist, _dann_ sollte in Betracht gezogen werden, den teuren und wenig effizienten Weg von SMP zu gehen. Statt vier niedrig getakteten und teuren Opterons würde ich an deiner Stelle eher zu zwei Opteron 248 oder 246 greifen. Davon hast du mehr.

Gerade bei Workstations, die in der Regel nur wenig Parallelisierung auf Taskebene zulassen, die wirklich einen adäquaten Produktivitätsvorteil verspricht. Bei Servern kann sich der Task Scheduler dagegen auf SMP Systemen richtig austoben und praktisch vollständig unabhängige Serviceprozesse einzelnen CPUs zuweisen. Zudem zählt bei Servern eher der Durchsatz insgesamt, bei Workstations die Leistung einzelner Prozesse und einzelner Benutzer. Ziemlich gegenläufige Anforderungen eben.