ARCHIV 1999-2006

ARCHIV :: # 2145

Dem G5 zwischen die Rippen geschaut

"Aber vorsicht!", das könnte geeky werden.

Autor: mike - Datum: 03.07.2003

Es war mir ein Bedürfnis, bei den Diskussionen um den "G5 und seine möglichen Gegenspieler" auch einmal auf einige Fakten hinzuweisen, die bisher gänzlich untergegangen sind bzw. die "Speicherthematik" nüchtern zu betrachten. Ich hab aber nach bekannter Manier kein Konzept für meine Artikel und so kommt zur Sprache, was mir wichtig erschien. Der neue G5 und der "Elastic Bus"



Der 32Bit breite I/O Bus des PowerPC 970 läuft mit einem Viertel des CPU Taktes, nutzt aber DDR und erreicht damit eine "word rate" in Höhe des Halben CPU Taktes. Der Frontside-Bus (FSB) trägt 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 Berücksichtigungen bei solch hohen Taktraten herrührt. 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 ausdrückt, kriegt man einen kleinen Schreck, aber das ist der Preis für den hohen Datendurchsatz, das ist die neue Realität! 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 drücken, und gegenwärtig 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 Cachegrössen und des "Instruction Timings" nicht der erwartete Erfolg ein.

Entgegen den früheren Busprotokollen die wir kannten (603/MPX), teilen sich mehrere Prozessoren beim Elastic Bus nicht einen Frontside-Bus. Das bedeutet natürlich, dass sich die CPU's die limitierte Bandbreite des Busses nicht teilen müssen, aber es zieht auch die Konsequenz nach sich, dass der Speicher Controller eine ziemliche Anzahl an Pins haben muss:
Pro Prozessor nämlich 128 (32 [Bits] * 2 [Signalleitungen] * 2 [Richtungen]), folgerichtig haben wir 256 Anschlüsse nur für die Prozessorbusse, bevor wir überhaupt 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:
(Selbstverständlich bezogen auf die Transferrate von Bytes und nicht auf Megabytes effektiver Nutzdaten)

2 GHz [CPU Takt] * (1/2) [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 für die beiden Richtungen und hernach abermals mit 2 multiplizieren, um einem Dualen Mac gerecht zu werden. Das sind ~ 2 DVD/s. Ich denke für einige Vergleiche ist das jetzt gar nicht so unfair, denn "so zählt man eben", wenn es um Zahlen und Leistung geht.

Doch es ist irreführend. Zumindest in 3 Punkten:

• Wie ich oben in Klammern bemerkte, enthalten die Busdaten auch Adress- und Steuersignale, was zu einem gewissen Overhead führt (sprich der Anteil der Nutzdaten auf dem Bus ist nicht 100% der Buskapazität -- der Schaffner fährt halt auch noch mit *g*).
• Es gibt eine Menge Programme, bei denen man hauptsächlich über den FSB liest, und nur selten schreibt, womit man die "totale Bandbreite" gar nicht ausschöpfen kann.
• Die Speicherbandbreite hat schlicht gar keine Chance, mit dem theoretischen Maximum des Prozessorbusses mitzuhalten: DDR400 ergibt pro "Kanal" 400*8*2 = 6.4GB/s (Theor. Maximum!) für Lesen und Schreiben !

Die "Gerüchte" über 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% beträgt. 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 gemäss IBM praktischen Werten von gegen 6.4 GB/s das Limit des DDR400 Speichers erreichen! Oder anders ausgedrückt - 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 *könnte*, dass das DDR einen Heulkrampf zu kriegen droht. Das ist natürlich 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 grosszügig ausgelegten L3 Caches wie ihre grossen Power4 Brüder, 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 müssen, haben auch keine L3 Caches. Geht schon.

Doch jetzt wo der Prozessor mal schnell ist:

Die Verknüpfung des Elastic Bus mit dem Prozessortakt (1:4, DDR) bedeutet, dass der Systembus "automatisch" mit dem CPU-Takt skaliert. Natürlich sind diesem Wachstum irgendwo Grenzen gesetzt, aber ich denke die sind weit weg, zeitlich ebenso wie hinsichtliche des Taktes. Eine mögliche Lösung wäre dann die Verbreiterung des Busses ("mehr Bit!").

Diese kontinuierliche Steigerung des FSB stellt das Speicherinterface vor immer grössere Probleme, denen es ohne Innovation in diesem Bereich nicht wirklich gewachsen ist. Wir scheinen uns immer mehr einer "Quantenunschärfe" zu nähern, indem wir nur entweder Durchsatz oder Reaktionszeit haben können, scheinbar aber nicht beides! Was wir momentan tun können, ist die Breite des Speichers anzupassen an die der CPUs. Der G5 weist ein 128bit Speicherinterface auf, das sich aus 2 normalen DDR Kanälen zu je 64bit zusammensetzt. Das ist ein Vorteil, aber es ist vergleichsweise aufwändig 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 berücksichtigen müssen wie Hochfrequenzverhalten).





Aus dem Publikum höre ich "Rambus RAM", aber während ich den Ansatz (Optimierung auf Datendurchsatz pro Bit, sozusagen) für recht schlau halte, erhöht 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 für 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 für kontinuierlichen Datenfluss, "streaming", nicht aber für pseudo-zufällige Zugriffsmuster. Ein Cache kommt dem mit seiner Arbeitsweise entgegen, sodass es nicht unmöglich ist, dass wir diesen Lösungsansatz sogar einmal betrachten dürfen.

Derzeit ist DDR sicher der König 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 können, um zukünftigen schnelleren DDR-"Standards" Paroli bieten zu können, 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 aufwändiger werden. Damit nicht genug, werden uns je länger je mehr die Latenzzeiten bei MP Systemen Sorgen bereiten, und hier sieht die Sache eigentlich nicht so rosig aus.
Lösungsansätze gehen bisher davon aus, soviel L3 Cache "as you can" einzubauen (*wink wink), was doch ein Stückchen Leistungsfähigkeit bringt, aber ehrlich gesagt einfach die Unzulänglichkeiten "deckt". Klar ist, dass die kommenden IBM Hochleistungssysteme Level-3 Cache aufweisen werden.

Ein sehr positiver Nebeneffekt der Nähe des 970 zu der Power Serie ist nicht nur die stark verkürzte 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 unterstützen wird. eDRAM ist DRAM, das einen SRAM "Cache" vor die Nase gesetzt bekommen hat, um die am meisten angefragten Daten schneller liefern zu können. IBM bastelt derzeit an der dritten Generation der Chips. Entgegen der G4-Baureihe weist der Power970 (und auch der Power4) keine dedizierten L3-Cache Anschlüsse auf, sodass bei einer Implementierung eines weiteren Zwischenspeichers dieser via der Northbridge angebunden würde (wie beim Power4 der Fall). Wichtig ist, zu sehen, dass das eine gänzlich andere Topologie ist.

Während 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 würde - und damit diesen Controller nutzlos machen würde. Daher gehe ich eher von Dual Core Prozessoren aus, bevor wir das Speicherinterface auf dem Prozessor sehen.

Zum Schluss möchte ich noch ein kunterbuntes Paket mit diversen Infos schnüren.

Apple hat die G5 Systemarchitektur von Grund auf neu entwickelt, weil man dieses Mal nicht schon nach kurzer Zeit an irgendwelchen Limiten oder Missständen 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 unterstützen und vorallem Nutzen kann. Die Auslegung der Speicherbänke ist respektabel, man sieht auch in der PC Welt, dass es nicht einfach ist, Boards mit so vielen DDR Steckplätzen 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" ausgeführt, was auch vom Blockdiagramm des Rechners unterstützt wird. Die 100 MHz PCI Steckplätze 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 lächerlichen PCI-Verbindung zwischen den Chips ging das natürlich nicht!). Anscheinend wird 16-bit HT verwendet, um die nördliche Brücke mit dem PCI Tunnel zu verbinden, und nur noch 8bit HT weiter zur südlichen Brücke (der grosse Datenstrom ist ja nun abgezweigt). Wie eingangs erwähnt ist auch dieser Bus unidirektional, also gelten die Bit-Breiten wiederum pro Richtung. Leider habe ich immer noch nicht herausfinden können, mit welchen Frequenzen die Chips bzw. HT arbeiten.

Die Kühlung des ganzen G5 ist eine Sache für sich.

Wie an der Keynote kurz angerissen weist der G5 4 thermische Zonen auf, die mittels 9 Kleinventilatoren umgewälzt werden. Im Netzteilbereich laufen die 2 Lüfter mit konstanter Drehzahl, das Netzteil befindet sich am Gehäuseboden, ist proprietär und sehr dünn. Die Lüfter in den Laufwerksschächten hingegen regieren auf eine Feedbackschleife, die die Temperatur der austretenden Luft misst, während die AGP/PCI Zone ihre Konvektion basierend auf der Leistungsaufnahme(!) der PCI Karten regelt! Zu guter Letzt sei auf die Prozessorlüfter verwiesen, die ihre Drehzahl natürlich aufgrund der gemessenen Chiptemperatur des Power970 einstellen.

Viele Leute scheinen nicht zu verstehen, dass viele kleine Lüfter den Lärmpegel senken können (weil beispielsweise ein grosser Anteil des entstehenden Lärmes durch den Gegendruck der Luft entsteht), sodass die 2+2 Kombination (nennt man in der vorliegenden Anordnung "Push-Pull") den Lärm senken kann. Die beiden "ziehenden" CPU Lüfter arbeiten identisch, aber die "stossenden" sind von der jeweiligen CPU abhängig, die sie belüften. Bei den Single CPU Rechnern hat es demnach nur einen Lüfter, der schiebt, die beiden ziehenden bleiben.

Zu dem Kühlsystem - heutzutage ja eher ein "Anti-Lärm-System" - gehört 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, können den aber innert einer Millisekunde hochfahren (ohne dabei zu "stolpern": während 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-Lüfter sollen dem Vernehmen nach "gerade mal so ein bisschen drehen", wenn der Mac läuft aber nicht benutzt wird. Das Überwachungssystem der Lüfter wurde wohl dem XServe entnommen und es würde mich nicht wundern, wenn man diese Werte mit denselben oder ähnlichen Tools auslesen könnte. Auf der Hardware Seite ist der G5 vorbereitet, dem Benutzer mitzuteilen, dass ein Lüfter langsamer dreht, als es die ihm zugeführte Leistung erwarten liesse; es entzieht sich aber meiner Erkenntnis, ob OS X 10.2.7/10.3 dafür geeignete Mechanismen mitbringen wird.

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

Seit dem ominösen 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 führte - 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 wäre, was er ist, aber ich will Apple auch nicht die verdienten Lorbeeren stehlen. Bei Grössenordnungen wie bei denen, wo Apple bei IBM anklopft für 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 Blödsinn wie die Idee dass Jonathan Ive den G5 alleine gestylt hätte.

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 führende Chipschmiede trägt wieder einmal Früchte. Dieses mal aber - so scheint mir - sind die Früchte viel grösser, saftiger und süsser !




Im Bild zu sehen auf der rechten Seiten die Antennen-Stöpsel für BT und AP.

3. Juli 2003 | Mr.Mike (Dieser Artikel ist den Leuten gewidmet, die sich noch über Dinge freuen können).

Quellen:
- IBM Technology Group Customer Event 2003
- IBM Power970 Info Seite
- IBM PowerPC970 Dokumentation (soweit vorhanden)
- Ars Technica

Kommentare

Preliminary Developer Note ist raus

Von: Mr.Mike (MacGuardians) | Datum: 03.07.2003 | #1
Ich habe soeben erst entdeckt, dass die Hardware Developer Note für den G5 in einer Beta-Fassung raus ist (1.8MB):

[Link]

HIER gibt es ein echtes Bild zu sehen auf die Speichersteckplätze

geeky real geeky

Von: derdomi | Datum: 03.07.2003 | #2
feiner Artikel... ich hab zwar nicht mal die hälfte verstanden aber war trotzdem nett. Jetzt will ich das Teil aber endlich mal in Aktion sehen.

woha

Von: McNeely | Datum: 03.07.2003 | #3
wow, toller Artikel, habe zwar nix gerafft - fühle mich aber viel intelligenter! Feine Sache!

HyperTransport

Von: Mr.Mike (MacGuardians) | Datum: 03.07.2003 | #4
Zum Hypertransport Speed folgende Ergänzung:

HT kann mit Frequenzen zwischen 200 und 800 MHz arbeiten, jeweils in einem Vielfachen von 200. Die Technik arbeitet ja auch mit DDR sowie uni-direktional. Somit ergibt sich bei 800MHz und 16bit Breite pro Richtung 3.2GByte/s [800*2*2=3200] für ein aggregiertes Volumen von 6.4GB/s in beide Richtungen und gleichzeitig. Macht das Spass, hehe.

Leider habe ich auch rausgefunden, das der Power970 zwar 42bit breites Adressieren versteht, das API (Apple Processor Interface) aber nur 36bit breite Adressdaten verarbeiten kann. So what ?

Anmerkung aum RAM durchsatz

Von: Rüdiger Goetz | Datum: 03.07.2003 | #5
Hallo,

ICh dachte im ersten Moment auch, dass das DDR400-RAM schon jetzt ein Flaschhals ist.

Ich glaube aber, da irrt man etwas.

SDRAM (egal ob SDR oder DDR) braucht zun'chst eine große Zahl von (ca 4-6) Takten, bis sie zu liefern beginnen. Da dass ganze dann eh im L1/2-Cache landet. Macht man gleich einen sog. Burst von 4 oder 8 Takten (RAM-Takt) länge in denen 8 oder 16 Datenworte (bei Apple 128 bit breit aus zwei Kanälen). Dass macht (bei einem 4 Takte Burst und DDR-RAM) 1024 bit oder 128 Byte vom RAM zum Memorycontroller.

Der elastic Bus (z.B. bei 2GHz Modell) läuft mit 500 MHz (der RAM mit 200 Mhz). Das heist während eines Burst des RAMs schafft er 10 Takte, in denen er 20 Datenworte a 32 bit transportieren kann. Macht 640bit oder 80 Byte.

Upps, da hat jetzt das RAM mehr geliefert als der Elastic Bus wegschaffen kann. Gut das read und write entkoppelt sind, so kann der Rest des Datentransfers noch während der Latenz der nächsten angeforderten Address nachlaufen, wofür er 6 weitere Takte braucht, die 2.4 RAM-Takten entsprechen. (BTW beim 1.6 GHz Modell schafft der elastic Bus nur 8 Takte während der Burstphase des RAM und brüchte 4 weitere RAM-Taktre um aufzuholen.
Ein Grund warum das 1.6 GHz Modell nur DDR 333 hat ?)

Wenn nun die Latenz bei der nächetn angeforderten Addresse kleiner ist als dieser Wert kann es wohl knirschen.

Anders wird dies erst bei einem elastic Bus von 800 MHz und damit einer CPU mit 3.2 GHz.

Also scheint der Elastic Bus noch Luft zu haben, es sein denn, Apple integriert auf dem Borad noch schnellen L3-Cache, der dann zwischen RAM und elasatic Bus tritt und so diesen permanet füllt, auch während der Latenzen des RAMs.


Mit anderen Worten dank der Burst und der Latenzen des DDR-SDRAMs dreht der elastic Bus oft Däumchen, ist aber wenn Daten kommen bereuts überfordert, auch dank des 2 kanaligen RAM-Designs.

Bis dann

R"udiger

Sehr informativ!

Von: Ungethom | Datum: 03.07.2003 | #6
Der Headline habe ich nichts hinzuzufügen.

thyl

Von: flo (MacGuardians) | Datum: 03.07.2003 | #7
Laut dem c't Artikel setzt der Opteron HT mit 800MHz ein und kommt damit auf die vollen theoretischen 6,4 GB/s. Die c't schrieb allerdings (logischerweise) auch noch vor dem Erscheinen Developer Note und mutmaßte daher ein bisschen (wobei die im Mutmaßen meist rcht genau sind ;)

Ein Gefühl von

Von: Thyrfing | Datum: 03.07.2003 | #8
Erhabenheit trägt meine Sinne hinter den Horizont....Der erste Tech-Artikel, bei dem ich das Gefühl hatte überhaupt etwas zu verstehen (und Gefühle sind wichtig).
Mensch Mike, biddä imma one Konzzäppt!

Echt super Artikel!

Thyr

Huch...

Von: Maxefaxe | Datum: 03.07.2003 | #9
Wo bin ich denn hier gelandet? Beim Hardware-Nerds-Forum für Power-PCs?

Alle Achtung.

Genau :-D

Von: Thyrfing | Datum: 03.07.2003 | #10
rofl

DDR oder nicht DDR

Von: neo | Datum: 03.07.2003 | #11
Also ich suche immer noch die Angabe im TechDoc von Apple das der CPU bus DDR ist ... das einzige was ich immer lese ist 800,900,1000Mhz.

Ich kann es mir auch nicht Vorstellen das es kein DDr ist aber warum schreibt Apple das nicht hin ...

Gruss Neo

PS: Wenn ich es überlesen habe gibt mir mal die Seiten zahl .... ;)

G5 hat keinen FSB

Von: Maximilian Lein | Datum: 03.07.2003 | #12
Das Ding ist kein FSB, Front Side Bus, sondern eine Punkt-zu-Punkt-Verbindung. Intel hat noch einen FSB und nennt diesen auch so. Aber der G5 hat keinen.

@ Kai

Von: Rüdiger Goetz | Datum: 03.07.2003 | #13
Hallo,

Schon klar dass ein 2x unidirektionaler "Bus" anders zu bewerten ist als ein (etwa) doppelte so schneller bidirektionaler. Beide haben je nach Anwendung stärken und schwächen (Extrembespiel von du von einem grossen Speicherbereich die Checksumme bilden willst, geht es nur in die CPU und fats nicht raus.)

Mein Hauptpunkt war aber eher, dass durch das
unidirektionale Busdesign und den zweikanal RAM, das aktuelle RAM-Konzept noch bis 3 GHZ CPU-Takt puste hat, bevor es zu nennensewerten Einbussen kommen dürfte, da bis dahin dass RAM (sofern nicht andere Geräte zugreiffen ,AGP etc) genug Luft.

Bei Mr.Mike klang es ein wenig so, als wäre er der Meinung das RAM wäre immer noch die Bremse, weil es den Elastic Bus nicht füllen kann. Das RAM ist im Moment schneller als der Bus der (jeder) CPU. Bei zwei CPUs sieht es natürlch auch wieder anders aus.


Ein anderer interessanter Punkt ist mir aber noch aufgefallen. Um die Cachekonsistenz zu erhalten müssen die CPUs in einem Dualsystem miteinander kommunizieren. Bei alten Dual G4 hätten sie es zumindest direkt am Memorycontroller vorbei machen können.
Beim G5 muss diese Kommunikation immer über den Memorycontroiller gehen, zumindest jedoch über das Mainboard. Welche Auswirkungen das hat ist mir aber nicht ganz klar.

Bis dann

R"udiger

@Maximilian Lein

Von: neo | Datum: 03.07.2003 | #14
Naja eine Punkt zu Punkt Verbindung kann auch dann Bus heißen, wenn sie nur zwei Komunikationspartner erlaubt. Es muß nur Terminert sein und schon ist es Technisch gesehen ein Bus.

USB z.B. ist ja sonst streng genommen auch kein Bus, obwohl es so heist.

PCI-X ist ja auch nur eine Punkt zu Punkt Verbindung über einen Sockel(laut der Spez.).

Irgendwie wird der Begriff BUS heutzutage etwas missbraucht.

Gruss Neo

@neo

Von: Maximilian Lein | Datum: 03.07.2003 | #15
... aber nicht Front Side Bus. Bus schon. Vielleicht hätte ich das klarer herausstellen sollen.

DDR

Von: Netzmeister | Datum: 04.07.2003 | #16
die mauer ist doch aber schon seit jahren weg!!!???
echt n super-artikel, sehr aufschlussreich und interessant, muß ich gleich nochmal lesen um mehr zu verstehen...
eure seite macht echt laune auf G5 + G6

@Netzmeister ...

Von: neo | Datum: 04.07.2003 | #17
ich sag ja, nciht nur die Wessis Wurden Ossimiliert sondern die Ganze Erde - Wenn RAM schon so heist wie ein Komischer Ex Staat.

FSB oder nicht FSB, daß ist hier keine Frage!

Von: Patrick | Datum: 04.07.2003 | #18
Aus dem Technology Overview zum G5:

"To harness the power of the G5 processor, a 64-bit bidirectional Double Data Rate (DDR) frontside bus maximizes throughput between the processor and the rest of the system."

Somit sollte geklärt sein, daß Apple den Bus sehr wohl FSB und auch DDR nennt...

Ist der PowerMac G5 jetzt zu empfehlen oder nicht

Von: Alexy | Datum: 04.07.2003 | #19
Langer Beitrag, aber nichts verstanden.

Ich hab den PowerMac G4, und schon
verkauft, jetzt will ich mir den G5
holen. Ist der viel besser als G4?

Round Up

Von: Mr.Mike (MacGuardians) | Datum: 04.07.2003 | #20
- Frontside Bus: Strenggenommen richtig, zudem macht er *eigentlich* nur dann Sinn wenn es noch einen anderen gibt (Backside Cache Bus). Ich hab den Begriff für das verwendet, was einige Bus und andere Punktverbindung nennen.

- DDR RAM: Ich sehe R.Goetz argumentation, glaube aber dass sie nur gilt, wenn die Busse leer sind, und sonst niemand was im Rechner tut, ausser dass wir ein paar Bytes übertragen. Ich denke in der "real world" ist es dann nicht mehr so "schön" - aber wir werden das (hoffentlich) bald herausfinden können !

- Elastic Bus: Die oben aus der Dev.Note zitierte Stelle zeigt, wie Apple die Dinge etwas leger nimmt. Sie sprechen von einem bidirektionale 64bit DDR Bus, obschon es nach allem was wir wissen pro Prozessor 2 unidirektionale 32bit Busse sind. Elektrisch ist das ein riesenunterschied

- Wie will Apple eigentlich die 3 USB Ports zu je 480Mbit durch einen einzelnen PCI Bus versorgen (via der K2 "Southbridge")?

- Alexy: Kann man doch nicht so einfach sagen, aber ich denke man würde an den meisten Enden eine Steigerung im Bereich x2.. x5 erwarten können gegenüber einem mittleren (800) G4. Nicht bloss CPU Power, *alles* ..ausser Disk vielleicht. Ah und das Modem wird wohl auch ned schneller gell ;-)

Erste Sahne!!!

Von: maccy | Datum: 04.07.2003 | #21
Solche Artikel lassen einem das Herz aufgehen. Relativ leicht verständlich geschrieben und doch sehr viel Hintergrundinfos. Weiter so!

@Mr. Mike

Von: Patrick | Datum: 04.07.2003 | #22
Nur als Hinweis: die zitierte Stelle stammt nicht aus dem Developer Doc, sondern aus dem Technology Overview (Link hab ich leider nicht mehr), der wohl eher vom Marketing kommt...

@Mr Mike

Von: Rüdiger Goetz | Datum: 04.07.2003 | #23
Hallo,

Ich versteh deine Antwort nicht ganz. Ehm.
Du meinst, dass durch RAM-Zugriffe anderer
DMA-Geräte die Bandbreite des RAMs soweit "verbraucht" wird, dass es mit (ich sgas jetzt auch, wir wissen ja was wir meinen) FSB kein
Problem gibt. Dem wiederspricht aber, das der Transfer zum Cache (und alles was die CPU anfordert landet ja auch im Cache, sei es L1 oder L2 ) immer in Gruppen von 128 oder 256 Byte erfolgt, also ein 4 oder 8 Takte Burst. Bei diesem kommt aber der FSB nicht hinterher, sodass das nächste Lesen aus dem Speicher von einem andern DMA-Gerät kommen muss (oder eben gar nichts am RAM passiert). Das agnze kann dann aber auch nur funktionieren, wenn bereits heute der Memory-Controller eine Art Cache von etwa 1 KB hat (BTW: Der 68030 hatte AFAIK 256 Byte L1-Cache nur so zum Vergleich) aus dem er den FSB bedienen kann, wärend er ein anderes DMA-Gerät (was auch eine zwite CPU sein kann) mit Daten aus dem RAM-versorgt.

Insofern denke ich, dass das aktuelle RAM-System zumindest in Single-CPU Konfigurationen bis ca. 3 GHz reichen wird und erst danach Schwächen zeigt, da bis dahin immer genug Luft für andere DMA-geräte bleibt, während der FSB noch überträgt.

Und ich denke das gilt auch in "real world"

Bis dann

R"udiger

@ Rüdiger Götz

Von: Mr.Mike (MacGuardians) | Datum: 04.07.2003 | #24
Heh, mag sein, aber ich denke oberste Priorität hat der Kanal CPU<->RAM gefolgt von AGP<->RAM. Meine Idee war, dass diese beiden das RAM theoretisch bereits ausreizen könnten. Eine 2GHz CPU kann bei vielem AltiVec (zB SP Floating Point) das DDR überfordern weil selbiges nicht sustained die 6.4GB liefern kann sondern nur als peak. Für die Bursts trifft Deine Aussage meiner Meinung voll zu, ich habe einfach Zweifel *daran*: Eine stark Altivec-lastige App mit OpenGL Ausgabe (AGP), wobei beide CPUs involviert sind, würde doch das RAM bedrängen oder nicht ?

Aber es geht mir ausschliesslich um die Technik, nicht um das Beurteilen! Ich geh jetzt nochmal bisserl nachlesen über Caches und Latenzen, interessanterweise ist die Speicherlatenz des G5 fast 50% höher als die des G4, aber da hilft die gute BPU denk ich mal *ggg*

PS: Der 68020 war der mit den 256bytes "Cache", der 68030 hatte bereits 256 Bytes Daten *und* Instruktion Cache (*wow)

PowerPC 970

Von: Mr.Mike (MacGuardians) | Datum: 04.07.2003 | #25
Sowas ähnliches - bezogen auf den Artikel - hätte ich dann noch für den Prozessor an sich.

Poste das hier mal als kleinen "Bedarfs-Test"...