Perda de pacotes UDP extrema a 300Mbit (14%), mas TCP 800Mbit sem retransmissão

10

Eu tenho uma caixa de linux que eu uso como o cliente iperf3 , testando 2 caixas do servidor Windows 2012 R2 equipadas de forma idêntica com adaptadores Broadcom BCM5721, 1Gb (2 portas, mas apenas 1 usado para o teste). Todas as máquinas estão conectadas por meio de um único switch de 1 Gb.

Teste de UDP por ex. 300Mbit

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

resulta na perda de 14% de todos os pacotes enviados (para a outra caixa do servidor com exatamente o mesmo hardware, mas drivers mais antigos da NIC, a perda é de cerca de 2%), mas a perda ocorre mesmo a 50Mbit, embora com menos severidade. Desempenho TCP usando configurações equivalentes:

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

produz velocidades de transmissão ao norte de 800Mbit, sem retransmissões relatadas.

O servidor é sempre iniciado usando as seguintes opções:

iperf3 -sB192.168.30.161

Quem é o culpado?

  1. A caixa do cliente linux (configurações de hardware? drivers?)? Editar: Acabei de executar o teste de uma caixa do servidor do Windows para o outro e a perda de pacotes UDP a 300 Mbit foi ainda maior, com 22%
  2. As caixas do servidor do Windows (configurações do hardware? driver?)?
  3. O comutador (único) que conecta todas as máquinas de teste?
  4. Cabos?

Editar:

Agora tentei a outra direção: Windows - > Linux. Resultado: perda de pacotes sempre 0 , enquanto a taxa de transferência atinge o máximo

  • 840 Mbit para -l8192 , ou seja, pacotes IP fragmentados
  • 250Mbit para -l1472 , pacotes IP não fragmentados

Acho que o controle de fluxo reduz a taxa de transferência e evita a perda de pacotes. Especialmente este último, figura não fragmentada está longe de TCP throughput (TCP não fragmentado produz números semelhantes ao TCP fragmentado), mas é uma melhoria infinitamente enorme sobre o Linux - > Windows em termos de perda de pacotes.

E como descobrir?

Eu segui os conselhos usuais para configurações de driver no servidor para maximizar o desempenho e tentei ativar / desativar / maximizar / minimizar / alterar

  • Moderação de interrupção
  • Controle de fluxo
  • Receber buffers
  • RSS
  • Wake-on-LAN

Todos os recursos de descarregamento estão ativados.

Editar Eu também tentei ativar / desativar

  • Ethernet @ Wirespeed
  • Os vários recursos de transferência
  • Prioridade e VLAN

Com taxas de perda semelhantes.

A saída completa de uma execução do 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%)

Execução 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                  
    
por Eugene Beresovsky 13.05.2015 / 15:32

2 respostas

8

Não há problema. Este é um comportamento normal e esperado.

O motivo da perda de pacotes é que o UDP não possui controle de congestionamento. No tcp, quando os algoritmos de controle de congestionamento entram em ação, ele informará ao final da transmissão para retardar o envio, a fim de maximizar o rendimento e minimizar a perda.

Portanto, este é um comportamento totalmente normal para o UDP. O UDP não garante a entrega se a fila de recebimento estiver sobrecarregada e descartará pacotes. Se você quer taxas de transmissão mais altas para UDP, você precisa aumentar seu buffer de recebimento.

A opção -l ou --len iperf deve fazer o truque. E possivelmente a configuração de largura de banda de destino -b no cliente.

-l, --len n[KM] set length read/write buffer to n (default 8 KB)

8KB ?? isso é um pouco pequeno quando não há controle de congestionamento.

por exemplo. no lado do servidor.

~$ iperf -l 1M -U -s

Isto é o que eu tenho Linux para Linux

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

Mas para UDP usando as configurações padrão eu recebo somente

~$ 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?

Depois de algumas experiências, descobri que precisava definir o comprimento e a meta de largura de banda.

~$ 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.

Lado do servidor:

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

Para demonstrar a perda de pacotes com pequenos buffers. O que para ser honesto não é tão extremo quanto eu esperava. Onde é uma fonte confiável para iperf3 eu posso testar entre o 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

Lado do servidor:

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

Você também analisou a página do github iperf3 ?

Known Issues

UDP performance: Some problems have been noticed with iperf3 on the ESnet 100G testbed at high UDP rates (above 10Gbps). The symptom is that on any particular run of iperf3 the receiver reports a loss rate of about 20%, regardless of the -b option used on the client side. This problem appears not to be iperf3-specific, and may be due to the placement of the iperf3 process on a CPU and its relation to the inbound NIC. In some cases this problem can be mitigated by an appropriate use of the CPU affinity (-A) option. (Issue #55)

Você está usando um NIC mais lento, mas gostaria de saber se ele está relacionado.

    
por 14.05.2015 / 03:33
0

Você perdeu completamente o culpado mais óbvio - os adaptadores e, em seguida, os drivers (você afirma que usar drivers de versão diferentes produz resultados diferentes).

Tente desativar todos os recursos de transferência.

    
por 13.05.2015 / 15:51