Czasy serializacji i serializacji w sieciach 40G / 10G i 100G / 25G Ethernet

15

Niedawno brałem udział w dyskusjach na temat wymagań dotyczących najniższych opóźnień dla sieci Leaf / Spine (lub CLOS) do obsługi platformy OpenStack.

Architekci systemów dążą do możliwie najniższego czasu RTT dla swoich transakcji (blokowanie pamięci i przyszłe scenariusze RDMA), a twierdzono, że 100G / 25G oferuje znacznie zmniejszone opóźnienia serializacji w porównaniu do 40G / 10G. Wszystkie zaangażowane osoby zdają sobie sprawę, że w końcowej fazie gry jest o wiele więcej czynników (z których każdy może zaszkodzić RTT lub pomóc) niż tylko karty sieciowe i opóźnienia serializacji portów. Nadal jednak pojawia się temat opóźnień serializacji, ponieważ są one jedną rzeczą, którą trudno zoptymalizować bez przeskakiwania potencjalnie bardzo kosztownej luki technologicznej.

Nieco zbyt uproszczone (pomijając schematy kodowania), czas serializacji można obliczyć jako liczbę bitów / szybkość transmisji , co pozwala nam zacząć od ~ 1,2μs dla 10G (patrz także 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

Teraz interesujący kawałek. W warstwie fizycznej 40G wykonuje się zwykle jako 4 linie 10G, a 100G jako 4 linie 25G. W zależności od wariantu QSFP + lub QSFP28 czasami jest to wykonywane za pomocą 4 par pasm włókien, czasami jest dzielone przez lambda na pojedynczej parze włókien, gdzie moduł QSFP samodzielnie wykonuje część xWDM. Wiem, że istnieją specyfikacje dla linii 1x 40G lub 2x 50G, a nawet 1x 100G, ale odłóżmy je na chwilę.

Aby oszacować opóźnienia serializacji w kontekście wielopasmowych 40G lub 100G, trzeba wiedzieć, w jaki sposób karty sieciowe 100G i 40G oraz porty przełączników faktycznie „rozprowadzają bity do (zestawu) przewodów”, że tak powiem. Co się tu robi?

Czy to trochę jak Etherchannel / LAG? NIC / switchports wysyłają ramki jednego „przepływu” (czytaj: ten sam wynik mieszania dowolnego algorytmu haszującego zastosowanego w jakim zakresie ramki) w jednym danym kanale? W takim przypadku spodziewalibyśmy się opóźnień serializacji, takich jak odpowiednio 10G i 25G. Ale w gruncie rzeczy, to spowodowałoby, że łącze 40G byłoby tylko LGD 4x10G, zmniejszając przepustowość pojedynczego przepływu do 1x10G.

Czy jest to coś w rodzaju nieco okradzionego robota? Każdy bit jest dystrybuowany w trybie round-robin przez 4 (pod) kanały? Może to faktycznie skutkować mniejszymi opóźnieniami serializacji z powodu paralelizacji, ale rodzi kilka pytań na temat dostawy w kolejności.

Czy to coś w stylu okrągłego robota? Całe ramki ethernetowe (lub inne kawałki bitów o odpowiedniej wielkości) są przesyłane przez 4 kanały, dystrybuowane w sposób okrągły?

Czy to coś zupełnie innego, na przykład ...

Dziękujemy za komentarze i wskazówki.

Marc „netztier” Luethi
źródło

Odpowiedzi:

14

Część dzieląca wiele linii nazywa się podwarstwą kodowania fizycznego w standardzie IEEE 802.3ba. Prezentacja Gary'ego Nicholla daje dobry przegląd tego.

Krótkim wyjaśnieniem jest to, że dane są podzielone na wiele linii w blokach po 64 bity każdy ( kodowane na drucie jako 66 bitów w celu odzyskania zegara). Dlatego gdy tylko rozmiar pakietu przekroczy N * 64 bitów (= 32 bajty dla 4 linii), może w pełni wykorzystać wszystkie linie. Wystąpi pewne opóźnienie w kodowaniu, ale prawdopodobnie jest to specyficzne dla implementacji.

Ten schemat pochodzi z prezentacji połączonej powyżej: Funkcja podwarstwowego kodowania fizycznego

jpa
źródło
1
„Kodowanie będzie opóźnione” , oh. Teraz otworzyłeś kolejną puszkę robaków! Ile wynosi opóźnienie? Czy wpływa to na opóźnienie pakietu? Itd ...
rura
1
Ach, dzięki za to. W moim rozumieniu, te „Słowa” są „kawałkami bitów o odpowiedniej wielkości”, jak to napisałem w moim oryginalnym poście. Czy to się zbliża?
Marc 'netztier' Luethi
1
@ Marc'netztier'Luethi Dokładnie.
jpa
@pipe Tak. Na szczęście „Wszystkie zaangażowane osoby są świadome, że jest o wiele więcej czynników” :)
jpa
2
@pipe dobrze, myślę, że zostawimy to na bok. Na wszelkie wyzwania, które pojawią się od teraz, odpowiem „póki wyślesz wystarczającą ilość danych naraz (32 bajty), aby umożliwić karcie sieciowej / portowi krążyć wokół czterech pasów, otrzymasz krótsze / równoległe opóźnienie serializacji wy tak bardzo szukacie ". Oczywiście każda częściowo upieczona ramka Ethernet z nagłówkiem IP i brak ładunku już przekroczy ten limit. Dlatego: nieważne.
Marc 'netztier' Luethi
16

Jesteś przesadny.

Liczba używanych pasów tak naprawdę nie ma znaczenia. Niezależnie od tego, czy przesyłasz 50 Gbit / s na 1, 2 lub 5 liniach, opóźnienie serializacji wynosi 20 ps / bit. Otrzymasz 5 bitów na każde 100 ps, ​​niezależnie od użytych linii. Podział danych na pasy i rekombinacja odbywa się w podwarstwie PCS i jest niewidoczny nawet na wierzchu warstwy fizycznej. Bez względu na sytuację, nie ma znaczenia, czy PHY 100G szereguje 10 bitów kolejno na jednym torze (10 ps każdy, 100 ps łącznie), czy równolegle na 10 liniach (100 ps każdy, 100 ps łącznie) - chyba że „ odbudowuję tę PHY.

Oczywiście 100 Gbit / s ma opóźnienie o połowę 50 Gbit / s i tak dalej, więc im szybciej serializujesz (na wierzchu warstwy fizycznej), tym szybciej przesyłana jest ramka.

Jeśli interesuje Cię wewnętrzna serializacja w interfejsie, musisz spojrzeć na wariant MII, który jest używany dla klasy prędkości. Jednak ta serializacja odbywa się w locie lub równolegle z faktyczną serializacją MDI - zajmuje to niewielką ilość czasu, ale zależy to od rzeczywistego sprzętu i prawdopodobnie niemożliwe do przewidzenia (coś o długości 2-5 ps zgaduję za 100 Gbit / s). Nie martwiłbym się tym, ponieważ wiąże się to ze znacznie większymi czynnikami. 10 ps to kolejność opóźnień transmisji, które można uzyskać z dodatkowych 2 milimetrów (!) Kabla.

Użycie czterech linii 10 Gbit / s każda dla 40 Gbit / s NIE jest tym samym, co zebranie czterech łączy 10 Gbit / s. Łącze 40 Gbit / s - niezależnie od liczby linii - może transportować pojedynczy strumień 40 Gbit / s, którego nie mogą uzyskać łącza LAGged 10 Gbit / s. Ponadto opóźnienie serializacji wynoszące 40G jest tylko 1/4 opóźnienia 10G.

Zac67
źródło
3
Dzięki za komentarz. Mówisz więc, że dla 10/25/40 / 100G reguła kciuka liczby bitów na klatkę / przepływność = opóźnienie serializacji pozostaje ważne, bez względu na to, ile linii używa dana warstwa fizyczna (daj lub wziąć trochę marginalnych różnic)?
Marc 'netztier' Luethi
6
Tak. Wielopasmowy Ethernet różni się pod tym względem znacznie od łączy zagregowanych.
Zac67