• OTR (Off the Record Messaging) Plugin for Apple’s iChat

Why OTR?

Because it provides privacy and authenticity of your chat communication by encryption.

Why an iChat Plugin

iChat is used by many people because it is a very comfortable application.

Why not use Adium instead? It already does support OTR.

Adium is not iChat. (Duh) I consider Adium a very nice and quite powerful chat client for a gazillion of protocols and even more settings. This complexity is too much for many users. i also consider the user interface of Adium inferior in regard to usability. I personally just prefer iChat over Adium because I feel more comfortable in using it.

There is an OTR Proxy that can be used with iChat

I consider myself sufficently nerdy and technically inclined to expect I can make this work. Yet I couldn’t. In addition to that it only works with AIM an not Jabber which makes it useless for anyone using Jabber, Gtalk, GMX Messenger, Facebook chat, or a private company Jabber account.

Any takers of that challenge? You may also want to contact Kent Sutherland to convince him, or even help with implementing OTR in his awesome Chax extension for iChat. According to his FAQ Kent is already evaluating to build this in. If you can help to make this happen, please do!

MP4 Videos

curl -s 'http://pipes.yahoo.com/pipes/pipe.run?_id=7688f1c3fdb544de90fe10ad93f2be00&_render=rss' | grep .torrent | grep -v title | grep -v application/x-bittorrent | sed -e 's/^.*http:\/\//http:\/\//g' -e 's/\.torrent.*/\.torrent/g' | uniq | while read url; do curl -LO -# -C - "{$url}" ; done

MP4 – iPhone/iPod touch

curl -s 'http://pipes.yahoo.com/pipes/pipe.run?_id=ff2eaf37014c59765259758c228e3919&_render=rss' | grep .torrent | grep -v title | grep -v application/x-bittorrent | sed -e 's/^.*http:\/\//http:\/\//g' -e 's/\.torrent.*/\.torrent/g' | uniq | while read url; do curl -LO -# -C - "{$url}" ; done

MP3

curl -s 'http://pipes.yahoo.com/pipes/pipe.run?_id=957eb6a061c7d297eb91669d782c3b7e&_render=rss' | grep .torrent | grep -v title | grep -v application/x-bittorrent | sed -e 's/^.*http:\/\//http:\/\//g' -e 's/\.torrent.*/\.torrent/g' | uniq | while read url; do curl -LO -# -C - "{$url}" ; done

OGG

curl -s 'http://pipes.yahoo.com/pipes/pipe.run?_id=de9d44596ea0ad51e35a2500ca56672e&_render=rss' | grep .torrent | grep -v title | grep -v application/x-bittorrent | sed -e 's/^.*http:\/\//http:\/\//g' -e 's/\.torrent.*/\.torrent/g' | uniq | while read url; do curl -LO -# -C - "{$url}" ; done

Alle Video Torrents auf einmal

curl -s 'http://pipes.yahoo.com/pipes/pipe.run?_id=7688f1c3fdb544de90fe10ad93f2be00&_render=rss' 'http://pipes.yahoo.com/pipes/pipe.run?_id=ff2eaf37014c59765259758c228e3919&_render=rss' 'http://pipes.yahoo.com/pipes/pipe.run?_id=957eb6a061c7d297eb91669d782c3b7e&_render=rss' 'http://pipes.yahoo.com/pipes/pipe.run?_id=de9d44596ea0ad51e35a2500ca56672e&_render=rss' | grep .torrent | grep -v title | grep -v application/x-bittorrent | sed -e 's/^.*http:\/\//http:\/\//g' -e 's/\.torrent.*/\.torrent/g' | uniq | while read url; do curl -LO -# -C - "{$url}" ; done

set term=builtin_ansi
syntax on


Wenn man das nächste Mal eine Datei mit Objective-C Quellcode, XHTML, CSS oder die httpd.conf öffnet, dann ist auf einmal alles so bunt hier. Das verhindert zwar nicht, daß man Fehler macht, aber wenigstens sehen sie nett aus.

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&oumlsungsansatz 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&auuml;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 !

3. Juli 2003 | Mr.Mike

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