Przepustowość iperf TCP Wi-Fi: 1 strumień czy wiele strumieni?

W teście przepustowości WLAN iperf TCP wiele równoległych strumieni da mi większą przepustowość niż 1 strumień. Próbowałem zwiększyć rozmiar okna TCP, ale nadal nie mogę osiągnąć maksymalnej przepustowości za pomocą tylko 1 strumienia. Czy w warstwie TCP jest coś jeszcze, co uniemożliwia wykorzystanie pełnej przepustowości łącza?

— elin05
źródło

Jaką różnicę obserwujesz? Idealnie, jeśli jeden strumień TCP zapewnia przepustowość T, wówczas dwa powinny indywidualnie zapewniać przepustowość T / 2 każdy.

— Manoj Pandey,

Należy pamiętać, że pełna przepustowość łącza niezależnie od liczby strumieni nigdy nie zostanie osiągnięta. IPv4 z minimalnymi nagłówkami [IP + TCP] zapewni ~ 95% wydajności kanału. Zobacz doskonałą publikację protokołu na stronie sd.wareonearth.com/~phil/net/overhead .

— generalnetworkerror,

@ManojPandey, nie jestem pewien, czy widzi idealny przypadek ... zwłaszcza, że korzysta z Wi-Fi ... Podejrzewam, że ma utratę pakietów ...

— Mike Pennington

TCP jest do bani przez Wi-Fi, załatw to. Jeśli musisz go użyć i widzisz straty pakietów warstwy 3, sugerowałbym zwiększenie maksymalnej liczby ponownych prób warstwy 2, ponieważ TCP nie jest zaprojektowany do obsługi stratnych łączy bez niszczenia wydajności.

— BatchyX 18.09.13

W teście przepustowości WLAN iperf TCP wiele równoległych strumieni da mi większą przepustowość niż 1 strumień. Próbowałem zwiększyć rozmiar okna TCP, ale nadal nie mogę osiągnąć maksymalnej przepustowości za pomocą tylko 1 strumienia. Czy w warstwie TCP jest coś jeszcze, co uniemożliwia wykorzystanie pełnej przepustowości łącza?

Z mojego doświadczenia wynika, że jeśli widzisz znacząco różne wyniki między 1 strumieniem TCP a wieloma strumieniami TCP, zwykle problem polega na utracie pakietów; więc „czymś innym” w warstwie TCP jest retransmisja (z powodu utraty pakietów niższej warstwy).

Przykład, który przygotowałem, aby zilustrować wpływ utraty pakietów na przepustowość pojedynczego strumienia ...

                   [Wifi||LAN-0.0%-Loss||LAN-2.0%-Loss]
+--------------+                                        +--------------+
|              |                                        |              |
| Thinkpad-T61 |----------------------------------------| Linux Server |
|              |                                        | Tsunami      |
+--------------+                                        +--------------+
iperf client             ------------------>            iperf server
                             Pushes data

To jest tabela, która podsumowuje wyniki 60-sekundowego iperftestu między klientem a serwerem ... możesz zobaczyć niewielką zmienność wyników iperf z jittera RTT (tj. Wyższe odchylenie standardowe RTT); jednak najbardziej znacząca różnica pojawiła się, gdy zasymulowałem 2% straty, pozostawiając przewodową kartę sieciową klienta. 172.16.1.56 i 172.16.1.80 to ten sam laptop (z systemem Ubuntu). Serwer to 172.16.1.5 z uruchomionym Debianem. Użyłem netem na przewodowej karcie sieciowej klienta do symulacji utraty pakietów ...

Client IP       Transport    Loss     avg RTT    RTT StdDev    TCP Streams   Tput
-----------     ----------   ----     -------    ----------    -----------   ----------
172.16.1.56     802.11g      0.0%      0.016s          42.0              1     19.5Mbps
172.16.1.56     802.11g      0.0%      0.016s          42.0              5     20.5Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              1    937  Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              5    937  Mbps
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              1    730  Mbps <---
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              5    937  Mbps

EDYCJA odpowiedzi na komentarze :

Czy możesz wyjaśnić, co dzieje się w ostatnim scenariuszu (1000BaseT, 5 strumieni, 2,0% straty)? Mimo utraty pakietów łączna przepustowość jest nadal nasycona przy 937 Mb / s.

Większość implementacji TCP zmniejsza okno przeciążenia po wykryciu utraty pakietu. Ponieważ używamy Netem, aby wymusić utratę 2% pakietów od klienta do serwera, niektóre dane klienta są usuwane . Efekt netto netem w tym przykładzie to średnia szybkość transmisji pojedynczego strumienia wynosząca 730 Mb / s. Dodanie wielu strumieni oznacza, że poszczególne strumienie TCP mogą ze sobą współpracować, aby nasycić łącze.

Moim celem jest osiągnięcie najwyższej możliwej przepustowości TCP przez WiFi. Jak rozumiem, powinienem zwiększyć liczbę strumieni, aby przeciwdziałać spadkowi przepustowości spowodowanemu utratą pakietów. Czy to jest poprawne?

tak

Ponadto, w którym momencie zbyt wiele strumieni zacznie negatywnie wpływać na przepustowość? Czy byłoby to spowodowane ograniczoną pamięcią i / lub mocą obliczeniową?

Naprawdę nie potrafię odpowiedzieć na to pytanie bez dalszych eksperymentów, ale dla łączy 1GE nigdy nie miałem problemu z nasyceniem łącza 5 równoległymi strumieniami. Aby dać ci wyobrażenie o tym, jak skalowalny jest TCP, serwery linux mogą obsłużyć ponad 1500 jednoczesnych gniazd TCP we właściwych okolicznościach. To kolejna dyskusja SO, która dotyczy skalowania równoczesnych gniazd TCP, ale moim zdaniem wszystko powyżej 20 gniazd równoległych byłoby przesadzone, jeśli tylko próbujesz nasycić łącze.

Muszę mieć nieporozumienie, że iperf używa maksymalnego rozmiaru okna -w, ponieważ brzmi to tak, jakbyś powiedział, że wzrósł powyżej tej początkowej wartości 21K

Nie korzystałem iperf -w, więc myślę, że istnieje nieporozumienie. Ponieważ masz tak wiele pytań na temat przypadku Wi-Fi, dołączam wykres Wireshark przepustowości TCP dla przypadku pojedynczego strumienia Wi-Fi TCP.

Przepustowość pojedynczego strumienia Wi-Fi TCP

Dane testowe

Podaję również surowe dane testowe, na wypadek gdybyś chciał zobaczyć, jak mierzyłem te rzeczy ...

802.11g, 1 strumień TCP

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
  --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.8  16.0   0.7 189.4  42.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9000 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9000 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9000
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 40376 connected with 172.16.1.5 port 9000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.1 sec   139 MBytes  19.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

802.11g, 5 strumieni TCP

[mpenning@tsunami]$ iperf -s -p 9001 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9001 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 37162 connected with 172.16.1.5 port 9001
[  5] local 172.16.1.56 port 37165 connected with 172.16.1.5 port 9001
[  7] local 172.16.1.56 port 37167 connected with 172.16.1.5 port 9001
[  4] local 172.16.1.56 port 37163 connected with 172.16.1.5 port 9001
[  6] local 172.16.1.56 port 37166 connected with 172.16.1.5 port 9001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  28.0 MBytes  3.91 Mbits/sec
[  5]  0.0-60.1 sec  28.8 MBytes  4.01 Mbits/sec
[  4]  0.0-60.3 sec  28.1 MBytes  3.91 Mbits/sec
[  6]  0.0-60.4 sec  34.0 MBytes  4.72 Mbits/sec
[  7]  0.0-61.0 sec  30.5 MBytes  4.20 Mbits/sec
[SUM]  0.0-61.0 sec   149 MBytes  20.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 strumień, 0,0% straty

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
>   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9002 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9002 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9002
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 49878 connected with 172.16.1.5 port 9002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.54 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 strumieni, 0,0% straty

[mpenning@tsunami]$ iperf -s -p 9003 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9003 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9003
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 47047 connected with 172.16.1.5 port 9003
[  3] local 172.16.1.80 port 47043 connected with 172.16.1.5 port 9003
[  4] local 172.16.1.80 port 47044 connected with 172.16.1.5 port 9003
[  5] local 172.16.1.80 port 47045 connected with 172.16.1.5 port 9003
[  6] local 172.16.1.80 port 47046 connected with 172.16.1.5 port 9003
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  5]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  3]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[  7]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 strumienie, 2,0% straty

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 1.7%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9004 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9004 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9004
TCP window size: 42.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 48910 connected with 172.16.1.5 port 9004
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-64.1 sec  5.45 GBytes   730 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 strumieni, 2,0% straty

[mpenning@tsunami]$ iperf -s -p 9005 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9005 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9005
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 50616 connected with 172.16.1.5 port 9005
[  3] local 172.16.1.80 port 50613 connected with 172.16.1.5 port 9005
[  5] local 172.16.1.80 port 50614 connected with 172.16.1.5 port 9005
[  4] local 172.16.1.80 port 50612 connected with 172.16.1.5 port 9005
[  6] local 172.16.1.80 port 50615 connected with 172.16.1.5 port 9005
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.74 GBytes   250 Mbits/sec
[  7]  0.0-60.0 sec   711 MBytes  99.3 Mbits/sec
[  4]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.59 GBytes   228 Mbits/sec
[  5]  0.0-60.0 sec  1.24 GBytes   177 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

Usuń symulację utraty pakietów

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root

— Mike Pennington
źródło

Czy możesz wyjaśnić, co dzieje się w ostatnim scenariuszu (1000BaseT, 5 strumieni, 2,0% straty)? Mimo utraty pakietów łączna przepustowość jest nadal nasycona przy 937 Mb / s. Moim celem jest osiągnięcie najwyższej możliwej przepustowości TCP przez WiFi. Jak rozumiem, powinienem zwiększyć liczbę strumieni, aby przeciwdziałać spadkowi przepustowości spowodowanemu utratą pakietów. Czy to jest poprawne? Ponadto, w którym momencie zbyt wiele strumieni zacznie negatywnie wpływać na przepustowość? Czy byłoby to spowodowane ograniczoną pamięcią i / lub mocą obliczeniową?

— elin05

@ elin05: Używanie wielu strumieni rozkłada utratę pakietów na kilka strumieni, więc gdy nastąpi utrata pakietów, tylko jeden strumień zmniejszy rozmiar swojego okna TCP, pozostawiając niezmienione inne strumienie.

— BatchyX 18.09.13

Czy protokół BDP 802.11g (54 Mb / s) nie wymaga okna o rozmiarze 54 KB z opóźnieniem 8 ms (16 ms RTT / 2) w celu utrzymania pełnej przepustowości pakietów podczas lotu? Jaki jest rozmiar okna po stronie serwera?

— generalnetworkerror,

@generalnetworkerror, okna TCP nie są statyczne ... zmieniają się w zależności od potrzeb TCP ... podczas tego przechwytywania maksymalny rozmiar okna reklamowanego przez Tsunami wynosił 1177600 bajtów; Średnie okno Tsunami wynosi 1045083 bajtów, a średni czas RTT w tym 60-sekundowym teście wynosił 32,2 ms.

— Mike Pennington

@MikePennington: Muszę mieć nieporozumienie, że iperf używa maksymalnego rozmiaru okna -w, ponieważ brzmi to tak, jakbyś powiedział, że wzrósł powyżej tej początkowej wartości 21K.

— generalnetworkerror 24.09.2013

Oto obliczenie maksymalnej przepustowości pojedynczego strumienia TCP.

(TCP Window [bytes]/RTT[seconds]) * 8 [bits/byte] = Max single tcp throughput in (bps)

Więc masz wąskie gardło i opóźnienia odgrywają dużą rolę.

— James.Birmingham
źródło

Prawdopodobnie wynika to z wielu procesów vs. jednego procesu. w iperf 2.0.9 można to przetestować przez -P 2 na kliencie. Spowoduje to rozwidlenie dwóch wątków zamiast jednego. Większość współczesnych procesorów ma wiele rdzeni, więc użycie wielu wątków będzie w stanie je wykorzystać.

— rjmcmahon
źródło