Big Iron - wo geht die Reise hin?

[mocad_tom]

Immer größere ccNUMA-Systeme?

Oder kann eine Art inverse Virtual Machine aus mehreren lose gekoppelten Systemen(Stichwort Cluster) wieder ein System schnüren, welches sich wie ein ccNUMA-System verhält?

http://www.theregister.com/2005/11/17/rackable_smp_sc/
Instead of using a single motherboard, the C5100 links four two-way systems. What makes it special is software from start-up ScaleMP. The software allows customers to run a single operating system across all of the servers with shared memory. Think VMware in reverse.

http://h20325.www2.hp.com/blogs/wu/archive/2005/09/13/277.html
Once an enterprise has many LINUX-power servers inside its data center, the next easy task is about scaling out. Scaling out in many ways is about building a server farm and breaking a traditional task down so that many independent slice of a task can be run in parallel on many different cheap commodity servers at the same time. This is great for tasks like compilation, CAD simulation etc, but not so great for high end application that requires interlocking state management, memory sharing, or thread dependency.

Scaling up takes it a step higher: build a n-way SMP machines out of cheap commodity Linux box. There are quite a few companies out there and I think it is a very cool space because of the large high end computer dependency in several vertical industries such as financial services, insurance and telecommunication.

Bei der Hyper-Transport-to-Infiniband-Bridge wird als MPI-Latenz 1.29 Mikrosekunden.

Bei einer Direct-Connect-Architektur werden folgende Latenzen angegeben:
http://www.digit-life.com/articles2/amd-hammer-family/

Uni-processor system: around 45 ns
Dual-processor system: 0-hop - 69 ns, 1-hop - 117 ns.
Four-processor system: 0-hop - 100 ns, 1-hop - 118 ns, 2-hop - 136 ns.

Zusätzlich kommt hinzu, das durch ScaleMP zusätzlicher Traffic erzeugt wird(alles was im Protokoll direkt in die Hardware gepackt ist muss nicht durch Software-Layer gepackt, verarbeitet oder umgepackt werden).
Auf der anderen Seite muss man auch sagen, das durch diese Software das Hardware-Layout deutlich handlicher wird - kostengünstigere Lösungen werden greifbar.

AMD rüstet hoch, kündigt glueless 32 Sockel-Systeme an.
4 Kern-CPUs zeichnen sich schon am Horizont ab, 8 Kern CPUs liegen durchaus im Rahmen des möglichen.
Mit Horus lassen sich mehrere Direct-Connect-Packete zusammenschalten.
Da aber an Horus auch einige HTr-Links angeschlossen werden können 32-Sockel dann schon nicht mehr realisiert werden.

Da ich grundsätzlich Optimist bin rechne ich jetzt mal mit den maximal denkbaren Werten:
8-Kern-CPU x 20 Sockel innerhalb eines Horus-Packets x 8 Horus-Packete = 1280 Kerne innerhalb eines ccNUMA-Verbundes.

Hier steckt schon ein enormes Potential.

@HenryWince
Irgendwann hast du mal gepostet wieviele Bits AMD in HTr reserviert hat für sein ccHTr.
Ich glaube es waren irgendetwas mit 10bit - was die Anzahl auf 1024 limitieren würde. ATM implementiert sind 32 - wenn ich das noch richtig im Kopf habe.
Macht es da überhaupt Sinn, wenn man ein 32-Sockel-Horus-System mit DualCores bestückt, oder wurde dies mittlerweile schon erweitert?

Grüße,
Tom

[HenryWince]

Immer größere ccNUMA-Systeme?
Glaub ich nicht. Ich denke der Trend geht weiter in Richtung Grid/Cluster, aber mit n-way SMP Nodes.

Bei den Prozessoren erwarte ich heterogene single ISA Multicores und EU sharing ==> Clustering.

Bei der Hyper-Transport-to-Infiniband-Bridge wird als MPI-Latenz 1.29 Mikrosekunden.

Bei einer Direct-Connect-Architektur werden folgende Latenzen angegeben:
<snip>
Diese Latenzen sind so nicht vergleichbar.

AMD rüstet hoch, kündigt glueless 32 Sockel-Systeme an.
... zumindest wenn es nach dem Inq geht.

Interessant ist wie Cache-Coherenz gereget wird. Beim jetzigen Verfahren müsste man schon 6 HT Links/CPU haben um einigermaßen zu skalieren. Bei einem Directory Based Verfahren bräuchte man einiges mehr SRAM (Dir-Table). Ich hab so meine Zweifel an dem was Charly schreibt. Für mich wäre ein 16-Socket/32-WAY System logischer.

@HenryWince
Irgendwann hast du mal gepostet wieviele Bits AMD in HTr reserviert hat für sein ccHTr.
Ich glaube es waren irgendetwas mit 10bit - was die Anzahl auf 1024 limitieren würde. Also das HT Grund Protokoll limitiert erst mal nix. Die NB der jetzigen K8 besitzt 8 Routing Table Node Register, das müsste man auf 32 Register erweitern. Wenn man das Node ID Register betrachtet sieht man, dass es für AMD leicht wäre das NodeCount Feld auf 5 bit und das NodeID feld auf 4 bit zu erweitern.

Wenn man mehr braucht gäbe es zwar noch Reserved Bits aus dem oberen Teil des Registers, allerdings glaube ich dann eher daran, dass AMD diese Schnittstelle nochmals überarbeitet. Eine Änderung von 8 auf 32 Socket Glueless ist nicht so einfach aus dem Ärmel zu schütteln.

[mocad_tom]

IBM geht einen anderen Weg - das Gigahertzrennen wird wieder aufgenommen. *party*

http://www.isscc.org/isscc/2006/ap/2006_AP_Final.pdf

Seite 62,70,90
------------------------------------------------------------------------------------------------------------

A 5GHz Duty-Cycle Correcting Clock Distribution Network for the POWER6 Microprocessor

Microprocessor global clock distribution networks use long buffered wires where
reflections can be significant. Using accurate transmission-line models and
optimization, these reflection effects can be exploited to improve clock-distribution
characteristics. The clock distribution network of the POWER6 microprocessor is
designed to run at frequencies exceeding 5GHz using only inverters and
transmission lines and is capable of on-the-fly duty-cycle correction.

-------------------------------------------------------------------------------------------------------------

4GHz+ Low-Latency Fixed-Point and Binary Floating-Point Execution Units for the POWER6 Processor

A 1-pipe stage, low-latency, 13 FO4, 64b fixed-point execution unit, implemented
in a 65nm SOI CMOS process, allows back-to-back execution of data dependent
adds, subtracts, compares, shifts, rotates, and logical operations. A 7-pipe stage,
91 FO4, double-precision floating-point unit allows forwarding of dependent
results after 6 cycles in most cases.

---------------------------------------------------------------------------------------------------------------

A 5.6GHz 64KB Dual-Read Data Cache for the POWER6 Processor

A dual-read 8-way set-associative data cache comprising four 16kB SRAMs and 2
set-prediction macros per POWER6 core is presented. The array utilizes a 0.75µm2
butted-junction split-wordline 6T cell in 65nm SOI. The design features dual power
supplies, unidirectional polysilicon, and hierarchical unclamped bitlines for
enhanced cell stability and performance.

----------------------------------------------------------------------------------------------------------------

Grüße,
Tom

[mocad_tom]

Ein blindes Huhn findet auch mal ein Korn, ich zitier mich mal kurz:

http://www.planet3dnow.de/vbulletin/showthread.php?t=222025#post2260874

Bei all dieser Multi- und Many-Core-Diskussion wird total die Single-Thread-Performance ausser acht gelassen. Evtl. war dieses Gerücht gezielt gestreut( back-2-Topic ), um Intel noch weiter in eine Richtung forschen zu lassen - dabei hat AMD ein 4,5GHz-65nm-Monster im Labor laufen der jeden Quad-Core-Yonah von der Strasse fegt.

Einfach mal wieder zurück besinnen - Theorie:

100Transistoren mit 2GHz bringen genau so viel Rechenleistung
wie
50Transistoren mit 4GHz

Wenn ein Kern die selbe Rechenleistung wie zwei Kerne bringt spart man sich den Verdrahtungsaufwand. Keine SRQ, kein HTr und trotzdem die gleiche Rechenleistung.

Allerdings wird schon spekuliert ob der Power6 überhaupt ein OoO-Design wird.

Grüße,
Tom

[mocad_tom]

Zum Power6 ein sehr interessanter Artikel:

http://www.realworldtech.com/page.cfm?ArticleID=RWT121905001634&p=3

750M Transistoren, davon 630-700M transistoren für caching und Systemfunktionalität (routing, directories, memory controller usw). Hier wird klar wie schwierig es ist zukünftige Multikernsysteme sinnvoll mit Daten zu befeuern - wieviel Infrastruktur nötig wird.

Zusätzlich zu diesen enormen Aufwand nutzt man noch die Vorteile von SMT - Speicherlatenzen lassen sich dadurch gut verstecken(in multithreaded Anwendungen).

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2657&p=2
http://images.anandtech.com/reviews/cpu/sun/ultrasparc_t1/CMTgraph.jpg
Hier eine wahnsinnig starke Grafik wie man sich die Threadwechsel vorzustellen hat.
Es wird einfach ständig geswitcht. Es sind keine 32 Threads !gleichzeitig! am Arbeiten sondern nur 8.

Auch beim Niagara wird sehr viel Die-Space in die Infrastruktur gesteckt.
Ob sich die Kosten dafür wirklich rechnen?
Wäre nicht evtl. ein Die mit 16 GeodeLX mittels GeodeLink an einen starken Memorycontroller gekoppelt viel effizienter?
Hat sich Sun mit dem Web/Java-Server-Markt als Zielmarkt wirklich die richtige Niesche ausgesucht - hier braucht man keine stark verzahnten Kerne. Load-Balancer(auf Software-Ebene) können dies in Cluster-Infrastrukturen genausogut.

Grüße,
Tom

[mocad_tom]

http://www.theregister.com/2006/02/03/rack_soars/

Oh Mann

:-X

Wie blöd kann man sein, wenn man im November nicht zugreift.

Grüße,
Tom

[mtb][sledgehammer]

Ich denke das passt hier am besten hin: Im aktuellen Digitime Interview gibts mal wieder eine interessante Passage von Henri Richard:
http://www.digitimes.com/bits_chips/a20060316PR200.html
Its [Opterons] superior scalability allows us to have both a cost-efficient 1P server and, soon, potentially hundreds of cores interconnected in a cost-efficient way.
...
So the notion of either Opteron becoming a co-processor or other architectures becoming a co-processor to Opteron, that's not excluded, and it would be in a normal tradition at AMD ? a tradition of partnership and collaboration in the industry ? to think about a range of possible solutions as long as that?s what end-user customers are demanding.
...
Hardware is only ultimately as good as the software that runs on it. And every day, there are millions of lines of good code added to x86, at a faster rate than any other architecture.
...

[mocad_tom]

Ich hol den mal wieder hoch, aus gegebenem Anlass:

http://www.dailytech.com/IBM+z10+Processor+Takes+20core+Crown/article10882.htm

[Bobo_Oberon]

Ich hol den mal wieder hoch, aus gegebenem Anlass:

http://www.dailytech.com/IBM+z10+Processor+Takes+20core+Crown/article10882.htm
Die Bildunterschrift ist dort bei DailyTech teilweise Unsinn:
Each of these three IBM z10 processor contains twenty cores, 60MB of L2 and 48MB of L3 cache Dieses dort nennt sich MCM (Multi Chip Module).
-> http://www.orthy.de/images/stories/bokill/IBM/Z-Serie/z10/ibm_z10-mcm_janet-rocque.jpg.
Quelle (http://www.orthy.de/index.php?option=com_content&task=view&id=5364&Itemid=86)
Auf diesem Keramik-Modul packt IBM dann die Prozessoren, L3-Cache und andere notwendige Dinge rauf. In dem Fall sind das die z10 Prozessoren. Der z10 ist ein nativer Quadcore, wie sein Vorgänger z6 auch.

Ich zähle allerdings dort 7 quadratische Chips, obs nun auch die z10-Prozessoren sind, vermag ich einstweilen aber noch nicht zu sagen. Von daher gehe ich zur Zeit spekulativ von 4x 7 Quadcores aus -> 28 Kerne pro MCM (und nicht 20).

IBM hat bislang vorher ein etwas anderes MCM-Design gehabt:
http://www.orthy.de/images/stories/bokill/IBM/Power5/ibm_power5-mcm.jpg
4x Power5 auf einem MCM.

MFG Bobo(2008 )

[mocad_tom]

Die 7 Dice auf dem MCM verteilen sich wie folgt:
5 Dice mit monolitischen Quadcores = 20 Cores
& 2 Dice die als Serviceprozessoren bezeichnet werden und "nur" L3 zur Verfügung stellen.

[Bobo_Oberon]

Die 7 Dice auf dem MCM verteilen sich wie folgt:
5 Dice mit monolitischen Quadcores = 20 Cores
& 2 Dice die als Serviceprozessoren bezeichnet werden und "nur" L3 zur Verfügung stellen. Wobei IBM unter "Serviceprozessoren" mitunter deutlich mehr versteht, als "nur" L3-Cache.

" ... CP: Central Processor = Hauptprozessor(en) für Betriebssystem.

SAP: System Assistance Processor = Zusatzprozessoren.

IFL: Integrated Facility for Linux = Ist ein Hauptprozessor, jedoch ohne den Instruktionssatz der ISA der z-Serie, dem z/OS.

Spare: Ist ein allgemeiner Begriff für Reserveprozessoren, falls ein "CP", "SAP" ausfallen sollte.

zAAP: Application Assist Processor. ... "

http://www.orthy.de/images/stories/bokill/IBM/Z-Serie/ibm_zaap_z-application-assist-processor.jpg
Quelle (1. (http://www.orthy.de/index.php?option=com_content&task=view&id=5364&Itemid=86), 2 (http://www.orthy.de/index.php?option=com_content&task=view&id=5079&Itemid=85).)

Es gibt da durchaus mehrere Möglichkeiten, welchen Sinn und Nutzen die anderen 2 Prozessoren haben. ;)

MFG Bobo(2008 )

[HenryWince]

Die Bildunterschrift ist dort bei DailyTech teilweise UnsinnNein, die ist vollkommen korrekt. IBM bezeichent das MCM auch als Processor Book bzw. z10 EC Processor. Die eigentlichen quadcore Chips wurden unter dem Namen "z6" entwickelt (Siehe Hot Chips Publikationen).

[..]2 Dice die als Serviceprozessoren bezeichnet werden und "nur" L3 zur Verfügung stellen

Kleine Korrektur: Die zwei Chips in der mitte sind Storage Controller (SC) Chips und keine Serviceprozessoren. Neben je 24MB L3 enthalten sie auch eine SMP Fabric und IO-Interfaces.


Übrigens alle Processor Units, egal ob CPs, SAPs, zAPPs, usw. entsprechen genau einem z6 Core. IBM verkauft/lizensiert das halt entsprechend... Die HW ist trozdem identisch (alle nutzen das gleiche Instruction Set).

Einen recht guten Überblick findet ihr hier (http://www.redbooks.ibm.com/redpieces/pdfs/sg247515.pdf)

[Bobo_Oberon]

Nein, die ist vollkommen korrekt. Nein das ist nicht "vollkommen" korrekt, da du selber vom "Processor Book" sprichst ;)

Richtig ist, dass IBM bei der z/OS-Serie auch immer gerne bei dieser Ansammlung dieser Chips gerne von Prozessor spricht, aber dann eben immer mit eigenen speziellen Akronym-Zusätzen.

In Anbetracht des Leserkreises ist die Bezeichnung bei DailyTech eben doch zu kurz gefasst. Auch ein einzelner z10 (oder auch z6) ist schon ein vollständiger Prozessor.
Der z6 ist aber von "Natur" aus eben für diesen Betrieb mit dem MCM ausgelegt (wie diverse andere z-Serien- und Power-Prozessoren auch).

Die eigentlichen quadcore Chips wurden unter dem Namen "z6" entwickelt (Siehe Hot Chips Publikationen). ... Kann ja nachfragen, is ja bald Cebit ;D
Einen recht guten Überblick findet ihr hier (http://www.redbooks.ibm.com/redpieces/pdfs/sg247515.pdf) Jo, danke. ;)

MFG Bobo(2008 )

[HenryWince]

Nein das ist nicht "vollkommen" korrekt, da du selber vom "Processor Book" sprichst ;)

Ich gebe nur das wieder was IBM dazu sagt...

Auch ein einzelner z10 (oder auch z6) ist schon ein vollständiger Prozessor.

Es steht ausser Frage, dass ein einzelner z6 Chip vier vollständige Kerne beinhaltet und man ihn damit eigenlich als Prozessor bezeichnen könnte.

Fakt ist aber, dass IBM diese Chips gar nicht einzeln verkauft. D.h. für IBM gibt es kein z6 Prozessor als Produkt, sondern nur das entsprechende Processor Book. So ein "Processor Book" ist eben einer der Prozessoren einer z10 Kiste.

Das ist so ähnlich als würde man sagen ein Core 2 Quad sei kein Prozessor weil er zwei eigentlich vollständige dual Core dies beinhaltet.

Letztendlich definieren alle Hersteller einen Prozessor als lieferbares Produkt in einem bestimmten Packgage.

[Bobo_Oberon]

... Fakt ist aber, dass IBM diese Chips gar nicht einzeln verkauft. D.h. für IBM gibt es kein z6 Prozessor als Produkt, sondern nur das entsprechende Processor Book. So ein "Processor Book" ist eben einer der Prozessoren einer z10 Kiste.
...
Letztendlich definieren alle Hersteller einen Prozessor als lieferbares Produkt in einem bestimmten Packgage. Is ja richtig. ;) Mein Einwand betrifft eher die Rolle der Fachpresse.

IBM bezeichnet dieses Prozessor-Produkt mit einer Vielzahl von PUs auf dem MCM ja auch als "Processor Book".

Die Leser bei DailyTech sind eher gewohnt Prozessoren als einzelnen Chip, bzw. Prozessoren im Stil von Intels aktuellen Quadcores (zwei Dice auf einem gemeinsamen Chipträger) als "Prozessor" zu verstehen.

Dass DailyTech durchaus auch Inhalte für ihren Leser zurecht portioniert zeigt ja die Formulierung: "Each of these three IBM z10 processor contains twenty cores, 60MB of L2 and 48MB of L3 cache" IBM spricht von "L-1,5" Cache und lässt die Bezeichnung "L3"-Cache weg in den "SPs".

Das z10-Produkt dort bei DailyTech als "Prozessor" zu verkaufen, das verschüttet eben doch die Vielzahl der weiteren Begriffe von IBM und es lässt die Rolle von IBMs MCM unberücksichtigt. Hätten sie "Processor Book" geschrieben, dann hätte ich ja auch nichts gesagt. ;)

Zum Topic:
IBM setzt hier weiterhin auf seine Kryptologie-Erfahrung und auch auf deren XML- und DB2-Beschleunigung in Hardware. Zusätzlich kommt deren DFP-Einheiten erneut zum Tragen.

Auch Sun setzt auf Beschleunigung von Krypto-Schlüsseln und Beschleunigung von Datenbanken, wenngleich in einem anderen Stil.

MFG Bobo(2008 )

[HenryWince]

Mein Einwand betrifft eher die Rolle der Fachpresse.
Irgendwie stehe ich da auf dem Schlauch
Die Leser bei DailyTech sind eher gewohnt Prozessoren als einzelnen Chip, bzw. Prozessoren im Stil von Intels aktuellen Quadcores (zwei Dice auf einem gemeinsamen Chipträger) als "Prozessor" zu verstehen.
Nichts anderes ist so ein Processor Book...
Dass DailyTech durchaus auch Inhalte für ihren Leser zurecht portioniert zeigt ja die Formulierung: IBM spricht von "L-1,5" Cache und lässt die Bezeichnung "L3"-Cache weg in den "SPs".
Wo liest du was von L-1,5 Cache? Mit SPs meinst du jetzt die Storage Controller!?
Das z10-Produkt dort bei DailyTech als "Prozessor" zu verkaufen, das verschüttet eben doch die Vielzahl der weiteren Begriffe von IBM und es lässt die Rolle von IBMs MCM unberücksichtigt. Hätten sie "Processor Book" geschrieben, dann hätte ich ja auch nichts gesagt. ;)

Aehm, was meinst du damit? Ich sehe keinen Widerspruch!

Ein Z10 System kann bis zu vier Prozessoren (=Processor Books) aufnehmen. Ein solcher Prozessor besteht seinerseits aus 5 Quadcore Dies (=z6) und zwei Storage Controller Chips (=SC) mit jeweils 24MB L3 Cache+SMP Fabric und entsprechenden IO-Interfaces. Jedes z6 Die besitzt seinerseits 4 Kerne die als PU (=Processing Unit) bezeichnet werden.

Aus verschiedenen Gründen gibt es eine MCM Variante bei denen nur 17 PUs existieren. D.h. IBM verwendet in einem Teil der MCMs Teildefekte z6 mit nur 3 funktionierenden Kernen.

Entsprechend der Konfiguration/Lizensierung kann so eine PU als CP, SAP, zAPP, ILF usw. verwendet werden. D.h. was IBM als XML oder DB2 Beschleuniger verkauft sind nichts weiter als dedizierte Kerne auf denen eine entsprechende Firmware läuft.

Im derzeitigen Maximalausbau kommt eine Z10 auf 77 Kerne:

1 MCM mit 17 PUs (=3*3cores+2*4cores) und 3 MCM mit 20 PUs (=5*4cores).

Für den Nutzer stehen maximal 64 PUs als CP zur Verfügung. Die restlichen PUs können andere Funktionen (SAP. ILF, etc) Wahrnemen oder nur als Spare rumgammeln.

[mocad_tom]

Ich wollte diesen Thread mal wieder nach oben bringen um zu zeigen wie gut der Barcelona im Moment im Serverbereich ankommt - leider ist es eine stille Revolution:

Hier der nested page table review von johan de gelas:
http://it.anandtech.com/weblog/showpost.aspx?i=467

Dann ein Test zu paravirtualized / fully virtualized:
http://www.redhatmagazine.com/2008/07/03/red-hat-enterprise-linux-5-virtualization-on-hp-dl585-amd-barcelona-with-rapid-virtualization-indexing/

Diese Tests können !nur! mit dem Barcelona gemacht werden, weil er die einzige x86-cpu mit diesen features ist.

Dann noch ein sehr erfreulicher specjbb-bench:
http://www.theinquirer.net/gb/inquirer/news/2008/08/08/sun-server-shatters-speed

8-socket-kiste:
683540 bops und 85450bops per jvm sind richtig ordentliche Werte.
Man hat also nur 8 jvms laufen lassen.

Zum Vergleich:
4-socket-kiste:
HP DL585
http://www.spec.org/jbb2005/results/res2008q2/jbb2005-20080422-00480.html
368540 bops und 92100bops per jvm.

Die 8-socket-kiste skaliert einigermassen ordentlich mit der Anzahl de Sockets und kann zum Teil richtig teure Server bei Preis/Leistung in Grund und Boden stampfen. Im Server-Bereich ist der Barcelona jetzt schon auf der Höhe, mit Shanghai wirds noch besser.

Grüße,
Tom

[Alex84]

Die 8-socket-kiste skaliert einigermassen ordentlich mit der Anzahl de Sockets und kann zum Teil richtig teure Server bei Preis/Leistung in Grund und Boden stampfen. Im Server-Bereich ist der Barcelona jetzt schon auf der Höhe, mit Shanghai wirds noch besser.

Hallo!
Weißt du auch wie es mit den Marktanteilen und Verkaufszahlen im Serversegment ausschaut? Ich hab eher den Eindruck, als hätte der Barcelona in allen Bereichen echt ein (meiner Meinung nach unbegründetes) chlechtes Image. Aber vielleicht irre ich mich ja?
-Alex

[Bobo_Oberon]

Hallo!
Weißt du auch wie es mit den Marktanteilen und Verkaufszahlen im Serversegment ausschaut? Ich hab eher den Eindruck, als hätte der Barcelona in allen Bereichen echt ein (meiner Meinung nach unbegründetes) schlechtes Image. Aber vielleicht irre ich mich ja?
-Alex Nun ja ... bei billigen Servern mit einem Sockel hat AMD Federn lassen müssen (Conroe-/Penryn-Schock).
Das haben mir die entsprechenden Verkaufsmanager von Tyan, SuperMicro [...] auf der Cebit 2008 bestätigt.

Bei Zweifach-Sockeln ist AMD noch vergleichsweise stabil, wenngleich hier AMD mit den Preisen runtergehen musste. Bei den 4-fach-Sockeln (und mehr) hat AMD (noch) einen stabilen Stand.

AMD hat aber keinen "schlechten Ruf", sondern der Glanz der K8-Systemplattform hat (deutlich) nachgelassen. AMD gleitet nun im Serverbereich in die Low-Cost-Ecke ... das muss nicht zwangsläufig den Ruf beschädigen ...

Bugs sind da viel schädlicher. Und da hat sich AMD mit der ersten Erscheinungsform des K10 "Barcelona" mit dem TLB-Bug so manches selbst kurz und klein geschlagen.

MFG Bobo(2008 )

[mocad_tom]

amd hat nach der behebung des bugs keinen wirklichen launch mehr gemacht - meiner meinung nach hätte man schon diesen "Aha-Effekt" stärker ausbauen können.

bei dem review vom redhatmagazine habe ich auch erst ein wenig gebraucht bis ich die zahlen wirklich kapiert habe. aber der barcelona ist ja in sachen virtualisierung wirklich phenomenal.
schaut euch mal die zahlen an.
Ein beispiel (quad-socket, 20 user):
Unvirtualisiert: 100%
Virtualisiert keine NPTs, keine paravirtualisierten treiber: 5%
Virtualisiert mit NPTs, keine paravirtualisierten treiber: 12%
Virtualisiert keine NPTs, mit paravirtualisierten treibern: 4%
Virtualisiert mit NPTs, mit paravirtualisierten treibern: 67%

ich hätte nicht gedacht, dass virtualisierung so viel performance kostet, und ich hätte nicht gedacht, dass nested page tables + paravirtualisierte treiber für disk i/o und ethernet sooo viel bringt. fehlt eines der beiden also entweder man hat ein system wo paravirtualisierte installiert sind, es fehlt aber NPT oder umgekehrt so muss man mit enormen performanceeinbußen leben. leider habe ich keine zahlen für xeon-kisten zur hand, die müssten aber richtig abkacken gegenüber einem ordentlich konfigurierten und installierten barcelona system.

Grüße,
tom

[Bobo_Oberon]

...
Ein beispiel (quad-socket, 20 user):
Unvirtualisiert: 100%
Virtualisiert keine NPTs, keine paravirtualisierten treiber: 5%
Virtualisiert mit NPTs, keine paravirtualisierten treiber: 12%
Virtualisiert keine NPTs, mit paravirtualisierten treibern: 4%
Virtualisiert mit NPTs, mit paravirtualisierten treibern: 67%

ich hätte nicht gedacht, dass virtualisierung so viel performance kostet, und ich hätte nicht gedacht, dass nested page tables + paravirtualisierte treiber für disk i/o und ethernet sooo viel bringt. ... Haben paravirtualisierte Systeme dennoch Zukunft?

Der Nachteil daran ist, dass bisherige Treiber nochmals explizit für die paravirtuelle Virtualisierung geschrieben werden müssen. Daher Paravirtualisierung gegenüber den klassischen Virtualisierungen, die mit ganz normalen Treibern funktionieren, zeitlich im Nachteil, bzw. wird es auf manchen Rechnern erst gar nicht möglich sein.

MFG Bobo(2008 )

[mocad_tom]

Ich wollte diesen Thread mal wieder hochholen - aus aktuellem Anlass.

Letzte Woche bin ich auf eine wahnsinnig interessante Seite gestossen:
http://highscalability.com/

Auf der Seite sind für mich zwei Beiträge besonders interssant - der Beitrag zur Website Stackoverflow.com und der Beitrag zu plentyoffish.com

http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html
http://highscalability.com/blog/2009/6/26/plentyoffish-architecture.html

Für mich besonders interessant, da beide auf ASP.net & Sql Server 2008 aufbauen und dabei nur je einen grossen DB-Server einsetzen. Bei Stackoverflow wird ein Dual-Sockel-Nehalem mit 48GB Ram eingesetzt und bei plentyoffish wird ein 8-Sockel-Opteron-Server von HP (DL785 G5) mit 512GB Ram eingesetzt.

Vergleicht man diese Seiten auf alexa, so stellt man fest, dass sie durchaus in der Größenordnung von heise.de mithalten können:
http://www.alexa.com/siteinfo/plentyoffish.com

Was sagt mir das? Die Web-Tier müssen nicht zwingend so starke Kisten sein, der Datenbank-Server sollte aber einen möglichst großen Speicherausbau haben - bei Datenbanken rentiert es sich.

In den Kommentaren der Artikel ist immer wieder die Rede davon, dass mit enorm wenig Hardware-Aufwand enorm große Seiten betrieben werden.

Was bringt die Zukunft?
Zukünftig wird man für noch weniger Geld noch größere Seiten hosten können. Z.B. die 4-Sockel Magny-Cours-Systeme im nächsten Jahr, oder ein Dual-Sockel-Westmere-System. Dual-Sockel-Systeme sind bei der Microsoft-Lizensierung extrem günstig. Auf so ein 2-Sockel-Westmere-System kann man ein Windows Server 2008 Small Business Premium für 1000€ drauf machen und gut ist.

Schon extrem was hier mittlerweile geht.

Grüße,
Tom

[mocad_tom]

Wollte hier mal wieder etwas bringen:

http://www.slideshare.net/mongosf/sharding-with-mongodb-eliot-horowitz

Auf Folie 6 wird dargestellt wie das verteilte Datenbanksystem MongoDB beispielhaft aufgesetzt werden kann.

Verteilte NoSQL-Systeme wie MongoDB, CouchDB, BigTable, Tokyo Tyrant und Redis rocken. ;)

Einzelne Rechner werden über Sockets so zusammengehängt, dass eine anfragende Applikation dieses Array aus Rechnerknoten als eine große Datenquelle wahrnimmt.

[mocad_tom]

Habe gerade eben etwas gefunden:
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de//pubs/archive/36448.pdf
Brawny cores still beat wimpy cores, most of the time
................
................
So, although we’re enthusiastic users of multicore systems, and believe that throughput-oriented designs generally beat peak-performance-oriented designs, smaller isn’t always better. Once a chip’s single-core performance lags by more than a factor to two or so behind the higher end of current-generation commodity processors, making a business case for switching to the wimpy system becomes increasingly difficult because application programmers will see it as a significant performance regression: their single-threaded request handlers are no longer fast enough to meet latency targets. So go forth and multiply your cores, but do it in moderation, or the sea of wimpy cores will stick to your programmers’ boots like clay.


Soll so viel heißen wie - commodity Prozessoren an ihrem Effizienz-Knie betrieben eignen sich besser als Wimpy-Cores. Ganz ehrlich ich finde diese Intel-Atom-Cluster und ARM-Cluster auch einfach nur Hirngespinnste.

[Markus Everson]

Soll so viel heißen wie - commodity Prozessoren an ihrem Effizienz-Knie betrieben eignen sich besser als Wimpy-Cores.

Mensch was freue ich mich das ich meine deutsche Muttersprache noch nicht völlig vergessen habe und bullshit-Bingo noch als solches erkenne.

M.a.W.: Gibts den Satz auch in Deutsch?

[mocad_tom]

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.

[tomturbo]

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 (http://http://www.cisco.com/en/US/products/ps9512/index.html) bei uns im RZ im Einsatz.

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

lg
__tom

[Bobo_Oberon]

... 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* (http://backup.orthy.de/index.php?option=com_content&view=article&id=4895:hot-chips-19-start-up-tilera-mit-64-fachem-multicore-update&catid=599:sonstiges&Itemid=56) 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 (http://www.techeye.net/business/tilera-raises-45-million-from-samsung-and-cisco)".

Ältere Meldungen:
"ARM-Server-Startup sammelt 48 Millionen US-Dollar (http://www.heise.de/newsticker/meldung/ARM-Server-Startup-sammelt-48-Millionen-US-Dollar-1059593.html)" (16.08.2010)

"Prozessorgeflüster, Von Okrakel und Oracle (http://www.heise.de/ct/artikel/Prozessorgefluester-1037721.html)" c`t 16 2010 (Sommer 2010)

MFG Bobo(2010)


* = CPU-Glossar (http://backup.orthy.de/index.php?option=com_glossary&id=471)

[mocad_tom]

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/3768?cPage=4&all=False&sort=0&page=1&slug=seamicro-announces-sm10000-server-with-512-atom-cpus-and-low-power-consumption
Wirklich lächerlich.

[Woerns]

@Itanium
Oracle steigt aus.
http://www.heise.de/newsticker/meldung/Oracle-stellt-die-Softwareentwicklung-fuer-den-Itanium-ein-1213716.html
MfG

[ONH]

Bleibt alleine HP übrig, oder gibt es noch eine andere Firma die Itanium benutzt.

[mocad_tom]

Johan de Gelas hat bei Anandtech einen Westmere-EX-Artikel geschrieben.
http://www.anandtech.com/show/4285/westmereex-intels-flagship-benchmarked/6
Ziemlich interessant, dass AMD beim Stromverbrauch gut mithalten kann.
Das müsste ja dann beim BD noch besser werden.

[tomturbo]

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.

[mocad_tom]

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.

[bbott]

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.

[nonworkingrich]

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

[mocad_tom]

http://www.tecchannel.de/server/prozessoren/2029719/intel_xeon_x7560_im_test_neue_generation_dreimal_schneller_als_x7460/index4.html

In Sachen RAS haben die neuen Xeon aufgeholt.

Und zur maximalen Anzahl an Kernen in einem OS:
http://pdos.csail.mit.edu/papers/linux:osdi10.pdf

[Stryki]

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.

[Lynxeye]

http://www.tecchannel.de/server/prozessoren/2029719/intel_xeon_x7560_im_test_neue_generation_dreimal_schneller_als_x7460/index4.html

In Sachen RAS haben die neuen Xeon aufgeholt.

Und zur maximalen Anzahl an Kernen in einem OS:
http://pdos.csail.mit.edu/papers/linux:osdi10.pdf

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.

[bbott]

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...

[mocad_tom]

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.

[Lynxeye]

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.

[bbott]

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.

[Stryki]

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.

[mocad_tom]

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.

[Mente]

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