Server-Boards Cluster

Hallo Leute,

wir haben hier einen Linux-Cluster mit 20/21 Knoten basierend auf AMD 64
Venice-Kern für CFD-Berechnungen.

Nun reicht für manche Simulationen der Ram pro Maschine nicht mehr aus und
auch die starke Aufteilung der „Partitionen“ (CFD-Gitter verteilt pro Knoten)
belastet zusehr das Netzwerk.

Die Lösung mit neuen Mitteln in diesem Jahr lautet:

Beschaffung von 2-3 leistungsstarken Maschinen mit Multiprozessor.

Auf jeden Fall mit:

Pro CPU mindestens 4 GByte Ram.

Opteron Sockel 940

Budget: 12000 - 14000 Euro

Und nun weiss ich nicht weiter bzw. suche Entscheidungshilfe zu folgenden Fragen.

1: Dual-CPU-Board oder Quadro-CPU-Board.

2: Dual-Core oder Single-Core

Allein das ist schon eine 2x2-Matrix ob

1. Dual-Board - Single-Core 2 CPUs
2. Dual-Board - Dual-Core 4 CPUs
3. Quadro-Board - Single-Core 4 CPUs
4. Quadro-Board - Dual-Core 8 CPUs

Vermutlich die beste Lösung bzgl. Preis und Leistung wird Dual-CPU Dual-Core,
also Punkt 2 sein.

Dual-Core bringt zum Single-Core ungefähr 60 Prozent Geschwindigkeitszuwachs.

Frage:
Empfehlungen, Ratschläge zu Preis und Leistung?

Dann die Frage des Mainboards:
Kann man überhaupt darüber nachdenken, ob man zu Boards von MSI, Asus oder
Gigabyte greifen könnte oder sollte man sich ausschliesslich auf Server-Boards
spezialisierte Anbieter wie Tyan zurück greifen?

Mainboardempfehlung?

Wir wissen noch nicht, ob wir im Basterladen vor Ort kaufen oder bei einem
Anbieter für Cluster- und Serverlösungen.
Frage Empfehlungen?

Besten Dank vorab für alle Ratschläge und Diskussionen,

Peter

Hallo Legi

Die Lösung mit neuen Mitteln in diesem Jahr lautet:
Beschaffung von 2-3 leistungsstarken Maschinen mit
Multiprozessor.
Auf jeden Fall mit:
Pro CPU mindestens 4 GByte Ram.
Opteron Sockel 940
Budget: 12000 - 14000 Euro

Interessante Sachen, die Ihr da macht …
(Bin begeistert :wink:

Schon gelesen?
http://www2.tomshardware.de/cpu/20051107/index.html

bzw.:
http://www.asus.com/products4.aspx?modelmenu=2&model…
http://www.hardwarezone.com/articles/view.php?cid=25…

Supports up to 24GB memory (with 64-bit operating system)

Allerdings hab ich nicht explizit
gefunden, ob dat Dingens auch
dual core-Dual Opteron Unterstützt.
Aber da kann man ja sicher mal nachfragen :wink:

Grüße

CMБ

Hallo Semjon,

Interessante Sachen, die Ihr da macht …
(Bin begeistert :wink:

Naja, wollen wir tauschen? :wink:

Schon gelesen?
http://www2.tomshardware.de/cpu/20051107/index.html

Jetzt ja!

Interessant! Gute Argumente für Single-Core, gefällt mir. Wobei es sich relativiert bzw. 7.11.2005 und den neuen Preisen dato für die CPUs. Und mit dem Wissen, dass Dual-Cores für unsere Anwendungen nicht umsonst empfohlen werden.

Zum Beispiel:

http://www.linuxclustersinstitute.org/Linux-HPC-Revo…

"A Compuarison of Single-Core and Dual-Core Opteron Processor Performance for HPC"

Author(s) Douglas M. Pase and Matthew A. Eckl
Author Inst. IBM
Presenter Doug Pase

Abstract: 

Dual-core AMD Opteron™ processors represent the latest significant
 development in microprocessor technology. In this paper, using the
 IBM® eServer™ 326, we examine the performance of dual-core Opteron
 processors. We measure the core performance under ideal work loads 
using the Linpack HPL benchmark, and show it to be 60% faster than the
 fastest single-core Opteron. We measure unloaded memory latency and 
show that the dual-core processor’s slower clock frequency makes the
latency longer. However, we also show that its memory throughput
is 10% greater than single-core processors. Finally, we show that 
dual-core Opteron processors offer a significant performance advantage 
even on realistic applications, such as those represented by the SPEC®
CPU2000 benchmark suite. 

bzw.:
http://www.asus.com/products4.aspx?modelmenu=2&model…
http://www.hardwarezone.com/articles/view.php?cid=25…

Supports
up to 24GB memory (with 64-bit operating

Das finde ich schon komisch, 4 Dimms für CDP1 und 2 Dimms fuer CPU1

Naja,

besten dank schon einmal, peter

Moien

Nun reicht für manche Simulationen der Ram pro Maschine nicht
mehr aus und
auch die starke Aufteilung der „Partitionen“ (CFD-Gitter
verteilt pro Knoten)
belastet zusehr das Netzwerk.

Womit wir beim Thema wären: welches Netzwerk ist den vorhanden ? Und wie schnell müsste es sein um … 20 2.0GHz Opterons unter Dampf zu halten ?

Beschaffung von 2-3 leistungsstarken Maschinen mit
Multiprozessor.

Auf jeden Fall mit:

Pro CPU mindestens 4 GByte Ram.

Opteron Sockel 940

Budget: 12000 - 14000 Euro

Kennst du iwill ? Bei denen kann man 14000 Euro ganz locker auf einem Board verbraten (H8501, 8 940 Sockets, Dual-core fähig, 128 RAM oder H4204, 4 Sockets, Dual-core, 64GB RAM).

Dann wär nämlich euer Netzwerkproblem definitiv gelöst. Hypertransport zwischen den Sockets sollte schnell genug sein.

Vermutlich die beste Lösung bzgl. Preis und Leistung wird
Dual-CPU Dual-Core,

Ich tippe da eher auf single CPU mit Dual-Core. Der Speicher kostet dann nämlich weitaus weniger und die Boards sind als 0815-Ware verfügbar.

Kann man überhaupt darüber nachdenken, ob man zu Boards von
MSI, Asus oder
Gigabyte greifen könnte

Je nach dem ob ein Monster mehr bringt als 8 kleine … Wenn das Problem Netzwerk minimierbar ist wär ich für normale 0815-SingleCPU Boards.

cu

Moien

'n Abend,

Opteron Sockel 940

Budget: 12000 - 14000 Euro

Kennst du iwill ? Bei denen kann man 14000 Euro ganz locker
auf einem Board verbraten (H8501, 8 940 Sockets, Dual-core
fähig, 128 RAM oder H4204, 4 Sockets, Dual-core, 64GB RAM).

Hm.

Dann wär nämlich euer Netzwerkproblem definitiv gelöst.
Hypertransport zwischen den Sockets sollte schnell genug sein.

Uhm… also, wenn es wirlich diese Topologie umsetzt will man das nicht: http://www.iwill.net/product_imgs/90/H8501_Diagram_L…
Opteron und grosse SMPs… sind fuer HPC wirklich nicht so schoen.

Gruss vom Frank.

1 Like

Moien

Dann wär nämlich euer Netzwerkproblem definitiv gelöst.
Hypertransport zwischen den Sockets sollte schnell genug sein.

Uhm… also, wenn es wirlich diese Topologie umsetzt will man
das nicht:

Wieso nicht ? OK, der Netzwerkersatz ist für manche Anwendungen ungünstig verschaltet. Aber du tauschst hier ein normales Netzwerk (10GEth oder Inifiband,… also etwa 1GB/s) gegen Hypertransport-Kanäle (15-20GB/s) aus. Und beim HPC kann man durchaus was mit der Struktur anfangen, ist ja ein Spezialfall von FNN. Und RDMA bekommt man gratis dazu.

Den RAM benutzen die ja lokal, d.h. die Bandbreite des Hypertransport ist bei CPU-intensiven Sachen frei. OK, wenn das Vieh viel IO mit PCIe-Karten machen soll oder die Prozesse nicht vorhersagbar viel untereinander kommunizieren hast du verloren.

cu

1 Like

Vorab: an Fakten hab ich nur Benchmarks. Der Rest sind ein grobe Ueberlegungen, wie das System gebaut ist und vage Interpretation der Benchmark-Ergebnisse. (Okay, ich hab noch ein paar Papers von Tyan, die ein aehnliches System, aber mit geringfuegig besserer Topologie haben. Nein, in denen kommt das 8-Wege-System auch nicht besonders gut weg.)

Ich hatte bis jetzt zwei verschiede 8-Wege-System unter den Fingern: das erste war von Iwill und zugegebenermassen eine fruehe Beta-Version, das zweite war von Tyan. Ersteres war indiskutabel und vermutlich kaputt, mein Laptop hat mehr Speicherbandbreite. Das Tyan ist schon besser, aber bei meinen Tests skalierten 8xDC in dem Ding genauso gut wie Dual Dual Core vernetzt mit Infiniband. Und mit IB kann ich viel groesser und billiger bauen.

Uhm… also, wenn es wirlich diese Topologie umsetzt will man
das nicht:

Wieso nicht ? OK, der Netzwerkersatz ist für manche
Anwendungen ungünstig verschaltet.

Eben.

Aber du tauschst hier ein normales Netzwerk (10GEth oder
Inifiband,… also etwa 1GB/s) gegen Hypertransport-Kanäle
(15-20GB/s) aus.

Bandbreite ist nicht alles: die CPUs sind unterschiedlich „weit“ auseinander. Der Linux-Kernel hat keine Ahnung ueber die Topologie der CPUs, er sieht also auch keine Notwendigkeit, threads eines Prozesses (die potentiell viel kommunizieren werden) an „nahe“ CPUs zu binden. Parallele Rechnungen sehen meist so aus, dass threads oder Prozesse Daten austauschen, ein Stueck rechnen und sich dann synchronisieren. Synchronisieren wollen erstmal alle auf einmal (-> HT dicht) und ausserdem warten alle auf den langsamsten, das wird der, der am weitesten weg ist. Wenn gleichzeitig noch andere Prozesse den HT zublasen…

Und beim HPC kann man durchaus was mit der Struktur anfangen,
ist ja ein Spezialfall von FNN.

Nein, eben nicht: die Latenz zwischen den nodes ist nicht gleich.

Und RDMA bekommt man gratis dazu.

Cache Kohaerenz leider nicht. Die kostet gleich wieder Zeit.

Den RAM benutzen die ja lokal, d.h. die Bandbreite des
Hypertransport ist bei CPU-intensiven Sachen frei.

Viele Prozesse, die nicht kommunizieren, mag man dem Ding gut zumuten koennen. Ein Gameserver oder so…

OK, wenn das Vieh viel IO mit PCIe-Karten machen soll

Das wird das naechste Problem: irgendwann will bestimmt mal einer, dass ich ein IB-HCA in so ein Ding stecke und wundert sich dann, dass er pro Core weniger Anbindung als GigE hat. Da wird auch DDR-IB nur ein Tropfen auf den heissen Stein.

oder die Prozesse nicht vorhersagbar viel untereinander
kommunizieren hast du verloren.

Hm, da muss ich jetzt mal dumm fragen: welche Prozesse im HPC-Bereich kommunizieren denn vorhersehbar? Abgesehen von den selbstgeschriebenen Applikationen irgendwelcher Wissenschaftler.

Gruss vom Frank.

1 Like

Moien

Vorab: an Fakten hab ich nur Benchmarks.

Glückwunsch, ich kenn sie von der Theorieseite her. Wenn jetzt der Fragesteller als ein Man der Praxis noch seinen Senf abgibt haben wir alle 3 zusammen.

Ich hatte bis jetzt zwei verschiede 8-Wege-System unter den
Fingern: das erste war von Iwill und zugegebenermassen eine
fruehe Beta-Version, das zweite war von Tyan.

Ich hab k.A. auf welchen Boards die 4x und 8x Server der Uni liefen. Damals gabs allerdings auch noch keine Opterons und es ging um Sparc, Power & Co.

Ersteres war
indiskutabel und vermutlich kaputt, mein Laptop hat mehr
Speicherbandbreite.

Das passiert Iwill öfter wenn die Deadlines für Boards näher rücken. Man sollte bei denen auch die Empfehlungen was den RAM angeht strikt einhalten.

Das Tyan ist schon besser, aber bei
meinen Tests skalierten 8xDC in dem Ding genauso gut wie Dual
Dual Core vernetzt mit Infiniband. Und mit IB kann ich viel
groesser und billiger bauen.

Es hängt eben von der Anwendung ab. Wenn du ein für normale, vernetzte Cluster geschriebenes Prog auf eine 8x klatschs wird da nix grünes bei rauskommen. Das war mir schon klar.

Aber du tauschst hier ein normales Netzwerk (10GEth oder
Inifiband,… also etwa 1GB/s) gegen Hypertransport-Kanäle
(15-20GB/s) aus.

Bandbreite ist nicht alles: die CPUs sind unterschiedlich
„weit“ auseinander. Der Linux-Kernel hat keine Ahnung ueber
die Topologie der CPUs, er sieht also auch keine
Notwendigkeit, threads eines Prozesses (die potentiell viel
kommunizieren werden) an „nahe“ CPUs zu binden.

Einfachso laufen lassen ist auch auch nicht im Sinne von HPC. Da muss man optimieren und Prozesse an bestimmte CPUs binden ( http://linuxcommand.org/man_pages/taskset1.html ). Und Linux haut den ProzessRAM dann auch gleich auf die richtige RAM-Bank (Wenn man das tastset schnell genug durchbekommt: http://www.cs.utk.edu/~vose/linux/NUMA.html . Wenn nicht ist Essig.)

Parallele
Rechnungen sehen meist so aus, dass threads oder Prozesse
Daten austauschen, ein Stueck rechnen und sich dann
synchronisieren. Synchronisieren wollen erstmal alle auf
einmal (-> HT dicht) und ausserdem warten alle auf den
langsamsten, das wird der, der am weitesten weg ist.

Ja, aber bei CFD (darum gings ja mal am Anfang) brauchen ja nicht alle Prozesse alle Daten. Da simulieren Prozesse jeweils einen Teilabschnitt eines Raums (1D, 2D oder 3D). Dafür brauchen sie beim synchronisieren nur die Daten der Räume rundum, sozusagen die „Trennwände“ zu ihrem Raum. D.h. die CPU links unten braucht im Optimalfall nur die Daten der CPU rechts von ihr und der von links oben. (Nach meinem Wissensstand kommunizieren immer 2 nebeneinander liegende CPUs direkt miteinander. D.h. die CPU agiert als eine Art 3-Port Switch in dem HT-Geflecht. Und eben nicht als 3 Port Hub… Wenn das nicht stimm ziehe ich alles zurück).

Allerdings machen die diesen Datentausch oft und die Daten sind nicht gerade klein (er sprach von 4GB grossen Räumen, das ist schon ein Stück Trennwand…). Deshalb halte ich HT (kleine Latenz, hohe Bandbreite) hier in diesem Fall für besser. Bis er halt mehr als 16 OpteronCores braucht …

OK, wenn die nun ein komerzielles Produkt einsetzen bei dem nicht ersichtlich ist welcher Prozess mit welchem kommuniziert wird es komplex. Dann wird tatsächlich irgendwann CPU links unten mit CPU rechts oben reden wollen. Das wird die Performance schwer in den Keller absacken lassen.

Und beim HPC kann man durchaus was mit der Struktur anfangen,
ist ja ein Spezialfall von FNN.

Nein, eben nicht: die Latenz zwischen den nodes ist nicht
gleich.

Wieso wurden dann solche Sauereien wie Torusnetzwerke entwickelt ?

Das Zeug hat alles einen Sinn. Es ist weit, weit von normalen Computeralltag entfernt, es wird mit Standardsoftware schnell in die Knie gehen, aber es macht trotzdem für bestimmte Fälle Sinn.

Und RDMA bekommt man gratis dazu.

Cache Kohaerenz leider nicht. Die kostet gleich wieder Zeit.

Stimmt. Bei CFD sind die Datensätze aber meistens einigermassen disjunkt, da hat man Glück gehabt.

Den RAM benutzen die ja lokal, d.h. die Bandbreite des
Hypertransport ist bei CPU-intensiven Sachen frei.

Viele Prozesse, die nicht kommunizieren, mag man dem Ding gut
zumuten koennen. Ein Gameserver oder so…

Bring mich nicht auf dumme Gedanken… es steht hier eine LAN an.

OK, wenn das Vieh viel IO mit PCIe-Karten machen soll

Das wird das naechste Problem: irgendwann will bestimmt mal
einer, dass ich ein IB-HCA in so ein Ding stecke und wundert
sich dann, dass er pro Core weniger Anbindung als GigE hat.

Jau.

Da wird auch DDR-IB nur ein Tropfen auf den heissen Stein.

Du hast Opterons, du kannst im Notfall auf InfiniPath umsteigen. OK, damit opfert man einen Sockel und die Daten müssen evtl. immernoch den ganzen Weg über 4 Sockel transportiert werden… aber wenigstens fällt der ganze PCI-XYZ Teil weg.

Hm, da muss ich jetzt mal dumm fragen: welche Prozesse im
HPC-Bereich kommunizieren denn vorhersehbar? Abgesehen von
den selbstgeschriebenen Applikationen irgendwelcher
Wissenschaftler.

Laut seiner Vika ist er Wissenschaftler.

Wir sollten mal HPC klarstellen:

Dir geht’s um Serverfarmen wo Standardsotware aus Performancegründen verteilt läuft. Ich denke mal SQL-DB, Webserver und der gleichen mehr. OK, da wird ein 8x (oder 8x 2x = 16 cores) Opteron abstinken, dafür reicht die Anbindung nach aussen einfach nicht aus. 2 bis maximal 4 Kerne pro System und ordentliches, jeder-spricht-mit-jedem Netzwerk dazwischen.

Ich sehe das ganze mehr als Cluster für selbstgeklöppelte oder bei anderen abgekupferte Simulationen realer Vorgänge oder mathematischer Probleme. Da hat man viele Systeme wo intensiver Austausch nur ziwschen wenigen „lokalen“ Knoten stattfindet. Anders als bei dem COMMIT in einer DB interessieren da manche Daten manche Knoten einfach gar nicht.

So, nun warten wir mal auf eine Antwort des Ursprungsposter. Evtl. ist es ja duch Standardsoftware und ich kann mir meinen schönen iwill in die Haare schmieren…

cu

1 Like

Guten Morgen Pumpkin!

Pumpkin
„Womit wir beim Thema wären: welches Netzwerk ist den vorhanden ?“

Gigabit PCI-Karten und 24-Port-Gigabit-Switch.
Pumpkin

„Kennst du iwill?“ [Board]

Jetzt ja, aber das Board kommt nicht in Frage, das ist jetzt schon abzusehen. Danke schön!

Pumkin:
„Ich tippe da eher auf single CPU mit Dual-Core“

Vielleicht. Geraten wird von jedoch vielen Seiten, wie ich auch unten an Semjon schrieb, auch von unserem CFD-Anbieter CFX, zu Dualcores zu greifen. Bis wir wenn überhaupt kaufen, vergeht noch mindestens 16 Wochen und dann sind die Preise vs. Leistung noch günstiger.

„Wenn das Problem Netzwerk minimierbar ist wär ich für normale 0815-SingleCPU Boards.“

Leider nicht! Jedenfalls nicht bei CFX. Das ist ein gekoppelter Solver und er macht uns eine Menge Probleme.

P.:

„OK, wenn das Vieh viel IO mit PCIe-Karten machen soll“

PCI-Express? Ich kann grad nicht folgen. Meinst Du Ethernet über PCI-NICs?

Frank:
„Das wird das naechste Problem: irgendwann will bestimmt mal einer, dass ich ein IB-HCA in so ein Ding stecke und wundert sich dann, dass er pro Core weniger Anbindung als GigE hat. Da wird auch DDR-IB nur ein Tropfen auf den heissen Stein.“

Was ist IB-HCA und DDR-IB?

Frank:
„Hm, da muss ich jetzt mal dumm fragen: welche Prozesse im HPC-Bereich kommunizieren denn vorhersehbar? Abgesehen von den selbstgeschriebenen Applikationen irgendwelcher Wissenschaftler.“ s.A.i.W.

Pumkin:
„Laut seiner Vika ist er Wissenschaftler.“

Eben, es ist leider nicht selbst geschrieben, sondern frisst jährlich unser ganzes Budget. Wenn ich allein zuständig wäre bzw. meine Arbeit hier nur für CFD-Sim., statt auch für Reaktorexperimente, Sys-Admin nicht nur Cluster, sondern auch in allen Fragen der Redmond-Kollegen (schmerz!), würde ich gerne mit und an freier Software (s.A.i.W.) schreiben. Aber naja …

Glückwunsch, ich kenn sie von der Theorieseite her. Wenn jetzt
der Fragesteller als ein Man der Praxis noch seinen Senf
abgibt haben wir alle 3 zusammen.

I try :smile:

Ersteres war
indiskutabel und vermutlich kaputt, mein Laptop hat mehr
Speicherbandbreite.

Das passiert Iwill öfter wenn die Deadlines für Boards näher
rücken. Man sollte bei denen auch die Empfehlungen was den RAM
angeht strikt einhalten.

F:

Das Tyan ist schon besser, aber bei
meinen Tests skalierten 8xDC in dem Ding genauso gut wie Dual
Dual Core vernetzt mit Infiniband. Und mit IB kann ich viel
groesser und billiger bauen.

Und wie sieht es aus mit 4xDC? Ist dann die Topologie immer noch vollvernetzt?

Es hängt eben von der Anwendung ab. Wenn du ein für normale,
vernetzte Cluster geschriebenes Prog auf eine 8x klatschs wird
da nix grünes bei rauskommen. Das war mir schon klar.

Vielen Dank für die Argumente, auch tiefer. Werde ich gar nicht erst versuchen.

Bandbreite ist nicht alles: die CPUs sind unterschiedlich
„weit“ auseinander. Der Linux-Kernel hat keine Ahnung ueber
die Topologie der CPUs, er sieht also auch keine
Notwendigkeit, threads eines Prozesses (die potentiell viel
kommunizieren werden) an „nahe“ CPUs zu binden.

Einfachso laufen lassen ist auch auch nicht im Sinne von HPC.
Da muss man optimieren und Prozesse an bestimmte CPUs binden (
http://linuxcommand.org/man_pages/taskset1.html ). Und Linux
haut den ProzessRAM dann auch gleich auf die richtige RAM-Bank
(Wenn man das tastset schnell genug durchbekommt:
http://www.cs.utk.edu/~vose/linux/NUMA.html . Wenn nicht ist
Essig.)

Das merke ich mir!

Parallele
Rechnungen sehen meist so aus, dass threads oder Prozesse
Daten austauschen, ein Stueck rechnen und sich dann
synchronisieren. Synchronisieren wollen erstmal alle auf
einmal (-> HT dicht) und ausserdem warten alle auf den
langsamsten, das wird der, der am weitesten weg ist.

Ja, aber bei CFD (darum gings ja mal am Anfang) brauchen ja
nicht alle Prozesse alle Daten. Da simulieren Prozesse jeweils
einen Teilabschnitt eines Raums (1D, 2D oder 3D). Dafür
brauchen sie beim synchronisieren nur die Daten der Räume
rundum, sozusagen die „Trennwände“ zu ihrem Raum. D.h. die CPU
links unten braucht im Optimalfall nur die Daten der CPU
rechts von ihr und der von links oben. (Nach meinem
Wissensstand kommunizieren immer 2 nebeneinander liegende CPUs
direkt miteinander. D.h. die CPU agiert als eine Art 3-Port
Switch in dem HT-Geflecht. Und eben nicht als 3 Port Hub…
Wenn das nicht stimm ziehe ich alles zurück).

Allerdings machen die diesen Datentausch oft und die Daten
sind nicht gerade klein (er sprach von 4GB grossen Räumen, das
ist schon ein Stück Trennwand…). Deshalb halte ich HT
(kleine Latenz, hohe Bandbreite) hier in diesem Fall für
besser. Bis er halt mehr als 16 OpteronCores braucht …

Bisher brauchen die grossen CFD-Simulationen von Ansys-CFX mit 900 000 Zellen und Verbrennungsprozessen 8 Knoten a 2 GByte Ram AMD-Venice mit Gigabit-Ethernet. Also brauchen wir mindestens 16 GByte Ram, schöner natürlich Faktor 2. Traffic ist das zweite Problem. Mit 4 CPUs Opteron wie auch immer realisiert mit SC oder DC hätten wir Trafficprobleme Giga-Eth. und Ram bereits erschlagen auf einem Board.

1*4DC und 32 Giga wäre bereits Wahnsinn, ein Traum.

2*4SC 16 Giga

oder

2*2DC 16 Giga

aber wären halt zwei Maschinen, die vielleicht zusammen kostengünstiger sind pro Geld und Simulationsleistung.

OK, wenn die nun ein komerzielles Produkt einsetzen bei dem
nicht ersichtlich ist welcher Prozess mit welchem kommuniziert
wird es komplex. Dann wird tatsächlich irgendwann CPU links
unten mit CPU rechts oben reden wollen. Das wird die
Performance schwer in den Keller absacken lassen.

yup

Das Zeug hat alles einen Sinn. Es ist weit, weit von normalen
Computeralltag entfernt, es wird mit Standardsoftware schnell
in die Knie gehen, aber es macht trotzdem für bestimmte Fälle
Sinn.

Und RDMA bekommt man gratis dazu.

Cache Kohaerenz leider nicht. Die kostet gleich wieder Zeit.

Stimmt. Bei CFD sind die Datensätze aber meistens
einigermassen disjunkt, da hat man Glück gehabt.

ok

Du hast Opterons, du kannst im Notfall auf InfiniPath
umsteigen. OK, damit opfert man einen Sockel und die Daten
müssen evtl. immernoch den ganzen Weg über 4 Sockel
transportiert werden… aber wenigstens fällt der ganze
PCI-XYZ Teil weg.

Kannst Du das bitte etwas erläutern?

Wir sollten mal HPC klarstellen:

Dir geht’s um Serverfarmen wo Standardsotware aus
Performancegründen verteilt läuft. Ich denke mal SQL-DB,
Webserver und der gleichen mehr. OK, da wird ein 8x (oder 8x
2x = 16 cores) Opteron abstinken, dafür reicht die Anbindung
nach aussen einfach nicht aus. 2 bis maximal 4 Kerne pro
System und ordentliches, jeder-spricht-mit-jedem Netzwerk
dazwischen.

ok

So, nun warten wir mal auf eine Antwort des Ursprungsposter.
Evtl. ist es ja duch Standardsoftware und ich kann mir meinen
schönen iwill in die Haare schmieren…

Ich fürchte ja … :smile:

Viele Grüsse und besten Dank!

Peter

Moien,

„Womit wir beim Thema wären: welches Netzwerk ist den
vorhanden ?“

Gigabit PCI-Karten und 24-Port-Gigabit-Switch.

OK, das ist doch ein Anfang. Aber da ist doch noch viel Luft für Verbesserung.

Euch läuft das Netzwerk voll wenn ihr die Grösse der Packete verkleinert ? Dann wäre ein neues Netzwerk (10 GigabitEthernet) evtl. keine schlechte Idee. Alternativ könnte man natürlich den RAM der Nodes vergrössern (was wahrscheinlich billiger auch kommen würde).

Ich tippe da eher auf single CPU mit Dual-Core

Vielleicht. Geraten wird von jedoch vielen Seiten, wie ich
auch unten an Semjon schrieb, auch von unserem CFD-Anbieter
CFX, zu Dualcores zu greifen. Bis wir wenn überhaupt kaufen,
vergeht noch mindestens 16 Wochen und dann sind die Preise vs.
Leistung noch günstiger.

Der Nachteil vom Einsatz vieler Nodes mit weniger CPUs ist halt dass man ein sehr gutes, schnelles Netzwerk mit einem richtig grossen Switch braucht. Die richtig schnellen Netze werden aber verdammt teuer wenn sie viele Nodes verkraften müssen.

Das gleiche Spiel rückwärts hat man bei Kauf von grossen Rechnern mit vielen CPUs: Das Netzwerk ist plötzlich weniger gross und dementsprechend billiger. Allerdings auch, pro Core gesehen, langsamer.

Nun gibt es verteile Programme denen das Netzwerk wichtiger ist oder eben unwichtiger. Da sollte man dann wissen wieviel Netzwerk-Power pro CPU-Power zur Verfügung stehen muss. (Stichworte: Net/IO-bound oder CPU-bound)

Manchmal kann man „einstellen“ wie wichtig das Netz sein soll, in dem man die Problemaufteilung hin zu grossen oder kleineren Teilproblemen macht. Allerdings können das bei weitem nicht alle Standardsoftwares. Und einige erlauben Einstellungen weit jenseits von Gut und Böse (Deins kenn ich nicht)

„Wenn das Problem Netzwerk minimierbar ist wär ich für normale
0815-SingleCPU Boards.“

Leider nicht! Jedenfalls nicht bei CFX. Das ist ein
gekoppelter Solver und er macht uns eine Menge Probleme.

Wären die Probleme bei 10 Gigabit Ethernet immernoch so schlimm ?

„OK, wenn das Vieh viel IO mit PCIe-Karten machen soll“

PCI-Express? Ich kann grad nicht folgen. Meinst Du Ethernet
über PCI-NICs?

Ethernet ist inzwischen schneller als normales PCI. Wenn man nachträglich 10 GigabitEthernet einbauen will muss man auf PCIe oder PCI-X Karten gehen.

Ein 8x-DualCore-Opteron Monster ist ziemlich begrenzt was die Netzwerkgeschwindigkeit pro Core angeht. Nicht weil sich da keine schnellen Netzwerkkarten für finden, sondern weil da so viele Cores drin sind.

„Das wird das naechste Problem: irgendwann will bestimmt mal
einer, dass ich ein IB-HCA in so ein Ding stecke und wundert
sich dann, dass er pro Core weniger Anbindung als GigE hat. Da
wird auch DDR-IB nur ein Tropfen auf den heissen Stein.“

Was ist IB-HCA und DDR-IB?

Das sind beides InfiniBand-Varianten. InfiniBand ist ein richtig schnelles, für Cluster entwickeltes Netzwerk. Die Bandbreiten fangen bei 2.5 Gigabit/s an und die grösste Ausbaustufte (12x QDR) erreich 120 Gigabit/s. (Im Vergleich zu den 1 Gigabit/s von deinem aktuellen Netzwerk … gell ?). Aber frag lieber nicht nach dem Preis. Und normale Software kommt nicht sonderlich gut mit dem System klar. Es basiert auf einem anderen Netzwerkprotokol und kann ohne Zusatztreiber nix mit TCP/IP anfangen.

Das Tyan ist schon besser, aber bei
meinen Tests skalierten 8xDC in dem Ding genauso gut wie Dual
Dual Core vernetzt mit Infiniband. Und mit IB kann ich viel
groesser und billiger bauen.

Und wie sieht es aus mit 4xDC? Ist dann die Topologie immer
noch vollvernetzt?

(Du meinst die Kommuniation ziwschen den CPU’s, ja ?) Nein, so gerade nicht. Opterons haben 3 Verbindungen nach aussen. Bei 4 Opterons erhält man 12/2 = 6 Verbindungen. Und eine davon muss zum Chipset gehen. Also fehlt genau eine.

Aber das ist HT. Da macht ein Umweg über eine andere CPU nicht so viel aus.

Einfachso laufen lassen ist auch auch nicht im Sinne von HPC.
Da muss man optimieren und Prozesse an bestimmte CPUs binden (
http://linuxcommand.org/man_pages/taskset1.html ). Und Linux
haut den ProzessRAM dann auch gleich auf die richtige RAM-Bank
(Wenn man das tastset schnell genug durchbekommt:
http://www.cs.utk.edu/~vose/linux/NUMA.html . Wenn nicht ist
Essig.)

Das merke ich mir!

Auf Rechnern die nur einen Speichercontroller haben (also alles was nur einen Sockel hat und alle Intelsysteme) bringt das exakt gar nichts. Der „faule“ Scheduler aus Linux macht da einen besseren Job.

Allerdings machen die diesen Datentausch oft und die Daten
sind nicht gerade klein (er sprach von 4GB grossen Räumen, das
ist schon ein Stück Trennwand…). Deshalb halte ich HT
(kleine Latenz, hohe Bandbreite) hier in diesem Fall für
besser. Bis er halt mehr als 16 OpteronCores braucht …

Bisher brauchen die grossen CFD-Simulationen von Ansys-CFX mit
900 000 Zellen und Verbrennungsprozessen 8 Knoten a 2 GByte
Ram AMD-Venice mit Gigabit-Ethernet. Also brauchen wir
mindestens 16 GByte Ram, schöner natürlich Faktor 2. Traffic
ist das zweite Problem.

Wenn ihr nur ein Monster mit 8 CPUs und 16 GB RAM hättet braucht ihr kein Netzwerk mehr. D.h. das Netzwerk kann euch auch nicht in die Quere kommen. Das was vorher übers Netzwerk lief geht in dem Fall als HT-Transfer über die Bühne. HT schafft etwa das 100x von GigabitEthernet.

Allerdings geht das tierisch in die Hose wenn ein 2. Monster angeschafft wird. Man kann nämlich kein Netzwerk zwischen 2 solchen Rechnern aufbauen das es schafft die Ergebnisse von 8 CPUs schnell genug zu transferieren.

Also wenn Monster, dann in dem Fall Standalone.

Und Monster-rechner laufen nicht mehr „einfachso“. Da muss man nachbessern, testen und dem Hersteller auf die Finger klopfen. Das sind keine „stell es hin und es wird gehen“ Systeme. Sowas braucht Monate Feintuning. Und wenn in dem Teil was richtig ausfällt (RAM) steht der Betrieb völlig.

aber wären halt zwei Maschinen, die vielleicht zusammen
kostengünstiger sind pro Geld und Simulationsleistung.

Rechen das Netzwerk mit rein. Das muss ja ausreichen um alle CPUs miteinander zu verbinden. Bei 4 OpteronCores reicht dann GEthernet nicht mehr und Karten im Bereich http://www.chelsio.com/products/T210.php sind verdammt teuer (± 1000 Eng. Pfund) UND brauchen Serverboards die etwas mehr als nur PCI können.

Du hast Opterons, du kannst im Notfall auf InfiniPath
umsteigen. OK, damit opfert man einen Sockel und die Daten
müssen evtl. immernoch den ganzen Weg über 4 Sockel
transportiert werden… aber wenigstens fällt der ganze
PCI-XYZ Teil weg.

Kannst Du das bitte etwas erläutern?

InfiniPath ist ± InfiniBand, nur mit kleinerer Latenz. InfiniBand wird an den PCIe / PCI-X Bus angeschlossen. Die Daten brauchen aber Zeit um von den CPUs über den Chipset zum PCI-Irgendwas und dann noch in die Netzwerkkarten zu kommen.

Nun ist der Sockel der Opteron mit 3 HT-Links ausgestattet. Und die funktionieren wie ein sehr schnelles, primitives Netzwerk (das momentan leider nicht länger als ein paar Handbreit werden kann). InfiniPath nutzt HT aus und arbeitet mit Netzwerkkarten die in Opteron-Sockets gesteckt werden. Das spart den Umweg über Chipset und PCI. Deshalb kommen Packete schneller durch.

Die Bandbreite bleibt aber gleich. D.h. es kommen nicht mehr Daten pro Sekunde an. Nur die Ping-Zeiten gehen deutlich runter.

Mit einem Wort: TEUER. Aber schööönnnn…

cu

1 Like