Ekstremalna utrata pakietów UDP przy 300Mbit (14%), ale retransmisje TCP> 800Mbit bez transmisji


11

Mam skrzynkę linux, której używam jako iperf3klienta, testując 2 identycznie wyposażone skrzynki serwera Windows 2012 R2 z adapterami Broadcom BCM5721, 1 Gb (2 porty, ale tylko 1 używany do testu). Wszystkie maszyny są podłączone za pomocą jednego przełącznika 1 Gb.

Testowanie UDP przy np. 300 Mb

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

powoduje utratę 14% wszystkich wysłanych pakietów (dla drugiego serwera z tym samym sprzętem, ale starszymi sterownikami NIC, utrata wynosi około 2%), ale utrata występuje nawet przy 50 Mb, choć mniej poważnie. Wydajność TCP przy użyciu równoważnych ustawień:

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

zapewnia prędkości transmisji na północ od 800Mbit, bez zgłaszanych retransmisji.

Serwer jest zawsze uruchamiany przy użyciu następujących opcji:

iperf3 -sB192.168.30.161

Kto jest winny?

  1. Klient Linuksa (sprzęt? Sterowniki? Ustawienia?)? Edycja: Właśnie uruchomiłem test z jednego serwera Windows do drugiego, a utrata pakietów UDP przy 300 Mb była jeszcze wyższa, o 22%
  2. Okna serwera Windows (sprzęt? Sterownik? Ustawienia?)?
  3. (Pojedynczy) przełącznik, który łączy wszystkie maszyny testowe?
  4. Kable?

Edytować:

Teraz spróbowałem w innym kierunku: Windows -> Linux. Wynik: utrata pakietów zawsze wynosi 0 , podczas gdy przepustowość osiąga maksymalny poziom około

  • 840 Mb dla -l8192np. Pofragmentowanych pakietów IP
  • 250 Mb dla -l1472niefragmentowanych pakietów IP

Wydaje mi się, że przepustowość ogranicza kontrolę przepływu i zapobiega utracie pakietów. Zwłaszcza ta ostatnia, niefragmentowana liczba nie jest zbliżona do przepustowości TCP (niefragmentowany TCP daje podobne liczby do fragmentowanego TCP), ale jest to nieskończenie ogromna poprawa w stosunku do Linuksa -> Windows pod względem utraty pakietów.

I jak się dowiedzieć?

Postępowałem zgodnie ze zwykłymi zaleceniami dotyczącymi ustawień sterownika na serwerze, aby zmaksymalizować wydajność i próbowałem włączyć / wyłączyć / zmaksymalizować / zminimalizować / zmienić

  • Przerwanie moderacji
  • Kontrola przepływu
  • Buforów odbiorczych
  • RSS
  • Wake-on-LAN

Wszystkie funkcje odciążania są włączone.

Edytuj Próbowałem także włączyć / wyłączyć

  • Ethernet @ Wirespeed
  • Różne funkcje odciążania
  • Priorytet i sieć VLAN

Przy podobnych wskaźnikach strat.


Pełny wynik uruchomienia UDP:

$ iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:10:39 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522639.098587.3451f174
[  4] local 192.168.30.202 port 50851 connected to 192.168.30.161 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  33.3 MBytes   279 Mbits/sec  4262
[  4]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  4577
[  4]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  4577
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-5.00   sec   176 MBytes   296 Mbits/sec  0.053 ms  3216/22571 (14%)
[  4] Sent 22571 datagrams
CPU Utilization: local/sender 4.7% (0.4%u/4.3%s), remote/receiver 1.7% (0.8%u/0.9%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44770
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 50851
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  27.2 MBytes   226 Mbits/sec  0.043 ms  781/4261 (18%)
[  5]   1.01-2.01   sec  30.0 MBytes   252 Mbits/sec  0.058 ms  734/4577 (16%)
[  5]   2.01-3.01   sec  29.0 MBytes   243 Mbits/sec  0.045 ms  870/4578 (19%)
[  5]   3.01-4.01   sec  32.1 MBytes   269 Mbits/sec  0.037 ms  469/4579 (10%)
[  5]   4.01-5.01   sec  32.9 MBytes   276 Mbits/sec  0.053 ms  362/4576 (7.9%)

Uruchom TCP:

$ iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:13:53 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522833.505583.4078fcc1
      TCP MSS: 1448 (default)
[  4] local 192.168.30.202 port 44782 connected to 192.168.30.161 port 5201
Starting Test: protocol: TCP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 MBytes   910 Mbits/sec    0   91.9 KBytes       
[  4]   1.00-2.00   sec  97.3 MBytes   816 Mbits/sec    0   91.9 KBytes       
[  4]   2.00-3.00   sec  97.5 MBytes   818 Mbits/sec    0   91.9 KBytes       
[  4]   3.00-4.00   sec  98.0 MBytes   822 Mbits/sec    0   91.9 KBytes       
[  4]   4.00-5.00   sec  97.6 MBytes   819 Mbits/sec    0   91.9 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec   499 MBytes   837 Mbits/sec    0             sender
[  4]   0.00-5.00   sec   498 MBytes   836 Mbits/sec                  receiver
CPU Utilization: local/sender 3.5% (0.5%u/3.0%s), remote/receiver 4.5% (2.0%u/2.5%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44781
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 44782
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec                  
[  5]   1.00-2.00   sec  97.5 MBytes   818 Mbits/sec                  
[  5]   2.00-3.00   sec  97.6 MBytes   819 Mbits/sec                  
[  5]   3.00-4.00   sec  97.8 MBytes   820 Mbits/sec                  
[  5]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec                  

Odpowiedzi:


8

Nie ma problemu. Jest to normalne i oczekiwane zachowanie.

Powodem utraty pakietu jest to, że UDP nie ma żadnej kontroli przeciążenia. W tcp, gdy uruchamiają się algorytmy kontroli przeciążenia, poinformuje koniec transmisji, aby spowolnił wysyłanie, aby zmaksymalizować przepustowość i zminimalizować straty.

Jest to więc całkowicie normalne zachowanie UDP. UDP nie gwarantuje dostawy, jeśli kolejka odbiorcza jest przeciążona i zrzuci pakiety. Jeśli chcesz uzyskać wyższe prędkości transmisji dla UDP, musisz zwiększyć bufor odbioru.

Opcja -l lub --len iperf powinna załatwić sprawę. I być może docelowe ustawienie przepustowości -b na kliencie.

-l, --len n [KM] ustaw długość bufora odczytu / zapisu na n (domyślnie 8 KB)

8 KB? to trochę małe, gdy nie ma kontroli zatorów.

np. po stronie serwera.

~$ iperf -l 1M -U -s

Właśnie to mam Linuksa na Linuksa

Client connecting to ostore, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 35399 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

Ale dla UDP przy użyciu ustawień domyślnych dostaję tylko

~$ iperf -u -c ostore 
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 52898 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.027 ms    0/  893 (0%)

WT?

Po kilku eksperymentach stwierdziłem, że muszę ustawić zarówno długość, jak i docelową szerokość pasma.

~$ iperf -u -c ostore -l 8192 -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 8192 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 60237 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec
[  3] Sent 146243 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

Po stronie serwera:

~$ iperf -s -u -l 5M 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 5242880 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 36448
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec  1008 KBytes   819 Kbits/sec   0.018 ms    0/  126 (0%)
[  4] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 60237
[  4]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec   0.078 ms    0/146242 (0%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order

Aby zademonstrować utratę pakietów za pomocą małych buforów. Co szczerze mówiąc, nie jest tak ekstremalne, jak się spodziewałem. Gdzie jest niezawodne źródło iperf3, na którym mogę testować między Linux / Windows?

~$ iperf -u -c ostore -l 1K -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1024 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 45061 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   674 MBytes   565 Mbits/sec
[  3] Sent 689777 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Po stronie serwera:

~$ iperf -s -u -l 1K 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1024 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 45061
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Czy przeglądałeś również plik Readme strony iperf3 na github ?

Znane problemy

Wydajność UDP: Zauważono pewne problemy z iperf3 na platformie testowej ESnet 100G przy wysokich prędkościach UDP (powyżej 10 Gb / s). Objawem jest to, że przy każdym uruchomieniu iperf3 odbiornik zgłasza współczynnik strat około 20%, niezależnie od opcji -b użytej po stronie klienta. Wydaje się, że ten problem nie jest związany z iperf3 i może być spowodowany umieszczeniem procesu iperf3 na procesorze i jego relacją z przychodzącą kartą sieciową. W niektórych przypadkach problem ten można złagodzić poprzez odpowiednie użycie opcji powinowactwa procesora (-A). (Numer 55)

Używasz wolniejszej karty sieciowej, ale zastanawiam się, czy jest ona powiązana.


Tak, a jeśli chodzi o utratę pakietów, pokażę ci, jak to się może stać. aktualizacja odpowiedzi.
Matt

Dzięki Matt, właśnie widziałem twoją aktualizację. Mój iperf (zarówno na serwerze Windows, jak i kliencie Linux) to wersja 2.0.5. Co twoje?
Eugene Beresovsky

To samo. I faktycznie, kiedy ustawię docelową przepustowość na 1G, dostaję przepustowość bonkas 14756449370562973696 Bajtów / s i inne takie uszkodzone dane wyjściowe. Więc myślę, że prawdopodobnie jest zepsuty. Nadal myślę, że problemami są bufory ... Wiem, że Windows robi kilka niezwykłych rzeczy z buforowaniem TCP i UDP.
Matt

Dziwne. Później dzisiaj zapewne uzyskam dostęp do dobrego środowiska produkcyjnego 10G i wypuszczę iperf3 na tym. Zobaczmy, jak to idzie.
Eugene Beresovsky

1
Myślę, że źle rozumiesz, co -lrobi przełącznik. Nie ustawia rozmiaru bufora; ustawia rozmiar pakietu. Jest to ilość danych, które iperf3 zapisze w gnieździe za jednym razem i odczyta z gniazda za jednym razem. Możesz ustawić rozmiar bufora gniazda za pomocą -w. Jeśli spojrzysz na źródło, zobaczysz, że wywołuje, setsockopt()aby ustawić rozmiar bufora gniazda na cokolwiek podałeś po -w.
András Korn,

0

Całkowicie przegapiłeś najbardziej oczywistego winowajcę - adaptery, a następnie sterowniki (stwierdzasz, że użycie innej wersji sterowników daje inne wyniki).

Spróbuj wyłączyć wszystkie funkcje odciążania.


To nie pomogło - pytanie odpowiednio zaktualizowane.
Eugene Beresovsky
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.