Diskussion:InfiniBand

Bus oder kein Bussystem?

Ist InfiniBand wirklich ein BUS? Es scheint doch eher ein switched Fabric zu sein, das genauc nicht die Nachteile eines Buses hat!

Technisch gesehen ist Infiniband tatsächlich kein Bus, sondern ist vielmehr als Busersatz konzipiert. Könnte man durchaus verbessern; allerdings widersprechen sich landläufiges und technisches Verständis von Bussen - siehe z. B. Artikel HyperTransport, auch dort wird HT als Bus bezeichnet, weil es die Aufgabe von Bussen übernimmt. Sollte man also vielleicht ersetzen.

Ich bezweifle, dass derzeitige InfiniBand-Implementierungen Latenzzeiten von 1.32mus schaffen. Woher stammt dieser Wert? Mir sind Latenzzeiten von ca. 3mus bekannt, darunter dürfte schwer werden...

Dito. Das kann ich nur bestätigen und die Frage wieder holen... Woher stammt denn bitteschön *dieser* Wert?

Ich hab ihn mal auf 3mus geändert...

"InfiniBand benutzt einen bidirektionalen seriellen Bus", dieser satzt ist irrsinnig. "bidirektionalen ... Bus" merkt wer ausser mir den widerspruch? Ein Bus ist immer "bidirektional" dieses Wort macht in diesem zusammenhang 0 sinn. Ein Bus ist auch nicht bidirektional sondern eher "multidirektional", aber das so zu sagen ist auch unsinnig. "Bus oder kein Bussystem?" Antwort: Kein Bus.--Moritzgedig 12:51, 10. Feb. 2009 (CET)

Als ich mal mit Infinibandprogrammiererei zu tun hatte hatte ich Karten bis QDR (40GBit/) und Openfabrics Netzwerksoftware in die Finger gekriegt. Nach meinem (unvollständigen) Verständnis wird ein Blocktransferaufruf des Anwenderprogramms (bis 2GByte - 32 bit Länge - theoretisch) beim laufenden Transfer durch die Karte in (bis zu) 4 KByte Päckchen zerlegt. Die 4KB Päckchen für Päckchen erst vom Sender abgeschickt werden wenn nicht nur die P2P Verbindung an der eigenen Netzwerkkarte (bis Switch) als auch die komplette Verbindung zwischen dem Sender und Empfänger frei - also auch frei vom letzten 4K Paket - sind. Transferprioritäten für Paketarbitration sind im Prinzip round-robin. Abwarten bis Verbindung frei heißt auch kein Delay durch Buffering durch konkurrierende Netzwerktransfers wie z.B. in TCP Switches.

Das bedeuted das die eine Latenzzeit die entsteht die Zeit für die Übertragung eines solchen 4KByte Paketes ist. (Bei 40GBit/s QDR Karten werden etwa 40000 Bit je 1 us übertragen - also gerade etwa ein solches 4 KByte Paket in ungefähr 1 us. Und das wird frühestens nach kompletter Übertragung an die ZielCPU ausgeliefert (Fertigmeldung). Nicht das einzelne Paket sondern der ganze Block. Da andere im Netzwerk laufende Transfers sicherlich mal 4 kByte Pakete verwenden - werden auch nach dem Round Robin Verfahren immer mal mindestens einfache fremde 4 KByte Transfers abzuwarten sein bis der eigene Pakettransfer möglich ist. Also Latenzen ab 1 us aber auch nicht fürchterlich weit davon entfernt für kurze Pakete - wenn die Zahl der gleichzeitig laufenden fremden und eigenen Transfers über das gleiche Netzsegment nicht unendlich ist.. Und: Je höher die Datenrate der Karte(n) (und Switches) - je kürzer die Latenzen.

Die zweite Latenzzeit die entsteht ist das die CPU die Blocktransfers managed. (Latenz= CPU Anwenderprogramm1 sendet .. CPU Anwenderprogramm 2 kriegt die Block(!)fertig Meldung.) Die eigene Anwendersoftware braucht dazu eine Threadaktivierung je Transferaufruf für einen Block (der von der Netzwerkhardware in 4 kByte Blöcke zerschnipselt übertragen wird) "Block fertig". Bei modernen (3..5..) GHz Prozessoren/OS kann man damit rechnen das Threadumschaltung etwa im bestenfalls 1 MHz Bereich (1us) liegen. Aber natürlich wird nicht jede Threadpriorität auch so schnell antworten - im Einzelfalle sind da oft (seltene) ziemlich beliebige Verzögerungen (Hänger) möglich. Je nach "Echtzeitfähigkeit" des OS .. Auch kann das Umräumen des CPU Cache bzw. schlichte Hauptspeicherzugriffe erhebliche Verzögerungen bewirken wenn's mal nötig wird. Auch DRAMs sind am Ende des Tages (äh des RAS-CAS Zyklus) in der Gegend von nur wenig schneller als 1us. Sind ja auch nicht mal RAS-CAS Zyklen sondern Cachelines ..

P.S. ich weiß nicht was "3mus" ist -- 2A00:6020:439A:9E00:BD8D:BC6E:C390:84B5 12:00, 17. Feb. 2022 (CET)

Hyper Transport

Inwiefern hat sich Hyper Transport als Bus nicht durchsetzen können? Verwechsle ich was? Was ist mit sämtlichen Opteron/Athlon64?

Diese Info stammt aus der Zeit, als die AMD64-Prozessoren noch nicht in professionellen Servern eingesetzt wurden; damals wurde HT nicht zur Anbindung von I/O benutzt. Heute gibt es auch schon I/O-Hardware, die direkt HT kann, allerdings laeuft fast alles immer noch über eine HT/PCI-X-Bridge. Das war mit "Bussystem" und "nicht durchsetzen" gemeint - dass die (ueberfaellige) Ersetzung von PCI durch ein geswitchtes System (wie HT, InfiniBand oder auch PCI-Express) mit HT und InfiniBand bis dato nicht gelang (auch PCIe tut sich noch etwas schwer, oder?)

unter 2 mu

siehe http://www.fz-juelich.de/zam/docs/za/2006/za-147#juli mit infinipath.

InfiniBand ist eine "switched fabric"

jedenfalls sieht die INfiniBand-Trade-Association (IBTA) das so. siehe: http://www.infinibandta.org/about/

Atomic-Doom-Option

Was versteht man unter der Atomic-Doom-Option. Der Begriff fällt hier einfach vom Himmel ohne weitere Erklärung und in der gesamten Wikipedia ist kein weiterführender Artikel zu finden der diese Option erklären würde. Wenn sich jemand damit auskennt bitte Präzisieren oder einen eigenständigen Artikel erstellen. Sonst sollte dieser Absatz besser gelöscht werden.

Änderung von 70.51.163.249 (am 22:31, 27. Nov. 2005) rückgängig gemacht. Für die "Atomic-Doom"-Option scheint es im gesamten WWW einen Suchtreffer zu geben: Die Wikipedia... --D235 15:26, 26. Jul. 2007 (CEST)

Änderung von 80.187.111.95 (am 22:28, 28. Okt. 2010) rückgängig gemacht. Ranma (23:17, 10. Mai 2011 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Aussprache

Wird InfiniBand gewöhnlich Deutsch oder eher Englisch ausgesprochen? Falls bekannt, bitte ergänzen. Danke --194.76.39.219 09:23, 2. Apr. 2007 (CEST)

HCA Begriffserklärung

Eine Frage, was bedeutet HCA aus dem Text? Edit: gerade gesehen, steht ja da --> Host Channel Adapter :-)

Software oder Hardware

Mich irritiert der Vergleich mit TCP/IP. Aus meiner Sicht sollte mit Ethernet oder TokenRing, etc. verglichen werden. Auch die Umsetzung des SW-Interfaces scheint mir hier deplaziert. Auch ist aus meiner Sicht das Ziel der Infiniband-Technologie aus dem Artikel nicht ersichtlich. Für mich war es das Ziel von Infiniband, low-latency-connections zur Prozessor-Kommunikation zu erstellen. Dies ist heute meist mit (PCIe)-Bussen realisiert. Kann daher diese "Bus-Diskussion" weiter oben entstanden sein? Faktisch wird es nun zur Prozessor-Kommunikation eingesetzt (z.B. bei IBM Power), aber auch zur Anbindung schnellen Speichers (z.B. Flash-Speicher oder NetApp e-series). (nicht signierter Beitrag von 84.142.64.211 (Diskussion) 14:10, 29. Sep. 2013 (CEST))

Funktionsprinzip im Detail

"Dies ermöglicht der Karte, die Übersetzung von virtuellen Adressen in physische Adressen selbst vorzunehmen".

Ich glaub eher nicht das das so den richtigen Eindruck erweckt. Beim Registrieren von bereits vorher angelegten Speicherblöcken (auch großen, theoretisch 32 bit Blocklänge) wird dieser Speicher "gepinnt". Sprich das Betriebssystem kann danach den Speicherblock nicht mehr verschieben (oder auslagern ?). Womit die Adresserzeugung durch die Hardware der Netzwerkkarte natürlich einfacher und statischer wird. Andererseits bringt dieses Pinning das letzte Quentchen Geschwindigkeitsgewinn - und macht dadurch erst die praktische Erreichung der theoretischen Transferrate einfachst (!) möglich - man muß nur die transferierten Speicherblöcke (Beliebiger Ausschnitt des gepinnten Buffers - (R)DMA) hinreichend groß machen - um den Transfer der Netzwerkkarte von der Prozessoraktivität hinreichend zu entkoppeln. Der Prozessor muß dann nur noch die Blocktransfers managen - sprich eine Threadreaktivierung je Block wird fällig.

Bei modernen GHz Prozessoren dürfte die Treadumschaltung Reaktionen im 1 us Bereich möglich machen - sprich die mit einem Blocktransfer den die CPU startet sollten bei 100 GBit/s (übliches EDR) mindestens in der Größenordung ab 12500 Byte liegen. Allerdings wird nicht jede Thread Priorität tatsächlich so schnell antworten. Es helfen größere Blöcke oder mehr überlappende Transfers - die Transferanforderungen des Anwenderprogramms trägt die Netzwerksoftware in eine Warteschlange ein.

Dieser Artikel ist eine Bleiwüste ohne Spezifikationen.

Ein Beispiel, wie man einen Artikel nicht schreibt. --176.199.210.236 19:03, 7. Apr. 2024 (CEST)