Wifi TCP iperf throughput: 1 stream vs multiple streams?

Em um teste de taxa de transferência TCP WLAN iperf TCP, vários fluxos paralelos me proporcionam uma taxa de transferência superior a 1 fluxo. Tentei aumentar o tamanho da janela TCP, mas ainda não consigo atingir a taxa de transferência máxima com apenas 1 fluxo. Há algo mais na camada TCP que está impedindo que a capacidade total do link seja usada?

— elin05
fonte

Quanta diferença você observa? Idealmente, se um fluxo TCP fornecer uma taxa de transferência de T, dois deverão fornecer uma taxa de transferência de T / 2 cada.

— Dilsh Pandey

Observe que a capacidade total do link, independentemente do número de fluxos, nunca será alcançada. O IPv4 com cabeçalhos [IP + TCP] mínimos produzirá ~ 95% de eficiência do canal. Veja a excelente publicação de Sobrecarga de protocolo em sd.wareonearth.com/~phil/net/overhead .

— generalnetworkerror

@ManojPandey, eu não estou certo de que ele está vendo um caso ideal ... especialmente porque ele está usando wi-fi ... Eu suspeito que ele tem alguma perda de pacotes ...

— Mike Pennington

O TCP é péssimo por Wi-Fi, lide com isso. Se você precisar usá-lo e estiver vendo perdas de pacotes da camada 3, sugiro aumentar a contagem máxima de novas tentativas da camada 2, pois o TCP não foi projetado para lidar com links com perdas sem destruir o desempenho.

— BatchyX

Em um teste de taxa de transferência TCP WLAN iperf TCP, vários fluxos paralelos me proporcionam uma taxa de transferência superior a 1 fluxo. Tentei aumentar o tamanho da janela TCP, mas ainda não consigo atingir a taxa de transferência máxima com apenas 1 fluxo. Há algo mais na camada TCP que está impedindo que a capacidade total do link seja usada?

Na minha experiência, se você ver resultados significativamente diferentes entre 1 fluxo TCP e vários fluxos TCP, o problema normalmente é perda de pacotes; portanto, a "outra coisa" na camada TCP é a retransmissão (devido à perda de pacotes na camada inferior).

Um exemplo que eu criei para ilustrar como a perda de pacotes afeta a taxa de transferência de fluxo único ...

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

Esta é uma tabela que resume os resultados de um teste de 60 segundos iperfentre um cliente e servidor ... você pode ver uma pequena variação nos resultados do iperf do jitter RTT (ou seja, desvio padrão maior do RTT); no entanto, a diferença mais significativa ocorreu quando simulei 2% de perda, deixando o cliente conectado à NIC. 172.16.1.56 e 172.16.1.80 são o mesmo laptop (executando o Ubuntu). O servidor é 172.16.1.5, executando o Debian. Eu usei o netem na NIC com fio do cliente para simular a perda de pacotes ...

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

EDIT para respostas aos comentários :

Você pode explicar o que está acontecendo no último cenário (1000BaseT, 5 fluxos, perda de 2,0%)? Mesmo que haja perda de pacotes, a taxa de transferência total ainda está saturada em 937 Mbits / s.

A maioria das implementações de TCP diminui sua janela de congestionamento quando a perda de pacotes é detectada. Como estamos usando o netem para forçar 2% de perda de pacotes do cliente para o servidor, alguns dos dados do cliente são descartados. O efeito líquido do netem neste exemplo é uma taxa de transmissão média de fluxo único de 730 Mbps. Adicionar múltiplos fluxos significa que os fluxos TCP individuais podem trabalhar juntos para saturar o link.

Meu objetivo é alcançar a maior taxa de transferência TCP possível através de WiFi. Pelo que entendi, devo aumentar o número de fluxos para combater a diminuição na taxa de transferência causada pela perda de pacotes. Isso está correto?

sim

Além disso, em que ponto muitos fluxos começarão a impactar negativamente a taxa de transferência? Isso seria causado por memória limitada e / ou poder de processamento?

Eu realmente não posso responder isso sem mais experimentos, mas para os links 1GE, nunca tive um problema em saturar um link com 5 fluxos paralelos. Para ter uma idéia de como o TCP é escalável, os servidores Linux podem manipular mais de 1500 soquetes TCP simultâneos nas circunstâncias certas. Essa é outra discussão da SO que é relevante para dimensionar soquetes TCP simultâneos, mas, na minha opinião, qualquer coisa acima de 20 soquetes paralelos seria um exagero se você estiver apenas tentando saturar um link.

Devo ter um mal-entendido de que o iperf usa o tamanho da janela -w no máximo, pois parece que você está dizendo que cresceu além desse valor inicial de 21K

Eu não usei iperf -w, então acho que há um mal-entendido. Como você tem muitas perguntas sobre o caso do wifi, estou incluindo um gráfico wireshark da taxa de transferência TCP para o caso de fluxo TCP único do wifi.

Taxa de transferência de fluxo único TCP Wifi

Dados de teste

Também estou incluindo dados brutos de teste, caso você queira ver como eu medi essas coisas ...

802.11g, 1 fluxo 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 fluxos 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 Stream, perda de 0,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                 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 fluxos, perda de 0,0%

[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 fluxos, perda de 2,0%

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 fluxos, perda de 2,0%

[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:~$

Remover simulação de perda de pacotes

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

— Mike Pennington
fonte

Você pode explicar o que está acontecendo no último cenário (1000BaseT, 5 fluxos, perda de 2,0%)? Mesmo que haja perda de pacotes, a taxa de transferência total ainda está saturada em 937 Mbits / s. Meu objetivo é alcançar a maior taxa de transferência TCP possível através de WiFi. Pelo que entendi, devo aumentar o número de fluxos para combater a diminuição na taxa de transferência causada pela perda de pacotes. Isso está correto? Além disso, em que ponto muitos fluxos começarão a impactar negativamente a taxa de transferência? Isso seria causado por memória limitada e / ou poder de processamento?

— Elin05 17/09/2013

@ elin05: A utilização de múltiplos fluxos espalha a perda de pacotes em vários fluxos; assim, quando ocorre uma perda de pacotes, apenas um fluxo reduz o tamanho da sua janela TCP, deixando os outros fluxos inalterados.

— BatchyX 18/09/2013

O BDP 802.11g (54 Mbps) não exige um tamanho de janela de 54 KB com um atraso de 8 ms (16 ms RTT / 2) para manter o cano cheio com pacotes de bordo? Qual é o tamanho da janela no lado do servidor?

— generalnetworkerror

@generalnetworkerror, as janelas TCP não são estáticas ... elas mudam com base nas necessidades do TCP ... durante essa captura, o tamanho máximo de janela anunciado pelo tsunami era de 1177600 bytes; A janela média do tsunami foi de 1045083 bytes e o RTT médio naquele teste de 60 segundos foi de 32,2ms.

— 9118 Mike Pennington

@ MikePennington: Devo ter um mal-entendido de que o iperf usa o tamanho da janela -w no máximo, pois parece que você está dizendo que cresceu além desse valor inicial de 21 mil.

— generalnetworkerror

Aqui está o cálculo para a taxa de transferência máxima de um único fluxo TCP.

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

Portanto, você tem um gargalo e a latência desempenha um papel importante.

— James.Birmingham
fonte

Provavelmente é devido a vários processos versus um processo. com o iperf 2.0.9, é possível testar isso via -P 2 no cliente. Isso irá bifurcar dois threads em vez de um. As CPUs mais modernas têm vários núcleos, portanto, o uso de vários threads poderá aproveitá-los.

— rjmcmahon
fonte