Big Iron - wo geht die Reise hin?

Hat sich schon mal jemand dieses Paper angeschaut?

http://www.morganclaypool.com/doi/pdf/10.2200/S00193ED1V01Y200905CAC006
Seite 10:
1.6.4 Quantifying Latency, Bandwidth, and Capacity
Figure 1.3 attempts to quantify the latency, bandwidth, and capacity characteristics of a WSC. For illustration we assume a system with 2,000 servers, each with 8 GB of DRAM and four 1-TB disk drives. Each group of 40 servers is connected through a 1-Gbps link to a rack-level switch that has an additional eight 1-Gbps ports used for connecting the rack to the cluster-level switch (an Ooversubscription factor of 5). Network latency numbers assume a socket-based TCP-IP transport, and networking bandwidth values assume that each server behind an oversubscribed set of uplinks is using its fair share of the available cluster-level bandwidth. We assume the rack- and cluster-level switches themselves are not internally oversubscribed. For disks, we show typical commodity disk drive (SATA) latencies and transfer rates.
Das Paper lässt tief blicken.
 
Zuletzt bearbeitet:
Klingt sehr nach den Data Center Switches welche es von Cisco gibt.
Nexus 5000 mit Fabric Extender gibt es seht mehr als einem Jahr, allerdings mit 10Gbps Anschlüssen *buck*
Von daher ist dieses Paper *gähn* nix wirklich neues.

Wir haben sowas da bei uns im RZ im Einsatz.

Big Iron ist also schon länger in diese Richtung gegangen ....

lg
__tom
 
... Big Iron ist also schon länger in diese Richtung gegangen ...
Du nimmst mir die Worte aus dem Mund.

Zudem ziehen auch SSDs ein und sind sozusagen ein Level 4 Cache vor den vielen Festplatten.

Aber folgendes scheint mir für Dicke Eisen interessant- Tilera* ist da und scheint einige Unternehmen in den Bann gezogen zu haben. Deren Kachel-Architektur ist interessant genug für Samsung und Cisco: "Tilera raises $45 million from Samsung and Cisco".

Ältere Meldungen:
"ARM-Server-Startup sammelt 48 Millionen US-Dollar" (16.08.2010)

"Prozessorgeflüster, Von Okrakel und Oracle" c`t 16 2010 (Sommer 2010)

MFG Bobo(2010)


* = CPU-Glossar
 
Eben meine Rede.
Sie bauen die größte Suchmaschine der Welt, ohne irgendwo teure Komponenten rein zu klemmen.
Deren Hardware-Spezifikation klingt so langweilig, dass man darüber einschlafen könnte.
Aber der Aufbau und der Software-Stack, der darauf läuft, kitzelt das Maximum heraus.

Habt ihr euch schon die Latenzen angeschaut?
Eigener Hauptspeicher hat niedrige Latenzen.
Hauptspeicher eines Knotens im eigenen Rack ist schneller zu erreichen, als die eigene (lokale) Festplatte.....

@Bobo
Ältere Meldungen:
"ARM-Server-Startup sammelt 48 Millionen US-Dollar" (16.08.2010)
Das finde ich wiederum zum Gähnen. Im Urs Hölzle Abstract "Brawny cores still beat wimpy cores, most of the time" wird angedeutet, dass zu kleine Kerne keinen Sinn machen, weil die Kommunikation untereinander zu teuer ist.
Ich finde so etwas einen totalen Quatsch.
General-Purpose-Prozessoren haben ihren Einsatzbereich gefunden und GPGPU-Supercomputing beweist, dass es ein richtiger Ansatz ist.

Zwischen den beiden "Extremen" wird es ARM nicht schaffen.
Entweder wird der ARM-Cluster ausgestochen von einem Warehouse-Scale-Computer, wie ihn Urs Hölzle beschreibt, oder aber von einem GPGPU-Cluster, wie er z.B. durch den Tianhe-1A-Cluster realisiert wird.
Wo soll denn da die Luft zum Atmen bleiben? In welchem Aufgabenbereich soll so ein ARM-Cluster wirklich schneller sein - der Sinn dahinter ergibt sich mir nicht.
Oder dieser Ansatz:
http://www.anandtech.com/Show/Index...-with-512-atom-cpus-and-low-power-consumption
Wirklich lächerlich.
 
Bleibt alleine HP übrig, oder gibt es noch eine andere Firma die Itanium benutzt.
 
najaaa, x86 ist aber nun wirklich kein "big iron".

Was ich ebenso peinlich finde ist die Tatsache, dass alle außer IBM bei 2 GHz herumgurken und trotzdem auf dicke Hose machen....

Aber das mit dem Stromverbrauch erstaunt wirklich und lässt hoffen, dass die nächste Generation aufzuholen im Stande ist.
 
Mir fällt eigentlich nur noch ein Iron ein, welches größer ist als der Westmere-EX.
Der Power7 aber die anderen haben sich im Umfeld-Performance-Krone verabschiedet.

Wer heute was großes will kann auch zu Intel greifen.
Ein Acht-Sockel Westmere-EX hat mächtig Dampf.

8 Sockel, 10 Kerne, 2 Threads pro Kern = 160 Threads.
Speicherausbau - mächtig viel.
 
8 Sockel, 10 Kerne, 2 Threads pro Kern = 160 Threads.
Speicherausbau - mächtig viel.

Wenn den ein BS soviel mich machen würde. Selbst Linux hatte mit 80 Kernen Problem in der aktuellen ct zumindestens ;-)

Windows Server 2008 R2 hat bei >64 Kernen große Probleme.
 
die hatten 48 Kerne, ich meine auch gelesen zu haben das man ab 63 Kerne zu in Gruppierungen packen muss was wohl nicht so trivial ist.
 

Die RAS Features des Xeon kommen noch lang nicht an die des POWER heran. Alleine doublechecked Execution und Processor Hotswapping sind bei den x86 Kisten nicht möglich.

Und zu den 48 Kernen in einem OS: was ist daran so besonders? Wir haben seit Monaten 4P MagnyCourse Maschinen im Produktiveinsatz.
 
die hatten 48 Kerne, ich meine auch gelesen zu haben das man ab 63 Kerne zu in Gruppierungen packen muss was wohl nicht so trivial ist.

??? Die ct hat in der aktuellen den EX und 80 Kerne...
 
Der Smiliey ist da nur aus versehen reingekommen.
Das Paper befasst sich mit Open-Source. Sprich wenn man sich dahinterklemmt kann man Linux dahingehend aufbohren, dass es skaliert. Die habens jetzt bis 48 Kerne gemacht, bei mehr wirds schwieriger. IBM und Oracle mit ihren kommerziellen Produkten sind da schon drüber.
Ist ja klar, dass sich die OSe daran anpassen müssen, dass die Grenzen immer weiter nach oben gepushed werden.

Ein 8-Sockel-Xeon 160 Threads.
Ein 4-Sockel-G34-Bulldozer jetzt dann hoffentlich bald 64 Threads.
 
Der Smiliey ist da nur aus versehen reingekommen.
Das Paper befasst sich mit Open-Source. Sprich wenn man sich dahinterklemmt kann man Linux dahingehend aufbohren, dass es skaliert. Die habens jetzt bis 48 Kerne gemacht, bei mehr wirds schwieriger. IBM und Oracle mit ihren kommerziellen Produkten sind da schon drüber.
Ist ja klar, dass sich die OSe daran anpassen müssen, dass die Grenzen immer weiter nach oben gepushed werden.

Sorry, aber glaub bitte nicht immer dem Marketinggeblubber der großen Anbieter. Ja, Linux mag teilweise noch Probleme haben, die man mit etwas Tuning umgehen kann. Die 48 Core Maschinen bei uns laufen trotzdem auf RedHat EL und das ziemlich gut.

Dagegen haben wir mit Solaris teilweise massive Skalierungsprobleme, auch wenn Oracle behauptet Solaris würde extrem gut skalieren. Die wollen halt was verkaufen, kochen aber wie alle anderen auch nur mit Wasser.
 
die hatten 48 Kerne, ich meine auch gelesen zu haben das man ab 63 Kerne zu in Gruppierungen packen muss was wohl nicht so trivial ist.

Wer sind die?

Falls du die ct meintest, die hat in der 12/2011 mit 80 logische Prozessoren getestet. Die Gruppierung unter Windows und deren Problematik wurde dort auch erwähnt.Die Programme hatten entweder 60 oder 20 Kerne wie viele der Anwendung dann zur Verfügung standen war dann reiner Zufall.
 
Das "die" bezog sich auf das Paper was verlinkt war.Das System hatte 48 kerne.

Falls du die ct meintest, die hat in der 12/2011 mit 80 logische Prozessoren getestet. Die Gruppierung unter Windows und deren Problematik wurde dort auch erwähnt.Die Programme hatten entweder 60 oder 20 Kerne wie viele der Anwendung dann zur Verfügung standen war dann reiner Zufall.
Das hab ich (noch) nicht gelesen aber die Beschreibung das Kerne zufällig zugewiesen werden sagt doch das es nicht einfach ist.
 
Sorry, aber glaub bitte nicht immer dem Marketinggeblubber der großen Anbieter. Ja, Linux mag teilweise noch Probleme haben, die man mit etwas Tuning umgehen kann. Die 48 Core Maschinen bei uns laufen trotzdem auf RedHat EL und das ziemlich gut.

Dagegen haben wir mit Solaris teilweise massive Skalierungsprobleme, auch wenn Oracle behauptet Solaris würde extrem gut skalieren. Die wollen halt was verkaufen, kochen aber wie alle anderen auch nur mit Wasser.
Gut das so zu hören. Ich finde ja auch das Paper extrem spannend - es befasst sich ja nicht mit einer maximalen teoretischen Anzahl an CPUs, sondern mit der tatsächlichen Rohleistung in realen Anwendungen.
Es geht darum, wo das Filesystem hakt, wo globale Counter Flaschenhälse darstellen, wo die Netzwerkkarte ein Flaschenhals sein kann.
Und tatsächlich schaffen sie es Postgres auf einer 48-Kern-Maschine skalieren zu lassen - finde ich extrem spannend. Apache skaliert (auch wenn ich da lieber nginx gesehen hätte). Memcache skaliert.

Es geht ja nicht mehr wirklich darum, ein Programm 160 mal parallel zu starten und die Prozessoren aus zu lasten. Dafür kann man sich ja auch eine Farm aus Zwei-Sockel-Server bauen. Es geht darum eine konkrete Anwendung (Postgres, Mysql, MS SQL Server) auf ein Eisen drauf zu installiern und zu kucken wie gut mir diese Kiste unter Last antwortet. Memcache und Apache sind ja schon wieder Anwendungen, die sich über mehrere Kisten hinweg verteilen lassen.
 
Hi

hm mal ein Test unter verschiedenen Systemen wäre mal Interessant zb. Linux Win2008 R2 Solaris OVMS usw.
Aber ich glaube sie werden immer weiter diese Maschinen Virtualisieren und der Skalierung ab einem Punkt nicht weiter folgen da der Aufwand je nach Applikation sehr aufwendig wird.

lg
 
Zurück
Oben Unten