Czy w systemie Windows można przetwarzać miliony datagramów na sekundę?


11

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 .


@Ramhound Teoretycznie jest to prawdopodobnie możliwe w systemie Windows. Ale jak to jest możliwe w praktyce? Do tej pory natknąłem się na kilka raportów od ludzi osiągających te poziomy w Linuksie na standardowym sprzęcie, ale ani jednego nie zbliżyłem się do systemu Windows. Jak myślisz, jak mógłbym ograniczyć zakres pytania? Po prostu: „Jakie są najwyższe stawki odbierania multiemisji UDP w systemie Windows?”. Większość tekstu w moim pytaniu to tylko przykłady, które powinny pokazać, że jest to możliwe w Linuksie - i że odrobiłem pracę domową.
Eugene Beresovsky

@Ramhound „Jeśli to możliwe w systemie Linux, to możliwe w systemie Windows”. Odpowiednio się nie zgadzam .. jednym systemem, który od razu przychodzi mi na myśl, jest iptables .. tak, powodzenia naśladując ten system w systemie Windows. ^ _ ^
NiCk Newman

Tak naprawdę nie starałem się tak mocno, więc zawsze możesz wziąć cały kod, który mam do testów RIO, które zrobiłem i nadal pchać.
Len Holgate,

Odpowiedzi:


5

Według Microsoftu testy w ich laboratorium wykazały, że „na określonym serwerze we wczesnych testach” RIO byli w stanie sobie poradzić

  • 2Mpps bez strat w Windows Server 2008R2, tj. Bez RIO
  • 4Mpps na (przedpremierowo) Windows Server 8 przy użyciu RIO

Zrzut ekranu z tego filmu (44:33):

wprowadź opis zdjęcia tutaj

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:

  1. Czy dane do wysłania? Otrzymujesz A może do routingu (tj. Odbieranie + wysyłanie)?
  2. Jaki rozmiar pakietu? -> Prawdopodobnie najniższa możliwa, jak to zwykle się dzieje, gdy próbujesz przekonać się do liczby pps
  3. Ile połączeń (jeśli TCP) / strumieni pakietów (jeśli UDP) ? -> Prawdopodobnie tyle ile jest konieczne do rozłożenia obciążenia, aby można było wykorzystać wszystkie obecne rdzenie
  4. Jaka konfiguracja testu? Specyfikacja maszyny i karty sieciowej oraz okablowanie

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)

platforma może utrzymać szybkość transakcji wynoszącą około 2 mln transakcji na sekundę

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

  1. odbiór pakietu UDP
  2. kolejne przekazywanie tego pakietu

(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:

wprowadź opis zdjęcia tutaj


2

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ł:

Nie starałem się tak mocno, aby uzyskać maksymalną wydajność, aby porównać względną wydajność między starymi i nowymi interfejsami API, więc nie byłem tak dokładny w testowaniu.

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ść:

  • Nikt tak naprawdę nie używa systemu Windows, próbując opracować aplikacje o bardzo niskim opóźnieniu i / lub o wysokiej przepustowości, obecnie używają Linuksa
  • Praktycznie wszystkie testy wydajności i raporty z rzeczywistymi wynikami (tj. Nie tylko reklama produktu) są obecnie w Linuksie lub BSD (dzięki Len za to, że był pionierem i dał nam przynajmniej jeden punkt odniesienia!)
  • Czy UDP (standardowe gniazda) w systemie Windows jest szybszy / wolniejszy niż w systemie Linux? Nie wiem jeszcze, musiałbym zrobić własne testy
  • Czy wysokowydajny UDP (RIO vs mapa) w systemie Windows jest szybszy / wolniejszy niż w systemie Linux? Linux z łatwością radzi sobie z pełną prędkością linii 10 Gb z jednym rdzeniem przy 900 MHz, Windows, w najlepszym przypadku opublikowanym może wzrosnąć do 43% lub 492 kpps dla dużego pakietu UDP o wielkości 1024, tj. Liczby bps dla mniejszych rozmiarów prawdopodobnie będą znacznie gorzej, chociaż liczby pps prawdopodobnie wzrosną (chyba że ograniczeniem jest obsługa przerwań lub inny narzut przestrzeni jądra).

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

zaznacz, aby opóźnić wymianę już od 35ns [nano sekund]

Przy okazji twierdzą, że tak

Zdecydowana większość istniejących kodów obliczeniowych do handlu jest obecnie napisana dla systemu Linux na architekturze procesorów x86.

a Argon używa przełącznika Arista 7124FX , który (oprócz FPGA) ma system operacyjny

zbudowany na standardowym jądrze Linuksa.


0

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ć.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.