Ob das Corning etwas bringt?
Alle sehen die Schnittstelle kritisch...

Nein, das tun nicht "alle". Es gibt jede Menge Aufbauten, die benutzen sie einfach.

Diese Kabel sind ja auch nicht für den einfachen Benutzer, sondern eher für große unternehmen und Server.
Wer sonst braucht ein recht teures 100 Meter langes Kabel, dass nur Daten übertragen kann.

…

Die Information ist: bis zu 100 m. Also auch andere Längen.

…

Ich hatte bereits in Rewind 366 ein optisches Thunderbolt-Kabel von Delock im Test, das ebenfalls bis 100 m Länge zu haben ist. Die Preise für dieses Kabel gehen leider schnell in den vierstelligen Bereich.

Na jeder der Peripherie weiter weg aufstellen möchte, im Keller oder unter dem Dach zum Beispiel. Da kommst du locker auf 50 Meter. Das sind ja schon über 5 Meter wenn du nur an die andere Zimmerseite willst. Und was heißt da "nur" Daten übertragen? Was willst du denn noch übertragen? Willst du deinen Kaffee durch das Kabel schicken? Ein CAT-Kabel überträgt auch nur Daten.

Ehrlich, einfach mal etwas weiter denken…

Wäre Thunderbold nicht so eine überteuerte Totgeburt, könnte man damit nette Dinge anstellen.

Das ist halt meine frage: totgeburt (für den normalo sieht es so aus) oder wird das corning kohle einbringen... ?

MacGayEntweder haben die bei Corning eine Monstermarge auf die Kabel (eher unwahrscheinlich) oder die sehen das einfach als Werbemassnahme im Profi-Segement. Bei einem weltweiten Markt von vielleicht 1000 Kabeln pro Jahr (wenn überhaupt) ist sicher nicht die grosse Kohle zu machen.

biegeradius in grad ???

Solche Produkte richten sich offensichtlich nicht an den Normalo.

Ja, er hat ohne zu denken einfach den fehlerhaften Pressetext übernommen. Sowas passiert bei schlechten Journalisten recht häufig.

Als Fresenius und sein Sohn verunglückten, hat die Weltpresse auch den fehlerhaften Agenturtext übernommen und von einer zweimotorigen Mooney gesprochen. Dabei hat Mooney nie zweimotorige Flugzeuge gebaut.

Und so was sieht man ziemlich oft in der Medienlandschaft.

Benutze TB täglich im Audiobereich, kann 100% sagen: bessere Schnittstelle gab es noch nie.

100m sind bei optischen Kabel nicht sonderlich viel. Bei 10GbE ist über OM3 Fasern 300m und über OM4 Fasern 400m zertifziert. Über OS2 Fasern sind problemlos 30km möglich. Mit stärkeren Transceiver bzw. Boostern geht rein optisch noch deutlich mehr.
PoE ist ein Begriff? PoE = Power over Ethernet

Oh nein! Die Meute stellt fest, dass ThunderBolt ein P R O F I - Feature ist.
Das kann nicht sein, das darf nicht sein! Apple macht doch gar nichts für Profis mehr! Schnell, zuhilf!

Kann nicht mal jemand den Forstall zurückholen? Der Skeuomorphisiert das dann weg, oder lasst es wenigsten Johnny Ive iOS 7 like "plattmachen". Oder wenigstens Craig F. soll seine Haartolle draufhämmern (Hadbangers FTW undso) … Hach nein, lasst einfach Phil Schiller alle Knöpfchen drücken, dann wirds schon explodieren und weg gehen …

* mit bösem gelächter in der mit "Paranoia-Notausgang" beschrifteten Falltüre verschwindend *
(und die Falltüre knarzt beim zuschlagen sanft: Hab ichs nicht gesagt …)

Ich frage mich vor allem, was man daran anschließen soll, erst recht über diese Distanz. Wg. dem hohen Datendurchsatz machen ja nur Geräte wie Monitore und Storage Sinn. Ersteres kann ich über DisplayPort usw. anschließen, wenn ich Distanzen für Public Displays brauche gibt es Splitter und Extender.
Storage binde ich in Netz (sei es 1/10 GBit, FC oder IB) ein, brauche ich das auch nicht für.
Drucker/Scanner machen mangels Durchsatz keinen Sinn, bzw. wenn es große Maschinen für Volumen sind sind die auch im Netz, schließlich sollen dann i. d. R. ganze Arbeitsgruppen drauf zugriefen.
TB ist aus meiner Sicht für Privat zu teuer und für Profis fehlen die Anwendungen.

Seit 10.9 gibt es "IP over Thunderbolt". Zwischen zwei absoluten Gurken kriegt man damit und mit einem 30,- € Kabel den Durchsatz, den man sonst von 10 Gbit Ethernet gewohnt ist (hier zwischen einem Mini und einem MacBook Air, beide aus 2011: um die 800 MByte/sek, also das Achtfache von dem, was mit Onboard-Ethernet möglich ist).

Da Apple offensichtlich mehrere TB-Anschlüsse unter 10.9 zu einer Bridge zusammenfaßt (jedenfalls kann man das ab 10.9 ganz generell, d.h. simpel per GUI Bridges aus verschiedenen Netzwerk-Schnittstellen erstellen lassen), kann man ab 10.9 mit Macs, die mehr als eine TB-Schnittstelle haben, relativ simpel hochperformante Mesh-Netzwerke aufbauen. Da Apple bei IP-over-TB bis auf Layer 2 herunter zu Ethernet kompatibel ist (identisches Frameformat und MTU 1500 Byte) kann man so ein Hochgeschwindigkeits-Mesh-Netzwerk an irgendeiner Stelle ganz simpel ins normale LAN oder WLAN übergehen lassen.

Problem aktuell: Für den Zweck eigentlich zu kurze Kabel. Und da gibt es jetzt eben Abhilfe. Die hat ihren Preis (für 10m werden wohl um die 300,- € abgerufen, für 30m will Sumitomo dann schon über 600,- aber das ist im Vergleich zu anderen Technologien immer noch günstig.

Nen neuen MacPro mit ordentlich TB-Storage dran und an jedem TB-Anschluß noch per "IP over Thunderbolt" einen "Power-Client" (und ggf. dahinter per Bridging dann einen normalen Ethernet-Switch mit weiteren Clients oder abermals per IP-over-TB weitere Clients). Da kannst Du für 'nen Bruchteil des Geldes Szenarien abfeiern, für die Du früher ein teures SAN oder 10 GbE-Infrastruktur gebraucht hast.

Naja, 10GBase-T wird auch immer billiger und es gibt mittlerweile eine Reihe von Systemen, die 10GBase-T onboard haben, Apple hätte hier eine Vorreiterrolle beim neuen MacPro einnehmen können. Ferner gibt es bereits kleinere 10GBase-T-Switche für unter 1000,- EUR. Es muß ja nicht ein nonblocking 10GbE-ToR-Switch sein.

Haben sie aber nicht. Anstatt alter Wein in neuen Schläuchen (bzw. Anachronismen deluxe: Ethernet, das für ein gemeinsames Kabel entwickelt wurde mit Mechanismen wie CSMA/CD auf völlig unterschiedlichen Topologien, die inzwischen Faktor 1000 oder mehr schneller sind, abzubilden) halt was Neues.

Der neue MacPro hat 6 Thunderbolt 2 Ports. Das ist grob gesagt das Äquivalent zu 12 10 GbE Ports. Da "IP over Thunderbolt" nun auch eine "Thunderbolt native"-Implementierung ist (und nicht huckepack PCIe transportiert wird), fällt das Verhältnis Durchsatz/Last besser aus (und das, obwohl Apple bei TB-over-IP nur die Standard-MTU zuläßt, siehe )

Da der Kram Framekompatibel zu dem ollen Ethernet-Schraddel ist, funktioniert auch ein Bridging zwischen Thunderbolt und [W]LAN problemlos (grad ausprobiert). Hmm... mich hat ja der neue MacPro bis gestern so gut wie gar nicht interessiert. Aber ich glaub, ich muß jetzt mal bei den Kunden rumhorchen, wer vorhat, im Dezember davon einige zu shoppen, um die Erlaubnis für ein Testlab zu bekommen (und dann gucken wie effizient der Bridging-Code dann wirklich ist, wenn man an 'nem MacPro per TB2 mehrere Clients per TB2 und IP-over-TB dranhängen hat, und was dann an Durchsatz und Latenzen angesagt ist).

Klar, 10GBase-T wird günstiger, bezahlbare Switches (sogar mit zus. SFP+ Ports) tauchen langsam auf. Aber identischen Durchsatz bei weniger Last für ein 30,- EUR Kabel? OK, Themaverfehlung, wir reden hier ja grad über die noch affig teuren optischen Kabel

Aktuelle ToR 10GbE Switche liegen bei 250ns Latenz. Die sind zwar teuer, aber sie haben deutlich mehr Ports, so daß der Preis pro Port deutlich unter einem Mac als Switch liegt. Ich bezweifle, daß ein Mac als Switch-Ersatz mit ASICs in einem Switch mithalten kann.

Dazu machen die meisten 10GbE und 40GbE Karten RDMA und Offloading. D.h. die CPU muß Prüfsummen gar nicht mehr berechnen, das macht die Karte selbst. Dadurch steigt die Transferrate deutlich an, und die CPU Last sinkt ab. Bei TB muß das ganze Protokoll von der CPU gestemmt werden, da TB von IP nichts weiß, nur der DMA-Transfer wird durch die Hardware durchgeführt.

Falls noch wer anders mitlesen sollte: ToR bedeutet

Ich glaub, wir reden aneinander vorbei. Ich sehe Macs nicht als Switch-Ersatz und mein Fokus ist auch nicht HPC oder Rechenzentren (ich wüsste auch nicht, wo man im Mac-Umfeld in freier Wildbahn sowas wie RDMA finden würde). Ich find das Thema in mehrerlei Hinsicht spannend:

a) Alte Zöpfe abschneiden. Ethernet ist ein häßlicher Anachronismus. Die Crux der Abwärts-/Rückwärts-Kompatibilität läßt sich zwar durch die von Dir genannten Verfahren kaschieren (befreit dabei die Host-CPUs, verbrunzt aber nichtsdestotrotz an anderer Stelle massiv Energie, denn irgendein Trumm Hardware muß haltnunmal den ganzen Kram erledigen) ändert aber nix dran, dass die Ethernet zugrundeliegenden Mechanismen aus dem IT-Paläozoikum stammen als Netzwerke Faktor 1000 langsamer waren. Thunderbolt (mal nicht als Huckepack-Dingens für PCIe und DIsplayPort betrachtet sondern "nativ") setzt hier ganz woanders an und startet gerade erst.

b) Einführung einer neuen Technologie: Den Kram in käufliche Hardware gegossen gibt's jetzt seit 2,5 Jahren. Und jetzt erst kommt Apple mit einer über "Huckepack" (DP, PCIe am Kabel) hinausgehenden Funktionalität ums Eck. Warum? Keine Ahnung -- aber Vermutung, dass sie einfach warten wollten, bis ausreichend Durchdringung mit TB-Hardware "draußen" da ist, um dem Ganzen keine schlechten Start aufgrund schlechter Nutzbarkeit zu bescheren. Dito die aktuelle Beschränkung von IP-over-TB auf Ethernet-Kompatibilität bis hinab zum Frameformat und Steinzeit-MTU. Man könnte an der Stelle die Technik viel mehr ausreizen, würde dann aber die Kompatibilität minimieren. Und ich vermute, dass sie genau das vermeiden wollen. Jedenfalls funktioniert ein Bridging zwischen [W]LAN und TB depperltauglich simpel

c) wenn ich Mitte 2014 in irgendeiner Medienklitsche was Neues aufsetzen müsste, würde ich schon sehr genau evaluieren, ob es nicht eine Option ist, so 'nen neuen MacPro als Server, an dem -- ggf. an 'nem längeren optischen Kabel irgendwo weggesperrt -- ein oder mehrere Areca ARC-8050 hängen, direkt zwischen die Power-User zu stellen, die drumherum per Standard-TB-Kabel per LAN angebunden sind. Und den Rest der Firma dahinter (also bspw. die "Power-Clients" dito als Bridges und an denen dann Switches zum Rest des Ladens). Das ist auf den ersten Blick 'ne recht kranke Konstellation (mit Workstations als Multi-Port-Bridges) aber könnte mehr Performance bei einem Bruchteil des Preises von althergebrachten Lösungen bedeuten (FC-SAN, 10 GbE)

Letztlich war's das eh mit PCIe-Erweiterungen in Macs (und all dem "Legacy"-Kram, der drauf aufsetzt). Es gibt keine Kiste mehr (zu kaufen), die das kann. Mal schauen, wo das hinführt. Bin inzwischen echt gespannt auf den neuen MacPro und wie der sich anstellt, wenn man ihn an der Stelle richtig quält

Der Verweis auf RDMA bei 10GbE gab's von mir deshalb, weil viele meinen TB sei hier schneller, weil es ja DMA könnte. Es herrscht in dieser Hinsicht Gleichstand.
Wir haben auch Infiniband im Einsatz, und weil der IB Port schneller ist als die GbE Ports fahren wir auch IPoIB (IP over Infiniband) darüber, IPoIB erlaubt es ganz normale APIs zu nutzen für *I*X also Sockets. Für IB muß man eine ganz andere API nutzen, und weil diese nicht normiert ist, gibt es bei Mellanox und QLogic unterschiedliche APIs! Ganz häßlich ist es, daß man eben nicht auf System A die eine und auf System B die andere API für eine gemeinsame Kommunikation nutzen kann. Man muß dann einen Emulator auf einer der beiden Systeme nutzen.

Wenn mir jemand die Wahl läßt ist 40GbE mein Favorit. Die Latenzen im Netz sind mittlerweile vergleichbar und man hat deutlich weniger Ärger. Im HPC Umfeld ergibt IB noch einen gewissen Sinn, aber außerhalb sollte man es eher nicht verwenden.
TB ist aber keine Netzwerkschnittstelle sondern eine Erweiterungsschnittstelle. Wenn man es zum Vernetzen nutzen will, muß man den ganzen Netzwerkkrempel in Software realisieren. Das war einmal bei IB ebenfalls der Fall, und entsprechend schlecht war die Performance. Die neuen ASICs von Mellanox machen den ganzen Kram nicht ohne Grund in Hardware.
Apple interessiert in diesem Kontext niemanden. Alles rund um TB stammt von Intel, und Intel will 2014 eine neue HPC Netzwerktechnik anbieten, dafür hatten sie auch QLogic gekauft. Mal sehen was das sein wird.
Die RAIDs sind durch TB lahm. Bei TB ca. 1GByte/s mit TB2 ca. 2GByte/s als Obergrenze. Damit lockt man niemanden hinterm Ofen hervor. Normalerweise würde man so etwas (ggf. mit weiteren RAID Controllern und JBODs) ins Rack montieren. Passender Switch dazu und die Clients mit 10GbE angeschlossen. Die LSI 2208 Controller machen an PCIe 2.0 x8 3,5GByte/s und limitieren so durch die Schnittstelle. Zudem ist meine Begeisterung bei Areca nahe am absoluten Nullpunkt.
Ein SAN braucht man nur bei großen Installationen, sonst ist im Grunde immer ein normaler Fileserver mit interner RAID Karte deutlich günstiger. Die von Dir angedachte Bastellösung hat auch das Problem, daß die einzelnen RAIDs nicht als ein Volume zur Verfügung stehen. Somit erlaubt es meines Wissens OSX nicht die verschiedenen RAIDs per LVM zu einem virtuellen RAID zusammen zu legen. D.h. man hat keinen Vorteil von Deinem Aufbau, weil man immer das Mapping 1:1 von einem RAID zu einem Client machen muß. Ok, man kann die Daten austauschen, aber das kann man auch, wenn alle Systeme ihre lokalen RAIDs exportieren.

Inzwischen bin ich davon sogar fest überzeugt

Och, ich glaub, v.a. Intel hat(te) im Kontext Thunderbolt ein großes Interesse an Apple. Um das Henne/Ei-Problem zu lösen, dass kein 3rd-Party-Hersteller Zeugs für eine Schnittstelle entwickelt, die von niemand genutzt wird, weil bekanntlich niemand Interesse an einer Schnittstelle hat, für die es keine Peripherie gibt...

Apple hat -- in gewissem Maße wie damals bei USB auf dem Rücken der Mac-Anwender -- für die Verbreitung gesorgt. Und vielleicht schafft Thunderbolt es ja sogar noch aus der Nische -- für manche Drittanbieter ist wohl die kritische Masse an Durchdringung erreicht. Aber völlig klar: das verfügbare Peripherie-Angebot ist nach wie vor mau und meist häßlich überteuert.

Nur... grad mit so einer "neuartigen" Nutzung wie jetzt IP over Thunderbolt kehrt sich das in manchen Bereichen komplett um: Ich krieg mit 'nem billigen Kabel über kurze Distanzen Netzwerk-Geschwindigkeiten, für die ich bis eben noch heftig in die Tasche greifen musste (10 GbE). Der Fokus ist dabei weder HPC noch überhaupt Rechenzentrum sondern "Kisten mal schnell eben" vernetzen.

Und das funktioniert -- Apple-typisch -- einfach so und in einer Art und Weise, dass es der sprichwörtliche DAU hinbekommt, dessen größte Hürde die nötige Feinmotorik darstellt, zwei Mavericks-Kisten unfallfrei mit einem Thunderbolt-Kabel zu verbinden. Der Rest (Anlegen des Interfaces, Einrichten eines Bridge-Devices, Zuweisen von link-local-Adressen und Annoncierung der Dienste der beteiligten Kisten per Bonjour) funktioniert einfach so.

Wenn dann noch ein Admin oder irgendwer mit rudimentären Netzwerk-Kenntnissen am Start ist, dann kann der 'ne kleine Herde Mavericks-Kisten, die eh immer durchlaufen (das trifft auf die Macs der Motion-Abteilungen bei einigen Kunden zu -- und das sind auch die mit den höchsten Bandbreiten-Anforderungen) simpel hochperformant vernetzen und diesen "Mesh-Verbund" durch bewusstes Anlegen einer Bridge Richtung Ethernet auf einem Mac mit dem restlichen LAN verbinden.

Wohlgemerkt: Der Fokus liegt da garantiert nicht auf HPC, RZ oder "echten" Servern sondern auf kleinen Arbeitsgruppen. Und das ist wohl der Grund, warum wir hier auch so schön aneinander vorbeischreiben

Ansonsten noch zur Info: SAN und "FC to the desk" war bis vor Kurzem in manchen Branchen (Motion/Editing) noch Standard. Einfach weil 10 GbE noch unrentabel bzw. im Mac-Umfeld zu ineffizient war.

Und man kann schon immer (also mindestens seit 10 Jahren bzw. MacOS X 10.2) beliebige Disk-Devices einfach zusammenfassen, so dass sie logisch als eines erscheinen (ganz simpel per GUI unter dem fehlleitenden Begriff "RAID", siehe ). Nur: Das will man nicht (zumindest ich). Weil HFS+ einfach nicht robust genug ist. Aber für ein temporäres Arbeits-Volume, auf dem die Motion-Leute verteilt rendernd ihre Arbeitsergebnisse abwerfen können, taugt es natürlich (und nein, 1 oder 2 GByte/sek sind für dieses Szenarium nicht zu langsam sondern völlig ausreichend).

Die 1-2GByte/s müssen pro Nutzer zur Verfügung gestellt werden. Der Storage muß natürlich schneller sein, so daß für jeden Nutzer die Datenrate garantiert werden kann. Unter Umständen kann man hier mit einer mittleren effektiven Datenrate unterhalb des Maximalbedarfs für alle Nutzer leben. Aber das erreicht man nur, wenn man hinreichend viele Nutzern auf dem Storage zusammenfassen kann. Mit nonblocking ToR Switchen und ClusterFS funktioniert das reibungslos und man braucht kein SAN.

Ich sehe nicht, wie man das mit einem MacPro erreichen kann. IPoTB ist zwar nett, aber momentan nur dann attraktiv, wenn man es zum Datenabgleich zwischen zwei Macs einsetzt. Genau dafür gab es schon IPoFW, und das war auch wenig erfolgreich. Schaut man sich die Zahl der Ports am neuen MacPro an, dann hat man genau sechs Ports. Nach der Regel rein=raus kann man so drei Computer mit drei RAIDs verbinden. Ob der Pro noch zu etwas anderes genutzt werden kann ist ein anderes Thema. Diese Bastellösungen werden doch nur angeschnitten, weil Apple keine kostengünstige Lösung erlaubt 10GbE oder schneller an in einen Mac zu integrieren. Die Kartenauswahl für den alten MacPro war schon sehr schlecht. Man kann nur hoffen, daß die Auswahl an 10GbE Adapter für TB zu nehmen wird, wo nun auch andere Computer Anbieter TB in ihren Notebooks anbieten. 10GBase-T NICs verbrauchen zu viel Strom für den Einsatz in Notebooks.

Hä? Nein, warum? Die Zahl kommt von Dir und Du hast sie wohl den mit TB möglichen Maximalwerten abgeleitet. Ich sprech die ganze Zeit noch von der Praxis und da _weiß_ ich halt nunmal, was die Render-Clients brauchen. Und das liegt weit unter diesen "1-2 GByte/s".

Den Vergleich mit IP over Firewire versteh ich auch nicht (denn das war aufgrund des niedrigen Durchsatzes nur in ganz wenigen Situationen die bessere Wahl verglichen mit GBit-Ethernet. Aber IP over Thunderbolt spielt da in 'ner ganz anderen Liga)

Und schließlich zur Topologie und "rein = raus". In dem von mir angedachten Bastelszenarium spielt der MacPro natürlich Fileserver (per SMB2), d.h. shared die RAIDs, die an ihm dranhängen (sonst wäre das Ganze ja Blödsinn und jeder der Clients kann gleich lokalen Storage nutzen). RAIDs und Clients können natürlich an einem TB-Port hängen (Daisy-Chaining auf der physischen TB-Ebene). Das ist unter dem Gesichtspunkt des Datenflusses zwar totaler Quatsch (weil ein Client am Ende des Kabels den MacPro am anderen Ende zwingen würde, die Daten vom dazwischenhängenden RAID erstmal via Blockstorage zu sich zu verfrachten, um sie dann in andere Richtung und wieder am RAID vorbei per SMB2 auszuliefern. Und vice versa). Aber es funktioniert vermutlich ab TB2-Ports mit Durchsatzraten irgendwo oberhalb 300 MByte/sek und ist daher dem "Grundsatz der Verhältnismäßigkeit" gemäß eine Option mit exzellentem Preis-/Leistungsverhältnis.

Die Szenarien, von denen wir hier schreiben, differieren so stark, dass es wohl müßig ist, das weiter zu vertiefen. Ich find das Thema für solche "kleinen" Lösungen grad extrem spannend, werd aber noch das Aufschlagen der neuen MacPro und erste Tests abwarten, bevor ich die Gedanken weiterspinne

Wenn das weit unter 1GByte/s liegt, dann braucht man auch kaum TB für die Vernetzung. Aber spielen wir das trotzdem mal durch.

Dann hat man an einem Port des MP ein RAID mit maximal 2GByte/s Durchsatz. Bei 5 Clients sind das max. 400MB/s. Naja, das schafft auch ein QuadPort NIC, TB oder TB2 sowieso. DualPort NICs sind bei den meisten Server und Workstation Lösungen als Standard am Board verfügbar. Wenn man davon ausgeht, daß man bei TB2 noch immer wie bei TB zwei unabhängige 10GBit/s Kanäle haben kann, dann ließen sich maximal 10 Computer anschließen. Das reduziert die Bandbreite auf 200MB/s = Dual GbE Speed. Ist das RAID langsamer wird die ganze Sache vollends sinnfrei, dann kann man gleich ein GbE Netz benutzen.
Da rollen sich mir die Fußnägel hoch. Günstig ist ja ok, aber das ganze soll auch brauchbar funktionieren.

Bei einer PC Installation würde ich das definitiv nie so machen. Dann nimmt man halt Systeme mit DualNIC onboard, einem passenden nonblocking GbE Switch, einen Rack Fileserver mit RAID Controller und hinreichend vielen Platten und schließt diesen nonblocking an den GbE Switch an. Es gibt GbE Switche mit 4x10GbE Uplinks. Das ruft nach einer 40GbE Karte. Dann hast Du an den Clients garantierte 200MB/s, mit Macs mangels zusätzlicher Ports wären es nur 100MB/s.

Hä? Ich rede übrigens die ganze Zeit von Praxis. Da ist es nicht so, dass alle Clients permanent nur Daten durchs LAN schieben sondern die rödeln mal überwiegend lokal herum, laden/schreiben ab und zu Daten aus dem LAN und überwiegend sind sie idle. D.h. eine Versoundsovielfachung des Netzwerkdurchsatzes um den Faktor x kommt beim Client fast gar nicht an. Nur die gefühlte Geschwindigkeit, wenn es um LAN-Traffic geht, steigert sich merklich.

Was anderes ist das bei konkreten Renderjobs. Da wird Footage-Material teils in erheblicher Menge geladen, dann eine Szene gerendert (null LAN, bisserl lokaler I/O, 100% CPU) und dann wird die Szene wieder weggeschrieben (idealerweise auf einen Shared Storage, denn am Ende müssen alle Szenen/Kacheln, die auf irgendwelchen Rendermaschinen gerechnet wurden, ja noch zu einem Film zusammengefügt werden) und dann der Kram für den nächsten Job geladen.

An der Stelle a) schnellen Zugriff auf das Footage-Material zu haben und b) die Szenen rasch wegschreiben zu können, ist von Vorteil und macht sich meßbar in einer Steigerung der Gesamtleistung eines Render-Clusters bemerkbar. Früher hat hier kein Weg an einem SAN vorbeigeführt, 'ne Zeit lang hat man das dann mit 10 GbE gemacht. Und jetzt kommt dafür auch evtl. TB in Frage.

Unter der frei an den Haaren herbeigezogenen Annahme, dass die Clients alle nichts anderes machen als rund um die Uhr und alle parallel nur Daten durchs Netz schieben. Hinweis aus der Praxis: Dem ist nicht so. Die Zugriffe (schreibend/lesend) finden versetzt statt und daher würden sich in Deinem Szenarium 5 Clients problemlos mit dem über 10 Gbps-TB Maximum, ca. 800 MB/sek, bedienen können.

Hmm... erklär mir bitte, inwiefern mir LAG in einer one-to-one-Situation (ein Client greift auf einen Server zu) helfen sollen? Quad-Port-NIC in Client und Server, jeder Link kann 1 GBit/sek. Wie krieg ich zwischen diesen beiden Kisten über ein stinknormales Filesharing-Protokoll wie AFP oder SMB mehr als diese 1 GBit/sek.

Hä? Bei Thunderbolt liegen auf einem Kabel 2 unabhängige 10 Gbps-Channel an. Der Host-Controller entscheidet, wie er TB-Paketchen auf die einzelnen Channel verteilt und die TB-Controller in per Daisy-Chaining angeschlossenen TB-Devices am Kabel können dann ihrerseits wieder Entscheidungen treffen, wie sie die auf einem Channel anliegenden Daten routen (wenn bspw. direkt ein Thunderbolt-Display angeschlossen ist, hinter dem noch ein zweites DisplayPort-Display angeschlossen ist, und an dem ein Firewire-Device hängt, dann ist die Sache klar, weil einer der Channel für den DP-Modus verwendet wird, d.h. direkt von der GPU DisplayPort generiert und vom Thunderbolt-Display einfach durchgeschleift wird. Display-Daten für das Thunderbolt-Display und verpackte Firewire-Signale müssen dann über den anderen Channel laufen. Ist kein DisplayPort-Device irgendwo in der Chain, dann kann der Host-Controller die Daten einigermaßen frei auf die beiden Channel verteilen -- soweit mein Wissenstand, kann aber auch sein, dass ich das falsch verstanden habe)

Mit TB2 hat sich jetzt an der ganzen Chose nur geändert, dass die neuen Controller (Falcon Ridge) nun schneller sind und ihre 10 Gbps-Limitation verloren haben. Aus zwei unabhängigen Channeln à 10 Gbps je Kabel wird jetzt ein einziger mit 20 Gbps. Der Gesamtdurchsatz pro Kabel bleibt. Aber für eine dedizierte Anwendung (sei's TB und darauf Aufbauendes oder sei's DP Stichwort 4K-Displays in Reihe) hat's jetzt den doppelten Durchsatz. So zumindest verstehe ich Intel:

Scusa, ich verstehe diese Rechnungen nicht.

Inwiefern bringen mir 2 GBit-NICs in einem Rechner was, wenn ich zu einem Server mehr als 100 MByte/sek haben will?

Und dann verstehe ich das Gesamtmodell nicht. Mein Modell sieht wie folgt aus (basierend auf der Annahme, dass die Render-Software an sich und die benutzten Engines, also After Effects und Cinema4D überhaupt schon oder in absehbarer Zeit unter Mavericks laufen):

Die Render-Leutchen hocken beim Kunden verteilt auf 2 Räume. Die LAN-Infrastruktur ist trotz Neubau durch den IT-Dienstleister völlig verbockt worden (2012 aufgesetzt und kein 10 GbE vorgesehen, Anbindung Richtung aller Server über EtherChannel, die -- zumindest nach meinem Wissenstand -- für die Verbindung zwischen genau zwei einzelnen Maschinen nicht mehr als Single-Link-Speed hergeben).

Wenn ich dort in jeden der beiden Räume in die Mitte 'nen MacPro stelle, an einen der MacPro ein oder zwei RAIDs (die 600-800 MB/sek bringen), die MacPro untereinander mit 'nem optischen TB-Kabel verbinde (weil elektrisch aufgrund Länge nicht mehr reicht) und ansonsten alle sonstigen TB-Ports der MacPro mit Clients vollstopfe, dann hab ich

a) einen schnellen Zwischenspeicher für Footage und Render-Material

b) je Raum einen Render-Server (die MacPro eben)

c) ein schnelles Mesh-Netzwerk mit Geschwindigkeiten im Bereich von 10 GbE zum Preis von paar Kabeln

Und natürlich kann ich an einen TB-Port des MacPro ein RAID anschließen und dahinter einen Client:

MacPro <- RAID <- Client

Wenn ich dann vom Client aus auf Daten des RAID zugreifen will, nehmen die zwar einen denkbar doofen Weg (denn das Netzwerkprotokoll wird von den TB-Ports des RAIDs durchgeroutet, der MacPro spielt den Fileserver und zuzelt die Daten vom RAID als Block-Device, d.h. letztlich passieren Daten auf dem Weg vom Client zum RAID zweimal den MacPro und zweimal das RAID). Aber was soll's? Wenn das RAID 600-800 MB/sek hergibt, dann kommen bei dem Client noch mindestens 500 - 700 MB/sek an (außer ein TB1-Controller routet die TB-Packerl doof über identischen Channel. Aber selbst dann ist das noch ein echter Fortschritt zum Status Quo. Und das für einen kleinen Preis)

Nochmal: Wie stellst Du es an, dass ein System mit DualNIC beim Zugriff auf einen Server über typischen LAN-Protokolle mehr als Single-Link-Speed erreicht? Oder spielst Du gar nicht auf klassisches Trunking/Bonding/LAG an? Weil:

Was für "garantierte" Geschwindigkeit soll das denn sein? Von welchem Szenarium gehst Du aus? Dass wirklich Clients rund um die Uhr Volldampf auf dem NIC haben? In der Praxis und abgesehen von irgendwelchem Server-Equipment hat ein Client unterschiedliche Load-Charateristiken. Und die LAN-Infrastruktur sollte dem Rechnung tragen, dass auch die Peaks sinnvoll abgefangen werden.

Wie schon geschrieben: Wenn ich paar der neuen MacPro unter die Finger krieg, schaue ich mir das alles mal im Detail an, was so der Bridging-Code unter Last taugt, wie sich SMB2 so schlägt, etc.

Kurzes Update!

Bzgl. der Chosen auf dem untersten (also dem TB-Layer) lag ich daneben, wenn es darum geht, dass zwischen zwei Devices im Host-Modus (vulgo Macs) noch was anderes per Daisy-Chaining hängt, siehe

Die gute Nachricht: Ganz offensichtlich spart sich Apple bei "IP over Thunderbolt" diesen ganzen anachronistischen Offloading-Mist, um einer MTU zu huldigen, die irgendwann Ende der 70er im letzten Jahrhundert für die damalige Netzwerk-Realität definiert wurde.

Das Bridge-Device, das beim Einrichten einer Punkt-zu-Punkt-Verbindung automatisch angelegt wird, behauptet von sich, Offloading/Checksumming zu beherrschen:


D.h. dem OS wird signalisiert, daß es hier ruhig bis zu 64 KB große Pakete abliefern darf und den Rest die Netzwerk-Karte macht. Aber anstatt jetzt CPU-Zyklen zu verbrunzen, indem per Software unnötigerweise die Pakete auf die MTU zurechtgestutzt werden, spart sich Apple das komplett, weil am anderen Ende des Kabels eh wieder ein Mac hockt, der ja nur wieder damit unnötig beschäftigt wäre, kleine Pakete entgegenzunehmen. Die Pakete rauschen einfach so mit der VMTU durchs Netz und fertig:

Im Fall, dass zu dem entsprechenden Bridge-Device ein Ethernet-ähnliches gehören sollte, geschieht Offloading unter der Haube in Software, das die Pakete auf die MTU dieses Devices ummapped.

Gute Nachrichten für die Peer-to-Peer-Vernetzung mittels Thunderbolt, eher schlechte für das Device, das ein solches Mesh-Netzwerk an Ethernet anbinden muß, wenn an der Stelle viel Austausch stattfindet und der TB-Traffic nicht eher lokal auf die TB-fähigen Kisten begrenzt ist.

Sehr interessante Einsichten hier. Danke @@ Thomas Kaiser.

Übrigens: Ein hochinteressantes Research Paper von Microsoft und Intel, in dem es genau darum geht, mittels TB (bzw. damals eben noch Light Peak) bzw. günstigen hochintegrierten Crossbar-Switches als Teil der TB-Implementierung und Peer-to-Peer-Vernetzung eine effizientere Alternative zu "traditionellen" LAN-Topologien mit zentralen Switches zu bilden, findet sich hier

Absolut lesenswert!

Nach meinem Kenntnisstand sieht die Roadmap für Thunderbolt vor, den Datendurchsatz zumindest über Glasfaserkabel schrittweise auf bis zu 100Gb/s zu erhöhen. In 2015 sollen bereits 50 Gb/s erreicht werden. Thunderbolt 1 und 2 sind definitiv nur der Anfang.

Hoffentlich werden die Glasfaserstrippen bald mal billiger, damit ich mein geplantes TB-Raid in den Nebenraum verbannen kann. Von Delock hatte ich neulich mal ein 10 Meter langes Thunderbolt-Kabel im Test. Funktioniert prächtig, kostet z.Z. aber weit über 1.000 Euro.