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.

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

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



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

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

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

Quelle (1., 2.)

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 Unsinn

Nein, 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

 

[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

Einen recht guten Überblick findet ihr hier

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/...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...esearch.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?