Quantumpair

Reality by Observation

PowerMac G5 Und Sein "Elastic Bus"

Der 32Bit breite I/O Bus des PowerPC 970 lauft mit einem Viertel des CPU Taktes, nutzt aber DDR und erreicht damit eine “word rate” in Hohe des Halben CPU Taktes. Der Frontside-Bus (FSB) tragt den Namen “Elastic Bus” und stellt IBM’s Pendant zu RapidIO beziehungsweise HyperTransport dar. Wie diese ist auch er unidirektional und differential, was von elektronischen Berucksichtigungen bei solch hohen Taktraten herruhrt. Ohne hier weiter in die Tiefe zu gehen sind sie einerseits schneller, andererseits einfacher zu implementieren als ihre bi-direktionalen Kollegen. Wenn man die bei diesen neuen Bussen die Latenzzeiten zum Speicher in Taktzyklen ausdruckt, kriegt man einen kleinen Schreck, aber das ist der Preis fur den hohen Datendurchsatz, das ist die neue Realitat! Herzlich Willkommen. Die so herrlich klingenden Cache-Funktionen wie etwa das “predictive streaming” sind nichts anderes als Gegenmassnahmen.

Das “Hyperthreading” hilft in Multiprozessorsystemen, die Latenzzeiten zu drucken, und gegenwartig scheint es als sei IBM diesen Weg gegangen. Jedoch auferlegt man dabei den Caches viel mehr Arbeit, oder sollte ich sagen “Verantwortung”… Insofern stellt sich bei einer Implementierung von Hyperthreading ohne Anpassung der Cachegrossen und des “Instruction Timings” nicht der erwartete Erfolg ein.

Entgegen den fruheren Busprotokollen die wir kannten (603/MPX), teilen sich mehrere Prozessoren beim Elastic Bus nicht einen Frontside-Bus. Das bedeutet naturlich, dass sich die CPU’s die limitierte Bandbreite des Busses nicht teilen mussen, aber es zieht auch die Konsequenz nach sich, dass der Speicher Controller eine ziemliche Anzahl an Pins haben muss: Pro Prozessor namlich 128 (32 [Bits] * 2 [Signalleitungen] * 2 [Richtungen]), folgerichtig haben wir 256 Anschlusse nur fur die Prozessorbusse, bevor wir uberhaupt gucken, WO wir jetzt anbinden wollen. Das geht zwar, aber eine Skalierung deutlich jenseits von 2 CPUs erfordert (nicht nur) deswegen eine NUMA Architektur in irgendeiner Form.

Wieviel schafft er aber jetzt? Nun, die Rechnung ist jetzt nicht mehr so schwer – nehmen wir einen einzelnen 2GHz Prozessor: (Selbstverstandlich bezogen auf die Transferrate von Bytes und nicht auf Megabytes effektiver Nutzdaten)

2 GHz [CPU Takt] * (½) [Bustakt] * 4 [Bytebreite] = 4 GB/s in jede Richtung

Werbemenschen kommen mit diesem Wert dann auf die netten 16 GB/s, indem sie die 4 GB/s erst verdoppeln fur die beiden Richtungen und hernach abermals mit 2 multiplizieren, um einem Dualen Mac gerecht zu werden. Das sind ~ 2 DVD/s. Ich denke fur einige Vergleiche ist das jetzt gar nicht so unfair, denn “so zahlt man eben”, wenn es um Zahlen und Leistung geht.

Doch es ist irrefuhrend. Zumindest in 3 Punkten:

  • Wie ich oben in Klammern bemerkte, enthalten die Busdaten auch Adress- und Steuersignale, was zu einem gewissen Overhead fuhrt (sprich der Anteil der Nutzdaten auf dem Bus ist nicht 100% der Buskapazitat — der Schaffner fuhrt halt auch noch mit g).

  • Es gibt eine Menge Programme, bei denen man hauptsachlich uber den FSB liest, und nur selten schreibt, womit man die “totale Bandbreite” gar nicht ausschopfen kann.

  • Die Speicherbandbreite hat schlicht gar keine Chance, mit dem theoretischen Maximum des Prozessorbusses mitzuhalten: DDR400 ergibt pro “Kanal” 40082 = 6.4GB/s (Theor. Maximum!) fur Lesen und Schreiben !

Die “Geruchte” uber diese Performance, die IBM selbst im Mai diesen Jahres angab, stimmten also, bezogen sich aber auf einen 1.8Ghz 970 Prozessor und die hatten freundlicherweise schon den Overhead abgezogen (1.8Ghz * 0.5 * 4 * 2 = 7.2GHz effektiv). Und weil wir so vorwitzig sind, rechnen wir damit gleich aus, dass der Steuersignal-Overhead gerade mal 11% betragt. Also ICH kann damit gut leben ;–)

Auf was ich aber hinauswollte ist, dass durch dieses Vorrechnen etwas klar werden sollte: Selbst dieser 1.8 GHz Prozessor kann mit seinen gemass IBM praktischen Werten von gegen 6.4 GB/s das Limit des DDR400 Speichers erreichen! Oder anders ausgedruckt – der Speicher wird zum Flaschenhals, bevor es auf dem Elastic Bus eng wird. Aber nein, nein, nein, das ist nicht schlecht, das is GUT! Der neue Bus muss uns auch ne Weile halten jetzt.

Jetzt sieht man, dass ein 2GHz Dual G5 derart viel Daten in den Speicher schaufeln konnte, dass das DDR einen Heulkrampf zu kriegen droht. Das ist naturlich etwas “suboptimal”, aber – wieder – lieber so als andersrum. Andersrum hatten wir es nun eine Weile, ich denke was Neues macht auch mal Spass, oder!

Leider aber haben die G5 Systeme keine grosszugig ausgelegten L3 Caches wie ihre grossen Power4 Bruder, und damit haben wir ein Problem. Letztlich aber reden wir von einer “Consumer” Maschine aus dem “Pro” Sektor, und auch dort spielt der Preis eine Rolle. Die meisten PC-Systeme, gegen die der G5 aber wird antreten mussen, haben auch keine L3 Caches. Geht schon.

Doch jetzt wo der Prozessor mal schnell ist:

Die Verknupfung des Elastic Bus mit dem Prozessortakt (1:4, DDR) bedeutet, dass der Systembus “automatisch” mit dem CPU-Takt skaliert. Naturlich sind diesem Wachstum irgendwo Grenzen gesetzt, aber ich denke die sind weit weg, zeitlich ebenso wie hinsichtliche des Taktes. Eine mogliche Losung ware dann die Verbreiterung des Busses (“mehr Bit!”).

Diese kontinuierliche Steigerung des FSB stellt das Speicherinterface vor immer grossere Probleme, denen es ohne Innovation in diesem Bereich nicht wirklich gewachsen ist. Wir scheinen uns immer mehr einer “Quantenunscharfe” zu nahern, indem wir nur entweder Durchsatz oder Reaktionszeit haben konnen, scheinbar aber nicht beides! Was wir momentan tun konnen, ist die Breite des Speichers anzupassen an die der CPUs. Der G5 weist ein 128bit Speicherinterface auf, das sich aus 2 normalen DDR Kanalen zu je 64bit zusammensetzt. Das ist ein Vorteil, aber es ist vergleichsweise aufwandig zu realisieren und zieht Kosten nach sich. Der “4-Kanal-256bit-Speicherbus” bleibt ein Traum, solange die Maschine keine 5000$ kosten soll. (Die Anbindung ist ausserordentlich zeitkritisch und wir sind seit Jahren soweit, dass wir die “Lichtgeschwindigkeit” (stark vereinfacht) ebenso berucksichtigen mussen wie Hochfrequenzverhalten).

Aus dem Publikum hore ich “Rambus RAM”, aber wahrend ich den Ansatz (Optimierung auf Datendurchsatz pro Bit, sozusagen) fur recht schlau halte, erhoht Rambus die Zugriffszeit massiv, ebenso wie die Kosten steigen. Zudem hat Rambus keine Freunde mehr seid der Lizenz-“Sache”. Jedoch mag sich trotzdem eine Nische fur Rambus ergeben, neben der bereits etablierten bei den GPUs: L3 Cache. HP hat diesen Weg schon einmal beschritten mit 32MB pro CPU (Hab die URL leider nicht mehr). Rambus eignet sich fur kontinuierlichen Datenfluss, “streaming”, nicht aber fur pseudo-zufallige Zugriffsmuster. Ein Cache kommt dem mit seiner Arbeitsweise entgegen, sodass es nicht unmoglich ist, dass wir diesen Lösungsansatz; sogar einmal betrachten durfen.

Derzeit ist DDR sicher der Konig der Speicherbausteine, und der “Nachfolger” DDR-II wird die Sache nicht grossartig verbessern, wenn auch ein klein wenig. Das heisst nur eines: Mittelfristig muss was anderes her! Apple wird den Memory Controller (Apple? Ja, Apple baut den Memory Controller in IBMs Design Facility unter Nutzung IBMs Infrastruktur. Ich meine, da arbeitet ein Apple Team in der IBM Fab mit deren Experten zusammen an dem G5 Chipset) wohl schon verbessern konnen, um zukunftigen schnelleren DDR-“Standards” Paroli bieten zu konnen, wobei der Elastic-Bus hier keine Probleme einbringen wird. Mit anderen Worten: Ich glaube nicht, dass Apple hier Probleme haben wird, den kommenden Industrie-Standards zu folgen.

Jedoch kommen noch mehr Probleme auf uns zu: Wer sich auskennt weiss, dass DRAM etwas schwierige Zeiten vor sich hat, geht es doch um weitere Steigerungen, die immer aufwandiger werden. Damit nicht genug, werden uns je langer je mehr die Latenzzeiten bei MP Systemen Sorgen bereiten, und hier sieht die Sache eigentlich nicht so rosig aus. Losungsansatze gehen bisher davon aus, soviel L3 Cache “as you can” einzubauen (*wink wink), was doch ein Stuckchen Leistungsfahigkeit bringt, aber ehrlich gesagt einfach die Unzulanglichkeiten “deckt”. Klar ist, dass die kommenden IBM Hochleistungssysteme Level-3 Cache aufweisen werden.

Ein sehr positiver Nebeneffekt der Nahe des 970 zu der Power Serie ist nicht nur die stark verkurzte Designzeit (vom Power4 die Probleme abgucken), sondern auch das “Erben” von Features, unter anderem auch des Power5. So erwarte ich in absehbarer Zeit, dass die Apple Hardware eDRAM unterstutzen wird. eDRAM ist DRAM, das einen SRAM “Cache” vor die Nase gesetzt bekommen hat, um die am meisten angefragten Daten schneller liefern zu konnen. IBM bastelt derzeit an der dritten Generation der Chips. Entgegen der G4-Baureihe weist der Power970 (und auch der Power4) keine dedizierten L3-Cache Anschlusse auf, sodass bei einer Implementierung eines weiteren Zwischenspeichers dieser via der Northbridge angebunden wurde (wie beim Power4 der Fall). Wichtig ist, zu sehen, dass das eine ganzlich andere Topologie ist.

Wahrend HyperThreading nur positive Auswirkungen auf Probleme mit Latenzen hat, kommt ein Treffer im L3 Cache (unter der Annahme, dass DRAM der Flaschenhals ist) sowohl der Latenz als auch dem Durchsatz zugute. Und da nun alles von Latenzzeiten zu reden scheint, ist es nur logisch zu folgern, dass der Memory Controller irgendwann auf dem Prozessor sitzen wird. Wenn man aber bedenkt, wie der vorliegende Controller im G5 entstanden ist, erscheint es nicht nachvollziehbar, wenn IBM schon an der Implementierung des Speicherinterfaces arbeiten wurde – und damit diesen Controller nutzlos machen wurde. Daher gehe ich eher von Dual Core Prozessoren aus, bevor wir das Speicherinterface auf dem Prozessor sehen.

Zum Schluss mochte ich noch ein kunterbuntes Paket mit diversen Infos schnuren.

Apple hat die G5 Systemarchitektur von Grund auf neu entwickelt, weil man dieses Mal nicht schon nach kurzer Zeit an irgendwelchen Limiten oder Missstanden anstossen will. Der erste Designansatz scheint gewesen zu sein, dass keine System- Komponente die anderen behindern darf, damit jedes Teil so schnell arbeiten kann, wie es vermag. Als Folge ist mehr oder weniger Alles im G5 als Punkt-zu-Punkt Verbindungen aufgebaut, was eigentlich gar kein Bus mehr ist.

Die Northbridge arbeitet auch intern “Punkt-zu-Punkt”, sodass der Chip an jedem Port die dem Port eigene Geschwindigkeit unterstutzen und vorallem Nutzen kann. Die Auslegung der Speicherbanke ist respektabel, man sieht auch in der PC Welt, dass es nicht einfach ist, Boards mit so vielen DDR Steckplatzen herzustellen.

Der AGP Pro 8x Anschluss liefert bis zu 75 Watt an die Graphikkarte und ist direkt an die Northbridge angebaut, damit eine gute Verbindung zum Hauptspeicher bestehen kann. Die PCi Slots sind m.E. als “PCI-X Tunnel” ausgefuhrt, was auch vom Blockdiagramm;) des Rechners unterstutzt wird. Die 100 MHz PCI Steckplatze sind auf einem PCI Bus, der 133MHz Steckplatz auf dem anderen, da die PCI-X Spezifikation nur einen 133MHz Slot pro Bus erlaubt.

Da wir aber HyperTransport verwenden zwischen der Northbridge und der Southbridge (und dem dazwischen liegenden PCI-X Tunnel), macht es auch Sinn, dass – entgegen Pangea bzw. UniNorth/Keylargo – sowohl Ethernet als auch ATA auf die Southbridge zu verlegen (Bei einer lacherlichen PCI-Verbindung zwischen den Chips ging das naturlich nicht!). Anscheinend wird 16-bit HT verwendet, um die nordliche Brucke mit dem PCI Tunnel zu verbinden, und nur noch 8bit HT weiter zur sudlichen Brucke (der grosse Datenstrom ist ja nun abgezweigt). Wie eingangs erwahnt ist auch dieser Bus unidirektional, also gelten die Bit-Breiten wiederum pro Richtung. Leider habe ich immer noch nicht herausfinden konnen, mit welchen Frequenzen die Chips bzw. HT arbeiten.

Die Kuhlung des ganzen G5 ist eine Sache fur sich.

Wie an der Keynote kurz angerissen weist der G5 4 thermische Zonen auf, die mittels 9 Kleinventilatoren umgewalzt werden. Im Netzteilbereich laufen die 2 Lufter mit konstanter Drehzahl, das Netzteil befindet sich am Gehauseboden, ist proprietar und sehr dunn. Die Lufter in den Laufwerksschachten hingegen regieren auf eine Feedbackschleife, die die Temperatur der austretenden Luft misst, wahrend die AGP/PCI Zone ihre Konvektion basierend auf der Leistungsaufnahme(!) der PCI Karten regelt! Zu guter Letzt sei auf die Prozessorlufter verwiesen, die ihre Drehzahl naturlich aufgrund der gemessenen Chiptemperatur des Power970 einstellen.

Viele Leute scheinen nicht zu verstehen, dass viele kleine Lufter den L&auuml;rmpegel senken konnen (weil beispielsweise ein grosser Anteil des entstehenden Larmes durch den Gegendruck der Luft entsteht), sodass die 2+2 Kombination (nennt man in der vorliegenden Anordnung “Push-Pull”) den Larm senken kann. Die beiden “ziehenden” CPU Lufter arbeiten identisch, aber die “stossenden” sind von der jeweiligen CPU abhangig, die sie beluften. Bei den Single CPU Rechnern hat es demnach nur einen Lufter, der schiebt, die beiden ziehenden bleiben.

Zu dem Kuhlsystem – heutzutage ja eher ein “Anti-Larm-System” – gehort auch die angemessene Nutzung der Hauptprozessoren bzw. deren Bremsung bei Arbeitsmangel. Die Systeme arbeiten angeblich in der Regel mit etwa 2/3 des angegebenen Taktes, konnen den aber innert einer Millisekunde hochfahren (ohne dabei zu “stolpern”: wahrend dem Hochfahren arbeiten sie ganz normal). Als Ergebnis dieser Massnahme konnte der mittlere Leistungsverbrauch um 60% verringert werden (85% Ersparnis bei “nichts tun”). Die CPU-Lufter sollen dem Vernehmen nach “gerade mal so ein bisschen drehen”, wenn der Mac lauft aber nicht benutzt wird. Das √úberwachungssystem der Lufter wurde wohl dem XServe entnommen und es wurde mich nicht wundern, wenn man diese Werte mit denselben oder ahnlichen Tools auslesen konnte. Auf der Hardware Seite ist der G5 vorbereitet, dem Benutzer mitzuteilen, dass ein Lufter langsamer dreht, als es die ihm zugefuhrte Leistung erwarten liesse; es entzieht sich aber meiner Erkenntnis, ob OS X 10.2.7/10.3 dafur geeignete Mechanismen mitbringen wird.

Fragt sich noch immer jemand, was Apple die vergangenen 18 bis 24 Monate getan hat?

Seit dem ominosen Auftauchen eines angeblichen DDR-Mainboards vor der MWNY 2001 – das das letzte war mit der nie recht funktionierenden UniNorth2, deren kontinuierliches “Versagen” dann zum “Tod” von UMA2 fuhrte – ist Apple auf der Power970 Schiene, bzw. einfach auf der IBM Schiene, um es zu verallgemeinern. Es ist klar, dass der G5 ohne IBM das ware, was er ist, aber ich will Apple auch nicht die verdienten Lorbeeren stehlen. Bei Grossenordnungen wie bei denen, wo Apple bei IBM anklopft fur einen neuen Prozessor, wird oft viel mehr kooperiert als man annimmt und es ist schlicht und einfach eine Notwendigkeit. Dass Apple die Chips auf dem Mainboard alleine entwickelt haben soll ist ebenso Blodsinn wie die Idee dass Jonathan Ive den G5 alleine gestylt hatte.

Fazit: In das Design und die Entwicklung sowohl des Prozessors als auch der weiteren Komponenten wurde Energie gesteckt, und die Zusammenarbeit mit IBM als die fuhrende Chipschmiede tragt wieder einmal Fruchte. Dieses mal aber – so scheint mir – sind die Fruchte viel grosser, saftiger und susser !

  1. Juli 2003 | Mr.Mike

Quellen: _– IBM Technology Group Customer Event 2003IBM Power970 Info SeiteIBM PowerPC970 Dokumentation (soweit vorhanden) – Ars Technica _