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.