Pérdida extrema de paquetes UDP a 300Mbit (14%), pero TCP> 800Mbit sin retransmisiones

11

Tengo una caja de Linux que uso como iperf3cliente, probando 2 cajas de servidor Windows 2012 R2 con equipos idénticos con Broadcom BCM5721, adaptadores de 1 Gb (2 puertos, pero solo 1 usado para la prueba). Todas las máquinas están conectadas a través de un solo interruptor de 1 Gb.

Prueba de UDP a, por ejemplo, 300Mbit

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

da como resultado la pérdida del 14% de todos los paquetes enviados (para la otra caja del servidor con exactamente el mismo hardware, pero los controladores NIC más antiguos, la pérdida es de alrededor del 2%), pero la pérdida ocurre incluso a 50 Mbit, aunque con menos severidad. Rendimiento TCP utilizando configuraciones equivalentes:

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

produce velocidades de transmisión al norte de 800Mbit, sin retransmisiones reportadas.

El servidor siempre se inicia utilizando las siguientes opciones:

iperf3 -sB192.168.30.161

¿De quien es la culpa?

  1. ¿La caja del cliente de Linux (hardware, controladores, configuración?) Editar: acabo de ejecutar la prueba de una caja de servidor de Windows a la otra y la pérdida de paquetes UDP a 300Mbit fue aún mayor, al 22%
  2. ¿Las cajas del servidor de Windows (hardware, controlador, configuración)?
  3. ¿El interruptor (único) que conecta todas las máquinas de prueba?
  4. Cables?

Editar:

Ahora probé la otra dirección: Windows -> Linux. Resultado: la pérdida de paquetes siempre es 0 , mientras que el rendimiento se maximiza alrededor de

  • 840Mbit para -l8192, es decir, paquetes IP fragmentados
  • 250Mbit para -l1472paquetes IP no fragmentados

Supongo que el control de flujo limita el rendimiento y evita la pérdida de paquetes. Especialmente el último, la cifra no fragmentada no está cerca del rendimiento del TCP (el TCP no fragmentado produce cifras similares al TCP fragmentado), pero es una mejora infinitamente enorme sobre Linux -> Windows en términos de pérdida de paquetes.

¿Y cómo averiguarlo?

Seguí los consejos habituales para la configuración del controlador en el servidor para maximizar el rendimiento e intenté habilitar / deshabilitar / maximizar / minimizar / cambiar

  • Moderación de interrupción
  • Control de flujo
  • Recibir tampones
  • RSS
  • Activación de la LAN

Todas las funciones de descarga están habilitadas.

Editar También intenté habilitar / deshabilitar

  • Ethernet @ velocidad del cable
  • Las diversas funciones de descarga
  • Prioridad y VLAN

Con tasas de pérdida similares.

La salida completa de una ejecución 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%)

TCP ejecutado:

$ 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
performance tcp udp packetloss iperf Eugene Beresovsky
fuente

Respuestas:

8

No hay ningún problema. Este es un comportamiento normal y esperado.

La razón de la pérdida de paquetes es que UDP no tiene ningún control de congestión. En tcp, cuando se activan los algoritmos de control de congestión, le indicará al final de la transmisión que disminuya la velocidad del envío para maximizar el rendimiento y minimizar la pérdida.

Entonces, este es un comportamiento completamente normal para UDP en realidad. UDP no garantiza la entrega si la cola de recepción está sobrecargada y descartará los paquetes. Si desea velocidades de transmisión más altas para UDP, necesita aumentar su búfer de recepción.

La opción -l o --len iperf debería hacer el truco. Y posiblemente la configuración de ancho de banda de destino -b en el cliente.

-l, --len n [KM] establece la longitud del búfer de lectura / escritura en n (predeterminado 8 KB)

8KB ?? eso es un poco pequeño cuando no hay control de congestión.

Por ejemplo, en el lado del servidor.

~$ iperf -l 1M -U -s

Esto es lo que llevo Linux a 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

Pero para UDP usando la configuración predeterminada solo obtengo

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

Después de experimentar un poco, descubrí que tenía que establecer tanto la longitud como el objetivo del ancho 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 del 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 demostrar la pérdida de paquetes con pequeños tampones. Lo que para ser honesto no es tan extremo como esperaba. ¿Dónde hay una fuente confiable para iperf3 que pueda probar entre 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 del 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

¿También ha mirado el archivo léame de la página iperf3 github ?

Problemas conocidos

Rendimiento UDP: se han notado algunos problemas con iperf3 en el banco de pruebas ESnet 100G a altas velocidades UDP (por encima de 10 Gbps). El síntoma es que en cualquier ejecución particular de iperf3, el receptor informa una tasa de pérdida de aproximadamente el 20%, independientemente de la opción -b utilizada en el lado del cliente. Este problema parece no ser específico de iperf3 y puede deberse a la ubicación del proceso de iperf3 en una CPU y su relación con la NIC entrante. En algunos casos, este problema puede mitigarse mediante el uso apropiado de la opción de afinidad de CPU (-A). (Problema # 55)

Estás utilizando una NIC más lenta pero me pregunto si está relacionada.

Mate
fuente
Sí, y en cuanto a la pérdida de paquetes, te mostraré cómo puede suceder esto. actualización de respuesta
Matt
Gracias Matt, acabo de ver tu actualización. Mi iperf (tanto en el servidor de Windows como en el cliente de Linux) es la versión 2.0.5. ¿Lo que es tuyo?
Eugene Beresovsky,
Lo mismo. Y, de hecho, cuando configuro el ancho de banda objetivo en 1G, obtengo tasas de ancho de banda bonkas de 14756449370562973696 Bytes / seg y otros resultados corruptos. Así que creo que probablemente esté roto. Aún así, creo que los problemas son búferes ... Sé que Windows hace algunas cosas inusuales con el búfer TCP y UDP.
Matt
Extraño. Más tarde hoy probablemente tendré acceso a un buen entorno de producción de 10G y dejaré ir iperf3 en ese. Veamos cómo va eso.
Eugene Beresovsky,
1
Creo que no entiendes lo que hace el -linterruptor. No establece el tamaño del búfer; Establece el tamaño del paquete. Esta es la cantidad de datos que iperf3 escribirá en el socket de una vez y leerá desde el socket de una vez. Puede establecer el tamaño del búfer de socket usando -w. Si observa la fuente, verá que llama setsockopt()para establecer el tamaño del búfer de socket a lo que especificó después -w.
András Korn
0

Te perdiste por completo al culpable más obvio: los adaptadores y luego los controladores (afirmas que usar una versión diferente de los controladores produce resultados diferentes).

Intente desactivar todas las capacidades de descarga.

Dani_l
fuente
Eso no ayudó: la pregunta se actualizó en consecuencia.
Eugene Beresovsky