Iperf: comportamiento extraño de desajuste UDP FUERA DE ORDEN

Esto significa que el servidor iperf3 está recibiendo los paquetes de prueba UDP en un orden diferente al que fueron enviados desde el cliente iperf3. Puede haber una variedad de explicaciones para este fenómeno, desde paquetes que toman diferentes rutas a través de la red hasta errores en los controladores de red.

Se necesitará más información para que alguien le ayude a diagnosticar el problema. Si toma un rastreo de paquete (digamos usando tcpdump) en el destino, podría decodificar los números de secuencia iperf3 en los paquetes y ver si los paquetes habían llegado intactos, fuera de orden, etc.

¿Podría haber un enlace vinculado o una NIC vinculada? Eso a menudo conduce a paquetes fuera de servicio.

Además, vea si 3.1.6 lo corrige.

@ bmah888 :

Dado que UDP como protocolo no garantiza que los paquetes lleguen en el mismo orden en que se envían, ¿por qué los paquetes fuera de orden se cuentan como paquetes "perdidos" en la salida de estadísticas?

Por ejemplo, en la salida de prueba UDP a continuación, usando la última confirmación f1415a0d98b de iperf en ambos extremos y usando el comando iperf3 -R -u --get-server-output -b 4M -c <my_server_hostname> , hay varios mensajes "FUERA DE ORDEN", ​​e inmediatamente después, esos paquetes fuera de orden son informado como paquetes perdidos (por ejemplo, 2/342 ). ¿Por qué se cuentan como perdidos? Esto es UDP, por lo que los paquetes fuera de orden son algo que puede suceder en circunstancias totalmente normales.

Connecting to host xxx, port 5201
Reverse mode, remote host xxx is sending
[  4] local 192.168.1.110 port 56316 connected to yyy port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec   510 KBytes  4.18 Mbits/sec  1.091 ms  0/358 (0%)
iperf3: OUT OF ORDER - incoming packet = 537 and received packet = 538 AND SP = 4
[  4]   1.00-2.00   sec   489 KBytes  4.01 Mbits/sec  1.111 ms  1/343 (0.29%)
[  4]   2.00-3.00   sec   488 KBytes  3.99 Mbits/sec  0.439 ms  0/342 (0%)
[  4]   3.00-4.00   sec   489 KBytes  4.01 Mbits/sec  1.150 ms  0/343 (0%)
iperf3: OUT OF ORDER - incoming packet = 1562 and received packet = 1563 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1581 and received packet = 1582 AND SP = 4
[  4]   4.00-5.00   sec   488 KBytes  3.99 Mbits/sec  1.397 ms  2/342 (0.58%)
iperf3: OUT OF ORDER - incoming packet = 2002 and received packet = 2004 AND SP = 4
[  4]   5.00-6.00   sec   488 KBytes  4.00 Mbits/sec  1.180 ms  1/342 (0.29%)
[  4]   6.00-7.00   sec   489 KBytes  4.01 Mbits/sec  0.753 ms  0/343 (0%)
[  4]   7.00-8.00   sec   489 KBytes  4.01 Mbits/sec  0.989 ms  0/343 (0%)
[  4]   8.00-9.00   sec   488 KBytes  3.99 Mbits/sec  2.294 ms  0/342 (0%)
[  4]   9.00-10.00  sec   486 KBytes  3.98 Mbits/sec  1.401 ms  0/341 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.06  sec  4.80 MBytes  4.00 Mbits/sec  0.000 ms  0/3445 (0%)  sender
[SUM]  0.0-10.1 sec  4 datagrams received out-of-order
[  4]   0.00-10.00  sec  4.80 MBytes  4.02 Mbits/sec  1.361 ms  4/3445 (0.12%)  receiver

Server output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from zzz, port 35815
[  6] local yyy port 5201 connected to zzz port 39455
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  6]   0.00-1.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   1.00-2.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   2.00-3.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   3.00-4.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   4.00-5.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   5.00-6.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   6.00-7.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   7.00-8.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   8.00-9.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   9.00-10.00  sec   489 KBytes  4.01 Mbits/sec  343
[  6]  10.00-10.06  sec  28.5 KBytes  4.01 Mbits/sec  20
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-10.06  sec  4.80 MBytes  4.00 Mbits/sec  0.000 ms  0/3445 (0%)  sender


iperf Done.

@AndrewJDR : Para ser totalmente honesto, no estoy seguro de por qué está contando los errores de la forma en que está. El código en cuestión se escribió antes de que comenzara a trabajar en este proyecto, o incluso antes de unirme a ESnet.

Mi suposición (y eso es todo) es que si se intercambiaran dos paquetes, entonces parece haber una brecha en los números de secuencia recibidos, que se cuenta (erróneamente) como una pérdida. En otras palabras, si los paquetes se enviaron en el orden ABCD pero se recibieron en el orden ACBD, entonces iperf3 podría estar pensando que hubo un paquete perdido entre B y D. Eso no es lo que sucedió, por supuesto. No tengo conocimientos más profundos en este momento.

Creo que, idealmente, iperf3 sería lo suficientemente inteligente como para realizar un seguimiento de las pérdidas frente a las averías por separado. Los paquetes claramente desordenados no deberían aparecer en el contador de 'pérdidas'.

El código en cuestión está en iperf_udp_recv , a continuación se muestra un extracto:

    /* Out of order packets */
    if (pcount >= sp->packet_count + 1) {
        if (pcount > sp->packet_count + 1) {
            sp->cnt_error += (pcount - 1) - sp->packet_count;
        }
        sp->packet_count = pcount;
    } else {
        sp->outoforder_packets++;
    iperf_err(sp->test, "OUT OF ORDER - incoming packet = %zu and received packet = %d AND SP = %d", pcount, sp->packet_count, sp->socket);
    }

pcount es el número de secuencia leído de un paquete UDP que llega. sp->packet_count es el número de secuencia más alto visto hasta ahora. Sí, parece tener un nombre incorrecto, es posible que este valor no tenga ninguna relación con el número total de paquetes recibidos en la secuencia. Básicamente, las primeras verificaciones condicionales para ver si el paquete que llega hace que los números de secuencia avancen o retrocedan. Si se reenvía, contamos los espacios (si los hay) como paquetes perdidos agregando el tamaño del espacio a sp->cnt_error . Luego establecemos el siguiente número de secuencia esperado.

Si los números de secuencia del paquete iban al revés, incrementamos el contador fuera de orden sp->outoforder_packets y mostramos un mensaje de error un poco confuso con los números de secuencia reales y esperados y el descriptor de archivo. El mensaje de error va a stderr , lo que creo que es un error (tenga en cuenta que no registramos pérdidas de paquetes individuales) ... podría ser mejor ocultar ese mensaje de error detrás de las banderas de depuración o verbose.

Supongamos que se envía una secuencia de paquetes con números de secuencia (1, 2, 3, 4) pero que de alguna manera se reciben en la secuencia (1, 3, 2, 4). El paquete 1 se procesaría sin incidentes. La recepción del paquete 3 contaría entonces como una pérdida (porque iperf3 pensaría entonces que el paquete 2 se había descartado), pero el receptor estaría esperando el paquete 4 a continuación. El paquete 2 en realidad se recibe, y esto incrementa el contador de fuera de orden (pero el paquete 4 sigue siendo el siguiente paquete esperado). Finalmente el paquete 4 llega al receptor, que es el valor esperado. Esta secuencia de paquetes contaría como un paquete fuera de servicio y una pérdida, aunque en realidad no hubo pérdidas reales.

Postulo que sería (más) correcto que por cada paquete fuera de orden que recibamos, podamos disminuir el número de pérdidas (ese número siempre debe ser distinto de cero, porque tenemos que tener un espacio en los números de secuencia para tienen un paquete desordenado, asumiendo que no hay duplicación de paquetes). Estoy seguro de que hay algunos casos extremos extraños con paquetes duplicados o combinaciones de pérdida y reordenamiento que harán que esto se caiga, pero por lo que puedo decir, la única forma de contar con precisión la pérdida en escenarios como este es mantener un mapa de bits de todos los números de secuencia y marque los números de secuencia que realmente hemos visto. Eso se siente bastante engorroso.

Entonces, en este punto, estoy considerando hacer ese pequeño ajuste en el procesamiento fuera de orden, cambiar el mensaje de error ahora y agregar documentación interna que explique lo que está haciendo el código. Sin embargo, no tengo una manera fácil de probar esto ... Estoy dispuesto a recibir sugerencias sobre cómo probar esto de una manera algo controlada.

@ bmah888 Si desea probar paquetes fuera de orden y / o pérdida de paquetes, puede usar la herramienta 'tc' en linux:
https://wiki.linuxfoundation.org/networking/netem#packet -re-ordering

por ejemplo:

# First add a qdisc:
tc qdisc add dev eth0 root netem delay 1ms # Simulates 1ms of delay
# After running "qdisc add", to simulate packet loss:
tc qdisc change dev eth0 root netem loss 1%
# Alternatively, for simulating re-ordering:
tc qdisc change dev eth0 root netem gap 5 delay 10ms # re-orders every 5th packet
# To switch between loss/re-ordering, first run:
tc qdisc del dev eth0 root
# Then run "tc qdisc add" and the appropriate "tc qdisc change" command above...

Después de ejecutar estos comandos, simplemente ejecute iperf como de costumbre (use la máquina en la que ejecutó 'tc' como remitente) y debe observar la pérdida de paquetes o el reordenamiento.

También debería poder usar estos comandos con "lo" en lugar de "eth0" si desea realizar las pruebas en el adaptador de bucle invertido.

(Probablemente hay formas más concisas de usar estos comandos, pero este es el método al que estoy acostumbrado).

@AndrewJDR : Gracias por la información, fue una gran ayuda para comenzar. En la VM CentOS 7 que estoy usando, necesito hacer algo ligeramente diferente, como esto:

tc qdisc add dev lo root netem delay 1ms
tc qdisc change dev lo root netem reorder 100 gap 5 delay 10ms

Ahora probando con este servidor:

bmah-centos7:iperf% src/iperf3 --server

Y este cliente:

bmah-centos7:iperf% src/iperf3 --client localhost --udp -b 15m

Necesitaba aumentar la tasa de bits de envío de UDP en el cliente, porque con el valor predeterminado, parece que los paquetes no están lo suficientemente espaciados como para que el reordenamiento de la red tenga algún efecto. 15Mbps parece ser lo suficientemente rápido como para ver una cierta cantidad de reordenamiento, pero no estamos abrumados por la salida.

@ bmah888 Gracias por esto ... Lo probaré la próxima vez que realice algunas pruebas de iperf y les haré saber cómo funciona.

Fusioné esa solicitud de extracción (# 589) para dominar después de algunas pruebas, con el argumento de que el comportamiento anterior estaba bastante roto y no es probable que empeore incluso si mi supuesta solución no funciona. No creo que sea completamente correcto en todos los casos, por cierto, pero cuenta correctamente (o casi correctamente) en los casos que he estado probando. Cerrando este problema por ahora ... se puede volver a abrir si es necesario.