Sprawdzam, czy mogę wdrożyć aplikację HPC w systemie Windows, która odbiera małe datagramy rozsyłania grupowego UDP (w większości 100-400 bajtów) z dużą szybkością, używając kilkunastu lub nawet 200 grup rozsyłania grupowego (tj. Używając MSI-X i RSS mogę skaluj do wielu rdzeni), wykonuje pewne przetwarzanie na pakiet, a następnie wysyła je. Wysyłając przez TCP udało mi się dotrzeć tak daleko, jak to konieczne (6,4 Gb / s), nie uderzając o ścianę, ale problem okazał się otrzymując datagramy z dużą szybkością pps.
W ostatnim teście na wysokiej jakości maszynie NUMA z 2-portową kartą Ethernet 10 Gb na Windows 2012 R2 byłem w stanie odbierać tylko setki tysięcy datagramów UDP na sekundę (wczesne upuszczenie, tj. Bez faktycznego przetwarzania danych, do usuń obciążenie obliczeniowe mojej aplikacji z równania, aby zobaczyć, jak szybko się to robi) za pomocą 2x12 rdzeni, a część jądra z 12 testowanych grup multiemisji wydawała się rozproszona na 8 lub 10 rdzeni jednego węzła NUMA ( ustawiono maks. kolejki RSS do 16) - aczkolwiek z aplikacją .net, więc aplikacje natywne powinny być w stanie działać szybciej.
Ale nawet Len Holgate zdołał tylko odebrać pakiety UDP przy 500kpps w swoich wysokowydajnych testach Windows RIO , używając ładunku 1024 UDP.
W białej księdze QLogic (o testowanym systemie operacyjnym nie wspomniano) limity dla „wielowątkowego routingu bardzo małych pakietów” (tak, że obejmuje to zarówno odbieranie, jak i wysyłanie?) Są ustawione na 5,7 Mb / s . W artykułach na temat pracy w sieci Linux limity są ustawione na 1Mpps do 2Mpps na rdzeń (podobno skaluje się mniej więcej liniowo), a nawet 15Mpps ze specjalnymi rozwiązaniami, które omijają jądro.
Np. Mapa sieci
może generować ruch z szybkością linii ( 14,88 Mb / s ) na łączu 10GigE za pomocą tylko jednego rdzenia działającego z częstotliwością 900 MHz. Jest to równe około 60-65 cyklom zegara na pakiet i dobrze skaluje się z rdzeniami i częstotliwością zegara (przy 4 rdzeniach szybkość linii jest osiągana przy częstotliwości mniejszej niż 450 MHz). Podobne stawki są osiągane po stronie odbiorczej .
Jak daleko mogę posunąć (najnowsze wersje) Windows / Windows Server, w szczególności odbieranie multiemisji UDP, jak opisano w akapicie wiodącym?
Edytuj Jest post na blogu cloudflare - i ciekawa sekcja komentarzy - jak to zrobić w Linuksie: jak otrzymywać milion pakietów na sekundę , i jest odpowiednia strona z komentarzami hakerów .
źródło
Odpowiedzi:
Według Microsoftu testy w ich laboratorium wykazały, że „na określonym serwerze we wczesnych testach” RIO byli w stanie sobie poradzić
Zrzut ekranu z tego filmu (44:33):
Tak więc odpowiedź na moje pytanie brzmiałaby
Is it possible to process millions of datagrams per second with Windows?: tak , i najwyraźniej było to jeszcze przed RIO, w Windows Server 2008R2.Ale oprócz oficjalnych danych, zwłaszcza dotyczących niepublikowanego oprogramowania, które należy wziąć ze szczyptą soli, z jedynie rzadkimi informacjami podanymi w tej prezentacji, pozostaje wiele pytań na temat testu, a tym samym, jak prawidłowo interpretować wyniki. Najważniejsze z nich to:
Pierwszy jest kluczowy, ponieważ wysyłanie i odbieranie wymaga różnych kroków i może wykazać znaczne różnice w wydajności. W przypadku innych liczb możemy prawdopodobnie założyć, że na maszynie o wysokiej specyfikacji zastosowano najmniejszy rozmiar pakietu, z co najmniej jednym strumieniem połączenia / pakietu na rdzeń, aby uzyskać maksymalne możliwe liczby Mpps.
Edytuj Właśnie natknąłem się na dokument Intela na temat przetwarzania pakietów o wysokiej wydajności w systemie Linux i zgodnie z tym (Linux)
używając standardowego stosu sieciowego Linuxa (na fizycznym hoście z rdzeniami 2x8). Transakcja w tym teście żądania / odpowiedzi obejmuje oba te elementy
(za pomocą serwera sieciowego netperf). Test prowadził równolegle 100 transakcji. Dla zainteresowanych jest więcej szczegółów w artykule. Chciałbym, abyśmy mieli coś takiego do porównania dla systemu Windows ... W każdym razie oto najbardziej odpowiednia tabela dla tego testu żądania / odpowiedzi:
źródło
tl; dr
Aby dać jednoznaczną odpowiedź, konieczne są dalsze testy. Jednak poszlaki wskazują, że Linux jest systemem operacyjnym używanym praktycznie wyłącznie w społeczności o bardzo niskim opóźnieniu, która rutynowo przetwarza obciążenia Mpps. Nie oznacza to, że jest to niemożliwe w systemie Windows, ale Windows prawdopodobnie pozostanie trochę w tyle, nawet jeśli możliwe jest osiągnięcie liczb Mpps. Ale to wymaga przetestowania i np. Ustalenia, jaki koszt (procesora) można uzyskać.
NB: To nie jest odpowiedź, którą zamierzam przyjąć. Ma on na celu udzielenie wszystkim zainteresowanym odpowiedzią na pytanie pewnych wskazówek na temat tego, gdzie się znajdujemy i gdzie należy dalej badać.
Len Holgate, który według Google wydaje się być jedynym, który przetestował RIO, aby uzyskać większą wydajność sieci Windows (i opublikował wyniki), wyjaśnił w komentarzu na swoim blogu , że używa jednej kombinacji IP / Port do wysyłania pakietów UDP.
Innymi słowy, jego wyniki powinny być w pewnym stopniu porównywalne z liczbami pojedynczego rdzenia w testach na Linuksie (chociaż używa 8 wątków - które, nie sprawdzając jeszcze swojego kodu, wydają się szkodliwe dla wydajności przy obsłudze tylko jednego strumienia pakietów UDP, a nie wykonując ciężkie przetwarzanie pakietów, a on wspomina, że w rzeczywistości jest używanych tylko kilka wątków, co miałoby sens). To dlatego, że powiedział:
Ale co rezygnuje z (względnej) strefy komfortu standardowego IOCP dla bardziej surowego świata RIO innego niż „ciężkie próby”? Przynajmniej jeśli chodzi o pojedynczy strumień pakietów UDP.
Wydaje mi się, że ma na myśli - próbując różnych podejść projektowych w kilku testach RIO - że nie dopracował np. Ustawień karty sieciowej, aby wycisnąć ostatnią część wydajności. Co np. W przypadku rozmiaru bufora odbiorczego może potencjalnie mieć ogromny pozytywny wpływ na wydajność odbierania UDP i straty pakietów.
Problem przy próbie bezpośredniego porównania jego wyników z wynikami innych testów Linux / Unix / BSD jest następujący: Większość testów, próbując przesunąć granicę „pakietów na sekundę”, używa najmniejszego możliwego rozmiaru pakietu / ramki, tj. Ethernet ramka 64 bajtów. Len przetestował 1024 bajty pakietów (-> ramka 1070 bajtów), które (szczególnie w przypadku UDP No-Nagle) mogą zapewnić ci znacznie wyższe liczby „bitów na sekundę”, ale mogą nie przesunąć granicy pps tak daleko, jak to możliwe przy mniejszych pakietach . Nie byłoby więc uczciwe porównywanie tych danych w obecnej postaci.
Podsumowując wyniki mojej wyprawy do Windows UDP otrzymałem dotychczas wydajność:
To, dlaczego używają Linuksa, musi być tak dlatego, że opracowywanie rozwiązań obejmujących zmiany jądra, takie jak netmap lub RIO - konieczne przy zwiększaniu wydajności do granic możliwości - jest prawie niemożliwe w zamkniętym systemie, takim jak Windows, chyba że twoje wypłaty wypadną z Redmond, lub masz specjalną umowę z Microsoft. Właśnie dlatego RIO jest produktem MS.
Wreszcie, aby podać kilka ekstremalnych przykładów tego, co odkryłem, było i dzieje się w Linuksie:
Już 15 lat temu niektórzy otrzymywali 680kpps przy użyciu procesora Pentium III 800 mHz, 133 MHz szyny frontowej na karcie sieciowej 1GbE.Edycja : korzystali z Click , routera w trybie jądra, który omija znaczną część standardowego stosu sieciowego, tzn. „Oszukuje”.W 2013 roku udało się zdobyć Argon Design
Przy okazji twierdzą, że tak
a Argon używa przełącznika Arista 7124FX , który (oprócz FPGA) ma system operacyjny
źródło
Na pewno będziesz potrzebować „pomiaru” różnych konfiguracji i scenariuszy. Można to zrobić AFAIK z dwoma narzędziami dostarczonymi przez 2 firmy. IXIA i Spirent . Oferują sprzętowe generatory ruchu, które mogą pompować ruch z prędkością linii. Oferują one test rampowy, w którym można wykryć prędkość, z jaką może zapaść się twój system. Urządzenia są drogie, ale można je wypożyczyć.
źródło