Metody zwiększania wydajności przetwarzania strumieni danych w stosach protokolarnych IP dla sieci standardu IEEE Ethernet

Transkrypt

1 Metody zwiększania wydajności przetwarzania strumieni danych w stosach protokolarnych IP dla sieci standardu IEEE Ethernet Jacek Światowiak, Krzysztof Nowicki, krzysztof.nowicki@eti.pg.gda.pl Politechnika Gdańska Słowa kluczowe: IP, Ethernet, strumienie danych, systemy operacyjne, jądro NT 5.X, NT 6.X, pomiary wydajności Abstrakt - W artykule dokonano analizy metod zwiększania wydajności przetwarzania strumieni danych w stosach protokolarnych IP w kontekście współczesnych sieciowych systemów operacyjnych dla sieci standardu Ethernet (IEEE 802.3). Badań dokonano dla dominujących na rynku rozwiązań (stos IPv4 oraz serwerowe systemy operacyjne Microsoft Windows i Unix/Linux). 1. Wstęp Około 95% współczesnych serwerów zbudowanych jest w oparciu o klasyczną architekturę zgodną z zaproponowaną przez firmę INTEL już w roku Od tego czasu komponenty serwerów uległy scaleniu, zwiększyła się wydajność poszczególnym komponentów takich jak procesory (zmiana wielkości przetwarzanego słowa danych 4/8/16/32/64 bity), magistrale (ISA/EISA/AGP/PCI/PCI-Express), wielkość i szybkość dostępu do pamięci (DDR/DDR2/DDR3/FBDIM). Jednak ogólna budowa serwerów nie uległa zmianie i jest pewnego rodzaju rozwinięciem architektury Von Neumann a 1. Serwery te pracują głównie z dwoma rodzajami sieciowych systemów operacyjnych: rodziny Microsoft Windows oraz szerokiej rodziny określanej, jako UNIX/LINUX/BSD (pozostałe systemy operacyjne jak SUN/SOLARIS/MACOS stanowią margines rynku i nie były rozpatrywane w prezentowanym projekcie badawczym. Jako powszechny protokół komunikacyjny wykorzystywany jest protokół IPv4 (IPv6 stanowi cały czas margines rynku [1]). Jako powszechne rozwiązanie komunikacyjne w środowiskach sieciowych wykorzystywany jest standard IEEE Ethernet (10,100 Mbit/s, 1 i 10 Gbit/s) [2]. Starsze rozwiązania jak Token Ring FDDI, ATM zanikły na rynku, zaś inne jak Fibre-Channel czy InfiniBand mają specjalne zastosowanie [3]. Protokoły z rodziny IP (IPv4/IPv6) idealnie wpisują się w 7-mio warstwowy referencyjny model odniesienia ISO/OSI, co umożliwia im szybką implementację w systemach operacyjnych i określa sposób przetwarzania danych zgodny z powszechnie stosowaną enkapsulacją danych warstw wyższych w strukturach warstw niższych [4]. Tego typu podejście bardzo wygodne w latach 90 XX wieku oraz pierwszych latach XXI wieku zaczyna w tej chwili stanowić pewnego rodzaju ograniczenie mogące w przyszłości stanowić barierę dla zwiększania wydajności przetwarzania strumieni danych o wysokich przepływnościach [6-18]. 2. Środowisko pomiarowe i dobór sprzętu Ze względu na odmienne zadania realizowane przez poszczególne typy serwerów (plików, drukarek, aplikacji) przy ocenie ich wydajności należy skupić się: a) dla serwerów plikowych i drukarkowych na dużej pojemności pamięci masowej i szybkim do niej dostępie - zatem podsystemy dyskowe oraz komunikacja z interfejsem sieciowym musi być bardzo wydajna. Sam serwer z punktu widzenia obciążenia, nie ma zapotrzebowania ani na dużą moc obliczeniową ani na dużą pamięć operacyjną. b) dla serwerów aplikacyjnych na mocy obliczeniowej i przepustowości magistral oraz wielkości dostępnej pamięci operacyjnej. Praktycznie gro operacji wykonywanych jest na pamięci operacyjnej. Komunikacja z otoczeniem jest raczej sporadyczna, ogranicza się do wprowadzania danych i wyprowadzania wyników. W tym przypadku czynnikami mającymi największy wpływ na wydajność są: moc obliczeniowa 1 Nazwa pochodzi od treści publikacji - First Draft of a Report on the EDVAC- 30 czerwca

2 procesora/procesorów/rdzeni o ile mamy możliwość skorzystania z dobrodziejstwa architektury SMP lub NUMA, ilość pamięci oraz przepustowość magistrali procesor <-> pamięć. Przygotowanie uniwersalnego środowiska pomiarowego (dla obu typów serwerów) wymagało podjęcia decyzji zarówno o typie komputerów mających pełnić role serwerów (markowość/łatwość konfiguracji, typ płyty głównej) jak też rodzajów interfejsów sieciowych (szybkości, zakresu wsparcia rozwiązań zwiększających wydajność), sposobie łączenia komputerów itd. Mimo szerokiego spektrum producentów sprzętu: markowych i nie markowych różnorodność dostarczanych na rynek rozwiązań serwerowych jest, wbrew pozorom, dość ograniczona. Pierwotnie dla celów badawczych planowany był wybór serwera markowego. Lecz czynniki zarówno ekonomiczne jak i pewne dość hermetyczne rozwiązania w markowym sprzęcie spowodowały zmianę decyzji i budowę serwerów z klocków. Trudno je nazwać niemarkowymi, gdyż przecież każdy z ich elementów produkowany jest przez markowego dostawcę i często jest również wykorzystywany w innych prawdziwie markowych serwerach. Warto podkreślić, że podejście związane z budową serwerów od zera pozwoliło nam na uzyskanie bardziej elastycznej konfiguracji bardziej przydatnej dla celów badawczych. Dla celów pomiarowych wydajności współczesnych elementów związanych z przetwarzaniem danych protokolarnych stosu IPv4 oraz IPv6 należało stworzyć prosty system umożliwiajacy łatwe rekonfiguracje i pomiary. Zaproponowany system pomiarowy składa się z dwóch identycznych serwerów klasy INTEL o parametrach zbliżonych do parametrów 80% serwerów powszechnie wykorzystywanych na rynku. Zostały one połączone pomiędzy sobą za pomocą szerokiej gamy interfejsów sieciowych klasy Ethernet IEEE (poczynając od 100 Mbit/s a kończąc na dostępnych już 10 Gbit/s). Aby pominąć wpływ czynników zewnętrznych serwery te łączone były bezpośrednio, za pomocą kabla skretkowego 6 kategorii (z pominięciem przełączników warstwy II). Aby móc skorzystać z najnowszych rozwiązań należało dobrać płytę główną, procesory i pamięć w taki sposób, aby zapewnić ich optymalne współdziałanie. Na tym poziomie rozważań jedynym czynnikiem ograniczającym był dostępny budżet. W zakresie budowy płyty głównej i procesorów, wybrano płytę pod procesory rodziny INTEL XEON. Dla serwerów pełniących rolę serwerów aplikacyjnych, płyta powinna wspierać wieloprocesorowość (SMP). Coraz popularniejsze są serwery zawierające dwa gniazda (sloty) na procesory. Zatem wybrano płytę główną, w której można było obsadzić 2 (jednordzeniowe, dwurdzeniowe oraz czterordzeniowe procesory). Dla sytuacji serwerów aplikacyjnych zależało nam na wypadkowej większej mocy obliczeniowej, zatem wybrano dwa procesory czterordzeniowe o mniejszej częstotliwości pracy każdy niż dwa procesory dwurdzeniowe o większej częstotliwości 2. Ostateczny wybór padł na procesory INTEL XEON CORE QUAD z rodziny E54XX E5405. Są to procesory taktowane zegarem 2 GHz wyposażone we współdzieloną pamięć cache L2 o wielkości 12 MB. Procesor ten ma również bardzo wysoką przepustowość magistrali łączącej go z pamięcią oraz układem MCH [tzw. mostka północnego], wynoszącą 1333 MT/s. Dysponowaliśmy, zatem serwerami wyposażonymi w sumie w 8 niezależnych rdzeni każdy. Budowę płyty głównej przedstawiono na rysunku 1. Do pomiarów wykorzystano kilka popularnych kart sieciowych standardu Ethernet: 100 Mbit/s opartych na magistralach PCI i PCI-Express, wykorzystywanych w popularnych stacjach roboczych. Były to: karta sieciowa 10/100 Mbit/s na magistrali PCI 32-bit/33 MHz oparta na chipsecie Realtek 8139 oraz karta sieciowa 10/100 Mbit/s na magistrali PCI 32-bit/33/66 MHz oparta na chipsecie Intel Gbit/s opartych na magistralach PCI (karta firmy Realtek - z chipsetem Realtek 8169S pracująca na magistrali PCI 32-bit/33/66 MHz), PCI-Express (karta firmy Intel INTEL 82564EB zintegrowana z mostkiem południowym na magistrali PCI-Express x4) oraz wbudowana w płytę główną (ta karta sieciowa posiada bardzo ciekawe rozwiązania mające zapewnić zwiększanie wydajności przetwarzania ruchu sieciowego: Jumbo frames 9,5 KB, INTEL I/O Acceleration Technology, INTEL Quick Data, iscsi Acceleration, MSI-X, Microsoft Receivce Side Scalling, Linux Scalable I/O, Direct Cache Access, IPv4/IPv6 TCP, UDP Checksum offload, TCP segmentation/large send offload, IPv6 offloading, IPSec Offload (w tym obsługa AES 256-bit) 2 Tego typu podejście mimo pozytywnej wstępnej analizy, okazało się pewnego rodzaju ograniczeniem, które wykryte zostało dopiero w fazie pomiarowej i stało się podstawą do sformułowania jednego z ważniejszych wniosków końcowych. 2

3 Rysunek 1. Budowa płyty głównej wykorzystywanej w środowisku pomiarowym (dwa gniazda na procesory INTEL XEON DP Core Quad z serii 5400, 8 banków pamięci DDR2 Fully Buffered ECC; gniazda rozszerzeń: 2 sloty PCI Express *16 Gen 2, 2 sloty PCI-X 133 MHz, 2 sloty PCI 32 bity/33 MHZ, 1 slot PCI-Express) 10 Gbit/s opartych na magistrali PCI-Expres Gen 2. Intel o symbolu 82598EB (karta ta obsługuje najnowsze rozwiązania w zakresie zwiększania wydajności, jak: INTEL I/O Acceleration Technology, INTEL Quick Data, iscsi Acceleration, MSI-X, Microsoft Receivce Side Scalling, Linux Scalable I/O, Direct Cache Access, IPv4/IPv6 TCP, UDP Checksum offload, TCP segmentation/large send offload, IPv6 offloading) oraz specjalizowana karta sieciowa Ethernet 10 Gbit/s oparta na chipsecie firmy NETXEN NX-3031 (obsługuje wiele rozwiązań z zakresu zwiększania wydajności : Interrupts: Message Based: INTx, MSI, MSI-X Up to 2K Unique Interrupts, Checksum Offload, TCP, UDP & IP Tx, Rx, IPv4 & IPv6 Advanced Stateless Offload, Large Send Offload (LSO), Large Receive Offload (LRO), TCP Segmentation Offload (TSO), Jumbo Frames 802.1p, Interrupt Coalescing, Stateful TCP/IP Offload, Hardware Support for iscsi Acceleration, Hardware Support for Full FCoE Acceleration). 3. Metoda pomiarowa oraz narzędzia pomiarowe Do wykonywania pomiarów wykorzystywane były zarówno niezależne gotowe narzędzia jak też specjalnie przygotowane skrypty: D-ITG Wysoce wydajny i konfigurowalny generator ruchu IP Typeperf Wbudowane w System Operacyjny Windows narzędzie służące do monitorowania i zbierania parametrów systemu Sleep.exe Narzędzie dołączane w pakiecie narzędzi Windows pozwalające na opóźnienie przetwarzania kolejnej części skryptu Runner.bat - Napisany w Windows Batch Script skrypt sterujący pomiarem w oparciu o zadany plik konfiguracyjny Output_get_for_run.bat (oraz wariacje) Skrypt na podstawie binarnego pliku logu zestawu pomiarów (wyjść ITGSend) uzyskuje potrzebne wartości w formie tekstowej D-ITG - jest wieloplatformowym, darmowym i otwartym zestawem programów służących do wysyłania i odbierania ruchu o zadanych parametrach. Dodatkowo dostępne są narzędzia do późniejszej obróbki zapisu przebiegu tego ruchu [5]. 3

4 Typeperf jest to narzędzie wbudowane w System Operacyjny Windows pozwalające na monitorowanie, wyświetlanie oraz logowanie różnych parametrów systemu. Program umożliwia użycie pliku, jako źródła danych do pomiaru oraz wskazania długości działania jak również pliku, w którym ma zostać zapisany wynik. W pomiarach służył do określenia ogólnego obciążenia systemu, tj: obciążenia rdzeni procesora, użycia pamięci, liczby wywołanych przerwań, długości kolejki dostępu do dysku, liczbę zapisów na dysk. Aby przeprowadzić pomiar potrzebne były dwie wartości: a) Wielkość pakietu (ustalone z góry wartości) oraz b) Intensywność zgłoszeń pakietów (liczba generowanych pakietów na sekundę nadawana przez generator) - pomiary rozpoczęto od wartości równej maksymalnej przepustowości łącza podzielonej przez wielkość generowanego pakietu. Otrzymana wartość wyznaczała teoretyczną liczbę pakietów, które może przenieść łącze. Jak się okazało ze wstępnych pomiarów wartość ta nie pozwalała na otrzymanie wyników nawet zbliżonych do maksymalnych. Powiększając ten parametr natrafiono na wartość gdzie dalsze zwiększanie dla inicjalnego systemu i domyślnych wartości nie powodowało już przyrostu średniej przepływności. Uzyskaną w ten sposób wartość zwiększono jeszcze nieznacznie upewniając się, że ta zmiana nie powiększa w zauważalny sposób ogólnego obciążenia systemu pozwalając na uzyskanie potencjalnie lepszych wyników manipulując parametrami kart sieciowych. Pomiary były wykonywane dla jednej karty 10G Intela a następnie przeniesione na pozostałe (aby wszystkie karty pracowały w identycznych warunkach roboczych). Pomiary zrealizowano dla każdej karty, zmieniając kolejno każdy dostępny parametr kart mogący wpłynąć na wynikową przepływność (za pomocowa odpowiednich zmian w pliku konfiguracyjnym skryptu pomiarowego). Dla każdego pomiaru rejestrowane były: a) Średnia wielkość strumienia b) Średnia liczba przesłanych pakietów na sekundę c) Obciążenie CPU oraz pojedynczych rdzeni d) Liczba przerwań na poszczególnych rdzeniach e) Zajętość pamięci RAM f) Długość kolejki dostępu do dysku twardego g) Liczba operacji zapisu na dysk Pomiary zostały wykonane osobno dla jednego i dla ośmiu strumieni przy zachowaniu identycznej metodyki. 4. Metody i mechanizmy zwiększania wydajności przetwarzania strumieni danych Klasyczne przetwarzanie stosu TCP/IP (uwzględniając architekturę modelu ISO/OSI) zakłada przetwarzanie sprzętowe tylko dwóch pierwszych warstw (fizycznej oraz podwarstw MAC i LLC) [w tym sprzętową kontrolę sumy korekcyjnej dla ramki Ethernet]. Całe przetwarzanie danych dla warstw wyższych musi być realizowane przez procesor główny serwera/komputera. Z przeprowadzonej analizy budowy i mechanizmów komunikacyjnych urządzeń podłączanych za pomocą dowolnej z magistral komunikacyjnych (ISA/EISA/AGP/PCI/PCI-Express) wynika iż, wszystkie urządzenia korzystające z magistral komunikacyjnych (niezależnie od trybu komunikacji synchronicznej czy asynchronicznej) muszą zgłaszać do procesora informacje o przyjęciu ramki danych /zapełnienia bufora komunikacyjnego odbiorczego oraz nadawczego. Ten proces realizowany jest poprzez zgłaszanie tzw. przerwania sprzętowego. To przerwanie musi zostać odebrane przez tzw. kontroler przerwań, który to kolejkuje przerwania od urządzeń zewnętrznych i przekazuje je do procesora tak, aby ten mógł sekwencyjnie zająć się ich obsługą. Z tego toku rozumowania wynika, iż im większy będzie strumień danych oraz liczba odebranych ramek danych /sekundę tym więcej będzie generowanych przerwań, które to musi odebrać i przetworzyć procesor. I tu zgodnie z klasyczną budową serwera obsługą przerwań zajmuje się wyłącznie procesor o numerze logicznym 0. Dla interfejsów sieciowych 1 Gbit/s potrafi osiągnąć wartość do 12 tysięcy przerwań na sekundę dla 32-bitowego systemu Windows Server 2003 R2 SP2 x86 w Wersji Enterprise i prawie 60 tysięcy przerwań /sekundę dla interfejsu 10 Gbit/s (dla tego samego systemu operacyjnego). Mechanizm rozkładania obsługi przerwań na różne procesory fizyczne/logiczne nazywany CPU Interrupt Affinity dostępny jest wyłącznie dla nowych systemów operacyjnych (bazujących na systemach Windows NT od rodziny 6.1) posadowionych na serwerach wyposażonych w zmodyfikowany mechanizm kontroli przerwań zwany MSI-X (Message Signaled Interrupt). Niestety dla klasycznego podejścia, dla zachowania spójności, obsługa całego strumienia ruchu wchodzącego czy wychodzącego musi być realizowana w obrębie jednego procesu wykonywanego przez pojedynczy procesor. Jest to bardzo widoczne na charakterystykach obciążenia poszczególnych rdzeni procesora. Przytoczony powyżej rozważania dotyczą obsługa danych pobranych z interfejsu sieciowego bez rozpatrywania, jaki protokół komunikacyjny dla warstwy sieciowej czy transportowej jest wykorzystywany. Odebrane dane muszą być, zatem załadowane szeregowo do jakiegoś bufora [najczęściej w trybie FIFO. Po czym sterowanie przekazuje się do warstw wyższych (III ISO/OSI lub II dla IPv4/IPv6). Teraz następuje sekwencyjne przetwarzanie danych (wykrycie typu i numeru protokołu dla warstwy III modelu ISO/OSI) oraz dalsze sekwencyjne przetwarzanie danych znajdujących się w nagłówku datagramu IPv4/IPv6. Dla protokołu TCP 4

5 wbudowany mechanizm zapewni nam optymalną wartość MSS segmentu TCP niestety w przypadku UDP może się okazać, iż przychodzące dane będą pofragmentowane. Fragmentowanie może również zajść w przypadku przechodzenia przez łącza o różnym MTU. Ze względu na przyjęty układ pomiary ten problem nigdy nie wystąpi. W układzie klasycznym procesor musi również dokonać weryfikacji (obliczyć sumy kontrolne nagłówka datagramu IP, oraz segmentu TCP czy pakietu UDP), w przypadku pofragmentowanego datagramu lub pakietu UDP musi również dokonać jego uporządkowania oraz odrzucić zdublowane fragmenty. To wszystko zajmuje moc i czas procesora a dane cały czas nie mogą być przekazane do protokołów warstwy aplikacji (warstwa IV modelu TCP/IP). Aby odciążyć procesor od wykonywania tych żmudnych [czaso- i zasobo- chłonnych] operacji, producenci sprzętu w uzgodnieniu z producentami systemów operacyjnych zaproponowali następujące mechanizmy sprzętowo-programowe, które mają po części odciążyć procesor/y od konieczności wykonywania tych operacji (patrz rysunek 2). Są to: Dodanie obsługi ramek Jumbo o wielkościach do 9014 bytów zamiast standardowej 1518 (przydatne szczególnie w przypadku przesyłanie dużych porcji danych, np. sieci pamięci masowych SAN, pracujących z protokołem iscsi) Opcje określane, jako TCP/IP Offloading Options: o IPv4 Checksum Offload - umożliwia sprzętową generację i weryfikację sumy kontrolnej nagłówka IP przez kartę sieciowa o TCP Checksum Offload (IPv4) - umożliwia sprzętową generację i weryfikację sumy kontrolnej segmentu TCP przez kartę sieciowa. Analogiczna opcja dostępna jest dla protokołu IPv6. o UDP Checksum Offload (IPv4) - umożliwia sprzętową generację i weryfikację sumy kontrolnej pakietu UDP przez kartę sieciowa. Analogiczna opcja dostępna jest dla protokołu IPv6. o Offload TCP Segmentation odpowiada za sprzętową fragmentację i defragmentację segmentów TCP. Określany również, jako LSO (ang. Large Send Offload) Rysunek 2. Opcje zaawansowane konfiguracji interfejsu sieciowego, na przykładzie interfejsu 10 Gbit/s Mechanizm Header Data Split dostępny dopiero od systemów Windows Server 2008 R2 umożliwiający sprzętowe oddzielenie przez interfejs sieciowy nagłówków datagramu IP oraz segmentu TCP i pakietu UDP od przekazywanych danych w celu optymalizacji buforowania danych i przetwarzania danych umieszczanych w nagłówkach Ściśle sprzętowy mechanizm o nazwie Adaptive Inter-Framing Spacing kompensujący straty związane z pojawieniem się kolizji na łączu Ethernetowym Ściśle sprzętowy mechanizm o nazwie Direct Cache Access - związany z bezpośrednim trybem przesyłania danych przez sterownik DMA dostępny tylko w natywnym sterowniku firmy INTEL (niedostępny zaś w sterowniku dostarczanym przez firmę Microsoft) 5

6 Flow Control opcja związana z reakcją sterownika na ramki odpowiadające za kontrole przepływu danych (niezależnie dla ruchu wchodzącego i wychodzącego) Interrrupt Moderation (Rate) jedna z najważniejszych opcji związana z celowym opóźnianiem generacji przerwań kierowanych do kontrolera przerwań i w konsekwencji do procesora Low Latency Interrupts opcje tylko dla protokołu TCP dostępne wyłącznie w sterowniku firmy INTEL opcja o zachowaniu przeciwnym niż poprzednia zmniejszająca opóźnienie generacji przerwania do segmentów TCP kierowanych na określone porty oraz mających ustawioną flagę TCP PSH RSS (ang. Receive Side Scalling) opcja umożliwiająca rozkładanie obsługi wchodzącego ruchu sieciowego pomiędzy wiele rdzeni procesora/procesorów. Opcja wymagana przez specjalne rozszerzenie sprzętowe firmy INTEL o nazwie INTEL I/O Acceleration Technology. Dla mechanizmu RSS można określić ilość sprzętowych kolejek wspieranych przez interfejs sieciowy oraz ilość rdzeni procesorów przeznaczonych do obsługi ruchu sieciowego. mechanizm TCP Chimney jeden z dodatkowych mechanizmów zaproponowanych przez firmę Microsoft i nie mający, z racji praw patentowych, swojego odpowiednika dla systemów klasy Open- Source. Umożliwia on rozdzielenie i niezależne przetwarzanie informacji zawartych w nagłówkach IP oraz TCP oraz samych danych, które poprzez specjalną warstwę określaną, jako TCP Chimney mogą być kierowane bezpośrednio do warstwy aplikacji (patrz rysunek 3). Rysunek 3. Budowa i działanie mechanizmu TCP Chimney 5. Zaobserwowane efekty i parametry pomiarów Jako najbardziej charakterystyczne wybrano wyniki pomiarowe dla dwóch kart sieciowych: wbudowanej, pracującej z szybkością 1 Gbit/s zbudowanej na chipsecie INTEL o symbolu 82575EB oraz 10 Gbit/s zbudowanej na chipsecie INTEL o symbolu 82598EB. Pomiary wykonano oddzielnie dla protokołu TCP oraz UDP dla 1 oraz 8 niezależnych strumieni danych, dla segmentów TCP oraz pakietów UDP o następujących wielkościach: 10, 100 bajtów, 1,1.5, 2, 5, 10, 20, 30, 40, 50 oraz 64 KB. W celu porównania wyników dla systemów starszej generacji (bazujących na jądrze NT 5.X) [Windows Server 2003] oraz nowych (bazujących na jądrze NT6.X) [Windows Server 2008 R2] ograniczono się wyłącznie do protokołu IPv4. Czynnikiem ograniczającym możliwości porównania systemów starszej i nowszej generacji była niestabilność generatora ruchu dla protokołu IPv6. Wyniki pomiarowe uzyskiwane z serii danych pomiarowych różniły się o kilkaset procent dla systemów 32-bitowych i 64-bitowych co całkowicie dyskwalifikuje wstępnie przyjęte narzędzie pomiarowe. Narzędzie to jest narzędziem uniwersalnym do pracy w systemach Windows jak i 6

7 open source i przyjęty w nim sposób generacji ruchu dla systemów 64-bitowych jest prawdopodobnie źle zaimplementowany, gdyż Microsoft w nowszych systemach zmodyfikował budowę sterownika interfejsów sieciowych NDIS, co mogło spowodować wspomniane wyżej rozrzuty na wynikach pomiarowych. Wydaje się, że najwartościowsze będzie, zatem porównanie wersji systemu klasy NT 5.X z systemem klasy NT 6.X. Dla systemów rodziny NT 5.X reprezentatywny jest Windows Server 2003 R2 SP2 w Wersji Enterprise Edition w edycji x86 (platforma 32-bitowa), dla którego dokonano pomiarów w siedmiu różnych ustawieniach konfiguracyjnych: 1. Ustawienia: default = jumbo = off; inter-fram spacing - adaptive; DCA - on; flow - rx & tx; interrupt moderation - adaptive; rx buffer - 256; tx buffer - 512; RSS - on; rss queues - 1; offload - all on 2. Ustawienia: Ramka jumbo = 4088B; 3. Ustawienia: Ramka jumbo = 9014B 4. Ustawienia: Offload checksum off 5. Ustawienia: Offload segmentation off 6. Ustawienia: RSS off; 7. Ustawienia: RSS 2 sprzętowe kolejki 8. Dla ustawienia: RSS 4 sprzętowe kolejki nie udało się dokonać pomiarów łącze wykazywało taką niestabilność i odczytane wyniki trudno było uznać za wiarygodne. Przyczyną mogło być nieprawidłowe działanie sterownika karty sieciowej Wyniki pomiarowe w obrębie tej samej rodziny dla platformy 32-bitowej i 64-bitowej są praktycznie jednakowe na granicy błędu pomiarowego i uśredniania za 100 jednakowych pomiarów. Dla systemów rodziny NT 6.X reprezentatywny jest Windows Server 2008 R2 w Wersji Enterprise Edition w edycji x64 (dla tej platformy dostępna jest wyłącznie wersja 64-bitowa), dla którego dokonano pomiarów w 10 różnych ustawieniach konfiguracyjnych: 1. Ustawienia: offload - all on; jumbo - off; flow - rx & tx; interrutla moderation - adaptive; rx tx buffers - 512; rss - enbled; rss queues Ustawienia: Ramka jumbo = 4088B; 3. Ustawienia: Ramka jumbo = 9014B 4. Ustawienia: Offload checksum off 5. Ustawienia: Interrupt Moderation rate off; 5. Ustawienia: Interrupt Moderation rate - on 7. Ustawienia: RSS Off; 8. Ustawienia: RSS 1 queue; 9. Ustawienia: RSS 4 queue 10. Ustawienia: Flow Control off 6. Przykładowe charakterystyki ruchowe dla interfejsów 1 Gbit/s i 10 Gbit/s Dla karty sieciowej 1 Gbit/s. Dla TCP segment o wielkości 10 i 100 bajtów zaobserwowano gwałtowny spadek przepływności do ok. 245 kbit/s, gdzie przy segmencie o wielkości 1 KB wartość ta jest aż 3 rzędy wielkości większa i sięga 155 Mbit/s dla ramki Jumbo o wielkości 9 KB. Jest to dość oczywiste gdyż wynika z niedopasowania wielkości wysyłanych danych do potencjalnej wielkości ramki. Dla tego typu danych system wykazuje dość wysokie obciążenie jednego rdzenia procesora (dla jednego strumienia danych) przekraczające 80%. W przypadku 8-miu strumieni obciążenie rozkłada się w miarę równomiernie po wszystkich rdzeniach ale sięga 60%. Dla segmentu zbliżonego do wielkości MTU klasycznego Ethernet, czyli 1500 bajtów średnie strumień danych niezależnie od wprowadzanych modyfikacji jest prawie jednakowy w granicach 680 MBit/s poza konfiguracją z ramką jumbo 9 KB gdzie jest ponad 3 krotnie mniejszy ok 180 Mbit/s. Dla tego typu danych system wykazuje cały czas dość wysokie obciążenie jednego rdzenia procesora (dla jednego strumienia danych), choć nieprzekraczające 60%. W przypadku 8-miu strumieni obciążenie rozkłada się w miarę równomiernie po wszystkich rdzeniach ale sięga już tylko 40%. Dla segmentów o wielkości 2 KB tu zaletę pokazuje ramka Jumbo o wielkości 4088 KB przepustowość sięga już 920 Mbit/s, przy jednocześnie najniższym obciążeniu rdzeni procesora nieprzekraczającym 28% [dla jednego strumienia i 32% dla 8-miu strumieni]. Dla segmentu 5 KB przepustowość dla jednego strumienia niestety nie przekracza 420 Mbit/s zaś dla 8-miu 850 Mbit/s przy bardzo niskim obciążeniu rdzeni poniżej 20% (zarówno dla jednego jak i dla 8-miu strumieni) Segment 10 KB pojedynczy strumień tylko ok. 300 Mbit/s przy 8-miu strumieniach prawie 980 Mbit/s przepustowość praktycznie niezależna od zmiany parametrów konfiguracyjnych. Obciążenie rdzeni procesorów poniżej 10%. Segment 20 KB pojedynczy strumień już prawie 500 Mbit/s przy 8-miu strumieniach prawie 980 Mbit/s przepustowość praktycznie niezależna od zmiany parametrów konfiguracyjnych. Obciążenie rdzeni procesorów w okolicach 12% dla jednego strumienia i 18% dla 8-miu strumieni. Segment 30 KB pojedynczy strumień już ponad 700 Mbit/s ale sumacyjny nieznacznier spadł do 940 Mbit/s. Wzrosło jednakże obciążenie rdzeni do 25% dla jednego strumienia Segment 40 i 50 KB zachowują się podobnie jak segment 30 KB Dla segmentu 64 KB praktycznie nie ma różnicy w przepustowości jednego i 8-mui strumieni. Dla ramki jumbo 9 KB wysycono praktycznie łącze 990 Mbit/s. Obciążenie rdzeni procesorów w okolicach 12% dla jednego strumienia i 18% dla 8-miu strumieni. 7

8 W przypadku pakietów UDP wyniki są zdecydowanie bardziej ciekawe: Dla pakietu UDP o wielkości 10 bajtów niezależnie od ustawienia przepustowość pojedynczego strumienia wynosi ok. 4 Mbit/s i 9,5 Mbit/s dla 8-miu strumieni. Obciążenie rdzenia procesora sięga 70% dla pojedynczego strumienia i do ponad 50% w przypadku 8-miu strumieni. Dla pakietu o wielkości 100 bajtów przepustowość wzrosła ponad 10 krotnie [do 40 Mbit/s jeden strumień i 93 Mbit/s dla 8-miu strumieni]. W obsługę ruchu wyraźnie angażowane są dwa rdzenie procesora, z czego obciążenie jednego sięga blisko 85%. Dla pakietu o wielkości 1 KB bajtów przepustowość znów 10 krotnie wzrasta [do 430 Mbit/s jeden strumień i 930 Mbit/s dla 8-miu strumieni]. W obsługę ruchu wyraźnie angażowane są jak poprzednio dwa rdzenie procesora, z czego obciążenie jednego sięga blisko 75%. Dla pakietu o wielkości 1,5 KB przepustowość pojedynczego strumienia spadła do ok 160 Mbit/s. Wynikowa 8-miu strumieni już tylko 600 MBit/s zaobserwowano natomiast dla wyłączonej opcji Offload checksum gwałtowną redukcję ilości generowanych przerwań z 9 tysięcy/s na 600/s. Gwałtownie spadło również obciążenie rdzeni procesora osiągnięto poziom 5%. Dla pakietu o wielkości 2 KB przepustowość pojedynczego strumienia wzrosła do ok 200 Mbit/s. Wynikowa 8-miu strumieni już tylko 420 MBit/s [poza przypadkiem, gdy włączone były dwie sprzętowe kolejki RSS tu sumarycznie osiągnięto 840 Mbit/s. Zaobserwowano ponownie dla wyłączonej opcji Offload checksum gwałtowną redukcję ilości generowanych przerwań z 9 tysięcy/s na 600/s. Gwałtownie spadło również obciążenie rdzeni procesora dla tej opcji osiągnięto poziom 5%. Średnie obciążenie rdzeni procesora sięga 12% - jednakże zawsze jeden rdzeń jest obciążony do poziomu ok 40%. Dla pakietu o wielkości 5 KB przepustowość pojedynczego strumienia osiąga ok 200 Mbit/s [ jednakże dla ramek o wielkości 4 i 9 KB osiąga już 380 Mbit/s]. Wynikowa 8-miu strumieni już ponad 650 MBit/s. Zaobserwowano ponownie dla wyłączonej opcji Offload checksum gwałtowną redukcję ilości generowanych przerwań z 9 tysięcy/s na 600/s. Równie gwałtownie jak dla poprzedniego przypadku spadło również obciążenie rdzeni procesora dla tej opcji osiągnięto poziom 5%. Dla 8-miu strumieni średnie obciążenie rdzeni procesora sięga tylko 8% - jednakże zawsze jeden rdzeń jest obciążony do poziomu ok 40%. Dla pakietu o wielkości 10 KB przepustowość pojedynczego strumienia osiąga ok 320 Mbit/s [nie jest tu jednak zależne od wielkości ramki jest stałe]. Wynikowa 8-miu strumieni już prawie 900 MBit/s. Ilość przerwań jest cały czas dość niska około 650/s. Obciążenie rdzeni procesora dla jednego strumienia utrzymuje się na poziomie 15%. Dla 8-miu strumieni średnie obciążenie rdzeni procesora sięga tylko 5% - jednakże zawsze jeden rdzeń jest obciążony do poziomu ok 35%. Dla pakietu o wielkości 20 KB przepustowość pojedynczego strumienia osiąga ok 600 Mbit/s [jedynie dla ramki jumbo o wielkości 9 KB utrzymuje się na poziomie ok 300 Mbit/s]. Wynikowa 8-miu strumieni już prawie 1 Gbit/s. Ilość przerwań jest cały czas dość niska z zakresu 1500 do 650/s szczególnie przy wyłączonej opcji Offload checksum. Obciążenie rdzeni procesora dla jednego strumienia utrzymuje się na poziomie 20%. Dla 8-miu strumieni średnie obciążenie rdzeni procesora sięga tylko 5% - jednakże zawsze jeden rdzeń jest obciążony do poziomu ok 35%. Dla pakietu o wielkości 30 KB i 40 KB wartości zmierzone są zbliżone jak dla pakietu o wielkości 20 KB. Wrosła tylko szybkość dla jednego strumienia dla ramki jumbo 9 KB do 600 Mbit/s. Zaś dla pozostałych opcji do ponad 820 Mbit/s. Pakiet o wielkości 65 KB zachowuje się identycznie jak pakiet 30 KB. Dla karty sieciowej 10 Gbit/s. W zakresie bardzo małych wielkości segmentów (10 i 100 bajtów) zmiana parametrów nie ma wielkiego wpływu na maksymalną przepustowość. Jedynie ustanowienie bardzo dużej wartości ramki Jumbo 4 lub 9 KB powoduje gwałtowny spadek maksymalnej przepustowości. Dla tego typu wielkości segmentu obciążenie rdzenia procesora związanego z obsługą transmisji sięgnęło 85% dla pojedynczego strumienia i 72 % dla rdzeni dla ośmiu jednoczesnych strumieni danych. Maksymalna osiągnięta wynikowa przepustowość dla segmentu 10 bajtów wyniosła 6,7 MBit/s przy jednym strumieniu danych i 10,7 przy ośmiu strumieniach. Analogicznie dla segmentu 100 bajtów wyniosła przy jednym strumieniu już 55,7 Mbit/s zaś przy ośmiu strumieniach 75 Mbit/s Dla segmentów o wielkości 1 KB maksimum przepustowości uzyskano przy domyślnych ustawieniach i wyniosło ono przy jednym strumieniu 373,5 Mbit/s zaś przy ośmiu strumieniach 541,3 Mbit/s. Co ciekawe największą sumacyjną wartość przepustowości uzyskano przy ramce jumbo o wielkość 4 KB. Najmniejszą ilość przerwań zaobserwowano dla ustawienia (Interrupt Moderation rate extreme), co jest oczywiste, gdyż ten parametr odpowiada za minimalizację ilości generowanych przerwań. Najmniejsza ilość generowanych przerwań przełożyła się automatycznie na najmniejsze obciążenie rdzenia odpowiedzialnego za obsługę transmisji dla pojedynczego strumienia. Dla ośmiu strumieni takiego pozytywnego zjawiska już nie zaobserwowano i średnie obciążenie każdego z ośmiu rdzeni wynosiło ok. 50%. Dla segmentu o wielkości 1,5 KB (dopasowanego specjalnie, aby wypełnić maksymalnie ramkę Ethernet standard) obserwowane wyniki są bardzo zbliżone jak dla segmentu o wielkości 1 KB. Wzrosłą jednak 8

9 maksymalna osiągnięta przepustowość dla pojedynczego strumienia do 442,3 Mbits/s i sumacyjna 703,7 Mbit/s dla ośmiu strumieni. Wrosło niestety również obciążenia procesorów przy ośmiu strumieniach nie jest ono równomierne. Przy zmniejszeniu ilości sprzętowych kolejek z 2 do 1 obciążenie procesora odpowiedzialnego za obsługę ruchu wzrosło do 81%. Segment o wielkości 2 KB (zatem przekraczający już wielkość standardowej ramki Ethernet) zachowuje się podobnie jak przy 1,5 KB. Lecz maksimum przepustowości dla pojedynczego strumienia uzyskano dla ustawień domyślnych interfejsu sieciowego i wyniosło ono 560 Mbit/s, zaś sumacyjne dla ośmiu strumieni 922,6 Mbit/s. Mimo to najbardziej optymalne ustawienia dla wielu strumieni pod względem obciążenia procesora (co wynika pośrednio z mniejszej ilości przerwań) odpowiadają konfiguracji opcji Interrupt Moderation rate extreme. Dla segmentu o wielkości 5 KB maksimum przepustowości dla pojedynczego strumienia wyniosło 460,7 Mbit/s, dla ośmiu strumieni spadło i wyniosło 853,3 Mbit/s. Zmiany parametrów nie powodują już tak gwałtownych obserwowanych zmian parametrów (najmniejsza wartość to 216 Mbit/s dla pojedynczego strumienia i 696,2 dla ośmiu strumieni. Bardzo ciekawe zjawisko zaobserwowano dla opcji wyłączonej moderacji przerwań. Jej wyłącznie nie spowodowało praktycznie spadku przepustowości, ale gwałtowny wzrost ilości przerwań (z ok. 7 tyś przerwań/sek do ponad 24 tysięcy). Segment o wielkości 10 KB zachowuje się podobnie jak 5 KB. Maksimum przepustowości dla pojedynczego strumienia wyniosło 545,5 Mbit/s, dla ośmiu strumieni spadło i wyniosło 1115,6 Mbit/s. Przerwania zachowują się podobnie. Dla wyłączonej opcji moderacji przerwań, ilość przerwań wzrosła z 6 tyś na 15 przy pojedynczym strumieniu oraz z 6,8 na ponad 25 tysięcy/s. Obciążenie rdzeni procesorów nie przekracza 40%. Dla segmentu o wielkości 20 KB obserwujemy już inne zjawiska. Maksymalna przepustowość dla jednego strumienia jest praktycznie niezmienna od parametrów (i wyniosła 932 Mbit/s). Najmniejsza zaobserwowana została dla opcji Interrupt Moderation rate extreme i wyniosła tylko 312,4 Mbit/s. Dla ośmiu strumieni jest praktycznie niezmienna (od 2,038 Gbit/s do 2,205 Gbit/s). Analogicznie zachowują się przerwania (średnio 6,5 tys./sek zaś przy wyłączonej opcji moderacji przerwań ponad 25 tys./s). Inaczej jednak zachowuje się obciążenie rdzeni procesora. Interfejs sieciowy miał domyślnie włączone dwie sprzętowe kolejki ruch z tych kolejek jak pokazują pomiary jest rozkładany na dwa rdzenie procesora(ów) mniej więcej równomiernie (ok. 60% obciążenie). Przy przełączeniu się na jedną kolejkę sięga już 75% (pozostałe na poziomie ok. 25%). Przy czterech kolejkach (a tyle posiada ich testowana karta obciążenie dla czterech rdzeni spadło do ok. 35%, pozostałych zaś poniżej 20%. Segment 30 KB zachowuje się analogicznie jak segment 20 KB. Maksymalna osiągalna przepustowość jest podobnie jak dla segmentu 20 KB w miarę niezmienna ( i wyniosła dla jednego strumienia 1,372 Gbit/s zaś dla ośmiu strumieni 2,970 Gbit/s. Przerwania zachowują się mniej więcej podobnie. Segment 40 KB dla pojedynczego segmentu największą przepustowość zaobserwowano dla ustawień standardowych i wyniosła 1,671 Gbit/s zaś dla ośmiu strumieni 3,901 Gbit/s (dla opcji 4 sprzętowych kolejek). Z pomiarów widać, iż obciążane są cztery rdzenie (trochę niestety nierównomiernie 42% do 66%), a nie jak w przypadku innych opcji, gdzie obciążane były dwa rdzenie (również bardzo niesymetrycznie). Przy jednej kolejce obciążenie rodzenia procesora sięgnęło już 98%. Segment 50 KB również bardzo zbliżone wyniki przepustowościowe, lecz już gorsze niż dla segmentu o wielkości 40 KB. Dla pojedynczego segmentu największą przepustowość zaobserwowano dla ramki jumbo 4 KB i wyniosła 1,620 Gbit/s zaś dla ośmiu strumieni 3,6114 Gbit/s. Segment 64 KB - Dla pojedynczego segmentu największą przepustowość zaobserwowano dla ramki jumbo 4 KB i wyniosła 2,069 Gbit/s zaś dla ośmiu strumieni 4,540 Gbit/s. Z pomiarów widać, iż obciążane są w tym przypadku cztery rdzenie konfiguracja z 4 sprzętowymi kolejkami - (niestety znowu widać, iż obciążenie rdzeni procesorów jest bardzo nierównomierne pomiędzy 28% a 72%), spadła zaś ilość przerwań do ok. 3 tyś/sek. 6. Wnioski końcowe Z przeprowadzonych serii pomiarów nie da się na dzień dzisiejszy wysnuć prostych jednoznacznych wniosków określających jak należy skonfigurować ustawienia interfejsu sieciowego, aby uzyskać optimum wydajności (przepustowości). Natomiast zgodnie z wieloma opisywanymi w literaturze przykładami charakterystyczne i zgodny z oczekiwaniami jest fakt, iż dla jednego strumienia danych częstotliwość taktowania procesowa praktycznie dokładnie odpowiada szybkości strumienia danych interfejsu sieciowego. Bardzo upraszczając 1 takt procesora to możliwość wysłania 1 bita po złączu Ethernet. Pomiarowy serwer był wyposażony w procesory taktowane zegarem 2 GHz i maksymalny pojedynczy strumień danych TCP wyniósł i to dla ramki o wielkości 4 KB - 2,069 Gbit/s. Druga bardzo ważna uwaga. Niezależnie od konfiguracji maksymalny strumień danych dla interfejsu 10 Gbit/s wyniósł tylko 4,540 Gbit/s, co sugeruje, iż dla pomiarowego serwera wyposażonego w procesory o wspomnianej 9

10 częstotliwości taktowania jest to wartość maksymalna i bez zmiany procesorów na szybsze (niestety nie są produkowane procesory o częstotliwości taktowania na poziomie 5 i więcej GHz) nie uda się prosto uzyskać wyższych przepustowości. Co prowadzi do kolejnego wniosku, iż w tej architekturze zarówno sprzętowej jak i systemowej inwestowanie w interfejsy 10 Gbit/s wydaje się nie mieć uzasadnienia zarówno technologicznego a tym bardziej ekonomicznego. Koszt dobrych interfejsów o przepustowości 1 Gbit/s wynosi ok. 100 zł, zaś koszt interfejsu 10 Gbit/s to wartość ok. 7 tyś zł, zatem jest nieproporcjonalnie wysoki. Należy sądzić, iż podobne parametry wydajnościowe można będzie uzyskać za pomocą wbudowanych mechanizmów, tzw. Teamingu interfejsów sieciowych dla kart 1 Gbit/s. Karta sieciowa serwerowa 4*1 Gbit/s kosztuje ok zł. Tego typu rozwiązanie posiada również dodatkowe zalety, charakteryzuje się skalowalnością oraz funkcjonalnością fail-over. W przypadku uszkodzenia jednego z interfejsów (również samego okablowania). System wyłączy dany port, zaś cały team kart będzie działał dalej ze zmniejszoną tylko wydajnością. Niektóre z rozwiązań implementowanych w systemach Microsoft chodzi tu o technologię TCP Chimney wykazują również poza zaskakującymi wynikami pomiarowymi cechy, które dla środowisk produkcyjnych są niedopuszczalne. Zaobserwowano niestabilności w działaniu interfejsów sieciowych, objawiające się losowo pojawiającym się jitterem, opóźnieniami w reakcji interfejsu sieciowego na pojawiający się ruch sieciowy. Również zgłaszane są problemy w funkcjonowaniu samych aplikacji wymieniających ruch sieciowy (dotyczy to poważnych aplikacji biznesowych jak serwer ISA, serwer SQL). Kilka z przykładowych problemów omówionych jest w punkcie odwołania. Wyniki pomiarów jednoznacznie ukazują, iż największy problem związany z obsługą ruchu sieciowego dla interfejsów 10 Gbit/s leży w ilości przerwań, generowanych przez interfejs sieciowy. Mimo dostępności rozwiązania określanego, jako Interrupt Moderation nie rozwiązuje ono wszystkich problemów. Należy niestety również wspomnieć, iż ruch sieciowy o charakterystyce jednego typu (np. segmenty TCP o wielkości 2 KB) jest sztuczny i nie odzwierciedla prawdziwego ruchu sieciowego, który składa się z segmentów TCP i pakietów UDP o bardzo zmiennej wielkości, zatem jedno rozwiązanie dobre dla małych segmentów TCP nie musi być dobre dla dużych pakietów UDP i odwrotnie. Problem tzw. strojenia interfejsu sieciowego (a właściwie stosu TCP/IP) należy, zatem wykonywać indywidulanie dla każdego serwera, każdej karty sieciowej, dla każdego systemu operacyjnego oddzielnie i dla każdej ważnej aplikacji oddzielnie. Każde z omawianych w niniejszym opracowaniu oraz analizowane rozwiązanie w ramach projektu badawczego zamawianego PBZ (grant MNiSW 02/II/2007) niestety wykazuje mimo potencjalnych zalet wiele jeszcze ukrytych i niezweryfikowanych ostatecznie przypadłości. Rozwiązania te powinny być jeszcze dogłębniej zanalizowane zaś same implementacje zdecydowanie bardziej przetestowane w wielu różnorakich środowiskach sieciowych, dla różnych serwerach, interfejsach sieciowych i dla różnych aplikacji tak, aby wyeliminować zgłaszane przez użytkowników cały czas informacje o nie do końca poprawnym działaniu danego rozszerzenia. 7. Bibliografia [1] Nowicki K., Światowiak J., Gajda B.: Problemy wdrażania protokołu IPv6, Przegląd Telekomunikacyjny 2010 [2] Nowicki K., Uhl T.: Ethernet End-to-End, Shaker Verlag, [3] Nowicki K., Woźniak J.: Przewodowe i bezprzewodowe sieci LAN, Oficyna Wydawnicza PW, [4] Nowicki K., Światowiak J.: Protokoły IPv6, Wydawnictwo PG, 2002 [5] [6] [7] [8] [9] [10] 2.aspx [11] [12] Advanced Windows Debugging Addison Wesley 2008 [13] Windows Driver Kit 6 Documents and Tools [14] The Complete guide to Windows Server 2008 Addison Wesley 2008 [15] Practical TCP/IP and Ethernet Networking - Newnes (Elsevier) 2003 [16] Windows Server 2008 TCP/IP Protocols and Services MS Press 2008 [17] Windows Server 2008 Networking and Network Access Protection (NAP) MS Press [18] Windows Internals 5 Ed - MS Press