Serialisierungs- und Serialisierungszeiten in 40G / 10G- und 100G / 25G-Ethernet

Vor kurzem habe ich über die Anforderungen an die niedrigste Latenz für ein Leaf / Spine-Netzwerk (oder CLOS) zum Hosten einer OpenStack-Plattform diskutiert.

Systemarchitekten streben nach einer möglichst geringen RTT für ihre Transaktionen (Blockspeicher und zukünftige RDMA-Szenarien), und die Behauptung lautete, dass 100G / 25G im Vergleich zu 40G / 10G erheblich weniger Serialisierungsverzögerungen bieten. Allen Beteiligten ist bewusst, dass das End-to-End-Spiel (was RTT schaden oder helfen kann) viel mehr als nur Verzögerungen bei der NIC- und Switch-Port-Serialisierung aufweist. Dennoch taucht das Thema Serialisierungsverzögerungen immer wieder auf, da diese nur schwer zu optimieren sind, ohne eine möglicherweise sehr kostspielige Technologielücke zu überspringen.

Die Serialisierungszeit ist etwas vereinfacht (ohne die Codierungsschemata) und kann als Anzahl der Bits / Bitrate berechnet werden , sodass wir bei ~ 1,2 μs für 10 G beginnen können (siehe auch wiki.geant.org ).

For a 1518 byte frame with 12'144bits,
at 10G (assuming 10*10^9 bits/s), this will give us ~1.2μs
at 25G (assuming 25*10^9 bits/s), this would be reduced to ~0.48μs 
at 40G (assuming 40*10^9 bits/s), one might expect to see ~0.3μs
at 100G (assuming 100*10^9 bits/s), one might expect to see ~0.12μs

Nun zum interessanten Teil. Auf der physischen Schicht werden 40 G üblicherweise als 4 Spuren von 10 G und 100 G als 4 Spuren von 25 G ausgeführt. Abhängig von der QSFP + - oder QSFP28-Variante wird dies manchmal mit 4 Faserstrangpaaren durchgeführt, manchmal wird es durch Lambdas auf ein einzelnes Faserpaar aufgeteilt, wobei das QSFP-Modul selbst xWDM ausführt. Ich weiß, dass es Spezifikationen für Fahrspuren mit 1x 40G oder 2x 50G oder sogar 1x 100G gibt, aber lassen wir diese für den Moment beiseite.

Um Serialisierungsverzögerungen im Kontext von mehrspurigen 40G- oder 100G-NICs abzuschätzen, muss man wissen, wie 100G- und 40G-NICs und Switch-Ports die Bits sozusagen "auf die (Gruppe von) Drähte (n) verteilen". Was wird hier gemacht?

Ist es ein bisschen wie Etherchannel / LAG? Die NIC / Switchports senden Frames eines "Flusses" (gelesen: dasselbe Hashing-Ergebnis eines beliebigen Hashing-Algorithmus, der in welchem ​​Bereich des Frames verwendet wird) über einen bestimmten Kanal. In diesem Fall würden wir Serialisierungsverzögerungen wie 10G bzw. 25G erwarten. Aber im Grunde genommen würde eine 40G-Verbindung nur eine LAG mit 4 × 10G ergeben, wodurch der Durchsatz bei einem einzigen Durchsatz auf 1 × 10G reduziert würde.

Ist es so etwas wie ein bisschen Round-Robin? Jedes Bit ist Round-Robin über die 4 (Sub-) Kanäle verteilt. Dies kann aufgrund der Parallelisierung zu geringeren Verzögerungen bei der Serialisierung führen, wirft jedoch einige Fragen zur Lieferung in der Bestellung auf.

Ist es so etwas wie Frame-weise Round-Robin? Ganze Ethernet-Frames (oder andere entsprechend große Bit-Blöcke) werden über die 4 Kanäle gesendet, verteilt auf Round-Robin-Art.

Ist es etwas ganz anderes, wie ...

Vielen Dank für Ihre Kommentare und Hinweise.

Der Teil, der die Aufteilung in mehrere Spuren vornimmt, wird im IEEE 802.3ba-Standard als physikalische Codierungsunterschicht bezeichnet . Diese Präsentation von Gary Nicholl gibt einen guten Überblick darüber.

Die kurze Erklärung ist, dass die Daten in 64-Bit-Blöcken auf mehrere Spuren aufgeteilt sind ( auf Draht codiert als 66-Bit für die Taktwiederherstellung). Sobald die Paketgröße N * 64 Bit überschreitet (= 32 Byte für 4 Lanes), können daher alle Lanes voll genutzt werden. Es wird einige Verzögerungen bei der Codierung geben, dies ist jedoch wahrscheinlich implementierungsspezifisch.

Dieses Diagramm stammt aus der oben verlinkten Präsentation:

Du überdenkst.

Die Anzahl der benutzten Fahrspuren spielt keine Rolle. Unabhängig davon, ob Sie 50 Gbit / s über 1, 2 oder 5 Lanes transportieren, beträgt die Serialisierungsverzögerung 20 ps / Bit. Sie erhalten also alle 100 ps 5 Bits, unabhängig von den verwendeten Spuren. Das Aufteilen von Daten in Spuren und das erneute Kombinieren erfolgen in der PCS-Unterschicht und sind selbst über der physischen Schicht unsichtbar. Unabhängig von Ihrer Situation spielt es keine Rolle, ob ein 100G-PHY 10 Bits nacheinander über eine einzelne Spur (jeweils 10 ps, ​​insgesamt 100 ps) oder parallel über 10 Spuren (jeweils 100 ps, ​​insgesamt 100 ps) serialisiert - es sei denn, Sie Bauen Sie diese PHY.

Natürlich hat 100 Gbit / s die Hälfte der Verzögerung von 50 Gbit / s und so weiter. Je schneller Sie (über der physischen Schicht) serialisieren, desto schneller wird ein Frame übertragen.

Wenn Sie an der internen Serialisierung in der Schnittstelle interessiert sind, müssen Sie sich die MII-Variante ansehen, die für die Geschwindigkeitsklasse verwendet wird. Diese Serialisierung findet jedoch im laufenden Betrieb oder parallel zur eigentlichen MDI-Serialisierung statt - es dauert zwar eine Minute, aber das hängt von der tatsächlichen Hardware ab und ist wahrscheinlich nicht vorhersehbar (etwa 2 bis 5 ps) schätze mal für 100 Gbit / s). Ich würde mir darüber eigentlich keine Sorgen machen, da es um viel größere Faktoren geht. 10 ps ist die Größenordnung der Übertragungslatenz, die Sie von zusätzlichen 2 Millimetern (!) Kabel erhalten würden.

Die Verwendung von vier Lanes mit jeweils 10 Gbit / s für 40 Gbit / s ist NICHT gleichbedeutend mit der Zusammenfassung von vier 10 Gbit / s-Verbindungen. Ein 40-Gbit / s-Link kann - unabhängig von der Anzahl der Lanes - einen einzelnen 40-Gbit / s-Stream transportieren, der bei LAGged 10-Gbit / s-Links nicht möglich ist. Außerdem beträgt die Serialisierungsverzögerung von 40G nur 1/4 der von 10G.