Iperf: Valores negativos en informe de pérdidas con UDP

Creado en 29 sept. 2019  ·  4Comentarios  ·  Fuente: esnet/iperf

# Contexto

  • Versión de iperf3: 3.7+
  • Hardware: Intel
  • Sistema operativo: servidor Ubuntu14.04.6 que se ejecuta en VM (virtualBox 5.2.28)

# Informe de error
Obtuve un informe con valores negativos en los contadores lost_packets y losr_percent en el archivo de registro del lado del servidor.

  • Comportamiento esperado:
    { "streams": [{ "socket": 6, "start": 19.000102, "end": 20.000105, "seconds": 1.0000029802322388, "bytes": 166520, "bits_per_second": 1332156.0298656528, "jitter_ms": 2.8512847190910904, "lost_packets": 0, "packets": 115, "lost_percent": 0, "omitted": false, "sender": false }], "sum": { "start": 19.000102, "end": 20.000105, "seconds": 1.0000029802322388, "bytes": 166520, "bits_per_second": 1332156.0298656528, "jitter_ms": 2.8512847190910904, "lost_packets": 0, "packets": 115, "lost_percent": 0, "omitted": false, "sender": false }
    El informe de transmisión anterior apareció como se esperaba en el mismo archivo de registro que el siguiente informe de transmisión (el que tiene valores negativos)
  • Comportamiento real
    { "streams": [{ "socket": 6, "start": 21.000194, "end": 22.000068, "seconds": 0.99987399578094482, "bytes": 372136, "bits_per_second": 2977463.1729218694, "jitter_ms": 2110.7105786449633, "lost_packets": -111, "packets": 146, "lost_percent": -76.027397260273972, "omitted": false, "sender": false }], "sum": { "start": 21.000194, "end": 22.000068, "seconds": 0.99987399578094482, "bytes": 372136, "bits_per_second": 2977463.1729218694, "jitter_ms": 2110.7105786449633, "lost_packets": -111, "packets": 146, "lost_percent": -76.027397260273972, "omitted": false, "sender": false }

  • Pasos para reproducir
    lado del servidor de comandos: iperf3 -s -p 11002-1 -J --logfile serverOut_11_to_2.json
    comando del lado del cliente: iperf3 -c 10.0.0.2 -p 11002 -u -b 1675.289k -t 40 -J --logfile clientOut_11_to_2.json

He reproducido varias de estas pruebas entre diferentes hosts y simplemente ocurre al azar, por lo que es difícil de reproducir.

Estoy empleando Mininet 2.2.1 en la VM para implementar una red con 23 nodos y 36 enlaces.
Estoy generando cantidades específicas de tráfico desde hosts en mi red con respecto a una matriz de tráfico (es decir, establezco un valor -b en el lado del cliente). Me acabo de dar cuenta de este problema al analizar todos los archivos de registro. ¿Qué podría estar haciendo mal? Agradeceré tu ayuda. ¡Gracias!

bug

Comentario más útil

Hola,
El valor negativo de los paquetes perdidos parece estar bien en general. Significa que se recibieron los paquetes que se consideraron perdidos en intervalos anteriores. Por ejemplo, en el siguiente caso dado anteriormente:

41:54.4: [  8]  30.00-31.00  sec   242 KBytes  1.98 Mbits/sec  4.966 ms  2/173 (1.2%) 
41:55.4: [  8]  31.00-32.00  sec   247 KBytes  2.03 Mbits/sec  5.648 ms  -2/173 (-1.2%)

Los -2 paquetes perdidos significan que los dos paquetes perdidos en el intervalo 30,00-31,00 se recibieron en el intervalo 31,00-32,00.

El total real de paquetes recibidos en el intervalo es, por lo tanto, "Total" - "Perdidos" (por ejemplo, 173 - (- 2) = 175 paquetes recibidos en el intervalo 31.00-32.00)

Para el caso original publicado, faltan datos con respecto al intervalo 20.000105-21.000194. Como en el intervalo 21.000194-22.000068, 146 - (- 111) = 257 paquetes fueron recibidos, parece que hubo un serio almacenamiento en búfer y reorden en la red en el intervalo 20.000105-21.000194, lo que provocó que un paquete llegara antes que los 111 paquetes anteriores, y el 111 los paquetes llegaron solo durante el siguiente intervalo.

Parece que el problema principal es que a veces el primer paquete se recibe con un recuento de paquetes distorsionado o se recibe truncado, por lo que el contador de paquetes se distorsiona. Por ejemplo, en:

46:24.9: [ ID] Interval          Transfer    Bitrate         Jitter          Lost/Total Datagrams
46:24.9: [  8] 0.00-1.00   sec   246 KBytes  2.02 Mbits/sec  2567541.936 ms  393365/393539 (1e+02%)

probablemente hubo un problema con el primer paquete que se supuso que se recibió, por lo que su recuento de paquetes confusos fue 393539. Prácticamente, 393539-393365 = 174 paquetes se recibieron en el primer intervalo. Todos los intervalos siguientes muestran un número negativo de paquetes perdidos, ya que cada paquete recibido se considera recuperación del paquete perdido desde el primer intervalo, hasta que se reciban más de 393539 paquetes.

Más tarde, enviaré una solicitud de extracción con cambios sugeridos para evitar el uso de un contador de paquetes ilegibles.

Todos 4 comentarios

¡Estoy de acuerdo en que esos valores no deberían ser negativos! Por el momento no tengo ninguna idea de cómo llegaron de esa manera ... no parece que esté haciendo algo particularmente inusual que pueda causar este problema.

Hola,

También veo un comportamiento similar en el que se informan paquetes perdidos negativos. Al igual que el póster original, ocurre solo esporádicamente. Lo he visto presente de dos formas diferentes.

Configuración:

  • Estamos usando una versión de iperf3 ligeramente modificada (basada en v3.5) para que los resultados del intervalo también se incluyan en una base de datos de Mongo (verá a continuación un par de indicadores de comando adicionales para respaldar eso), pero ninguno del código de tráfico real fue tocado. Nuestra prueba tiene 32 pares cliente / servidor iperf3 simultáneos que ejecutan tráfico udp entre 2 dispositivos Linux (un Ubuntu 18.04 y uno yocto). Solo he visto un par afectado a la vez, aunque la persona que me lo informó dijo que ha visto varios pares afectados.

Caso 1:

  • Este es el caso más común. El primer intervalo muestra una gran fluctuación, paquetes y valores de paquetes perdidos, pero un rendimiento normal. Entonces, todos los intervalos posteriores tendrán cero paquetes y valores negativos de paquetes perdidos (el rendimiento y la fluctuación parecen normales). Curiosamente, la transposición del valor absoluto de los valores de paquetes / paquetes perdidos proporcionaría el resultado esperado.
  • El jitter inicial alto se menciona en el número 842, donde se menciona la sincronización NTP. Tenemos nuestros dos dispositivos NTP sincronizados y los otros 31 pares (en los mismos dos dispositivos) que se ejecutan simultáneamente no presentan el mismo problema.
  • Hay una línea en iperf_api.c (línea 2745 en el último maestro) que corresponde al cálculo de paquetes perdidos (cnt_error) en un intervalo: temp.interval_cnt_error = sp->cnt_error - irp->cnt_error; No soy un programador de C, así que rápidamente se perdió, pero supongo que si por alguna razón el cnt_error para la transmisión era 0 y el valor en iperf_interval_results no lo era, entonces podría ocurrir un valor negativo. Tal vez sea solo una coincidencia, pero parece extraño que los valores de los paquetes perdidos (por ejemplo, -170) sean los negativos de los valores que esperaría para los paquetes (por ejemplo, 170).

  • Cliente iperf3 (línea de comandos y salida):

iperf3 --octoerror --bind=192.168.222.202 --bitrate=2m --client=192.168.222.4 --connect-timeout=500 --dscp=0 --forceflush --interval=1 --mongo --parallel=1 --port=24731 --reverse --set-mss=8000 --time=32 --udp --window=2M


46:24.1: time: Thu, 31 Oct 2019 17:46:23 GMT  timesecs: 1572543983  Client mode: connecting_to  host: 192.168.222.4  port : 24731
46:24.1: Connecting to host 192.168.222.4, port 24731
46:24.1: Reverse mode, remote host 192.168.222.4 is sending
46:24.9: [  8] local 192.168.222.202 port 34524 connected to 192.168.222.4 port 24731
46:24.9: protocol: UDP  num_streams: 1  blksize: 1448  omit: 0  duration: 32  bytes: 0  blocks: 0  reverse: 1
46:24.9: [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
46:24.9: [  8]   0.00-1.00   sec   246 KBytes  2.02 Mbits/sec  2567541.936 ms  393365/393539 (1e+02%) 
46:26.0: [  8]   1.00-2.00   sec   240 KBytes  1.97 Mbits/sec  49.376 ms  -170/0 (0%) 
46:26.4: [  8]   2.00-3.00   sec   247 KBytes  2.03 Mbits/sec  4.897 ms  -175/0 (0%) 
46:27.4: [  8]   3.00-4.00   sec   245 KBytes  2.00 Mbits/sec  4.799 ms  -173/0 (0%) 
46:28.4: [  8]   4.00-5.00   sec   243 KBytes  1.99 Mbits/sec  5.500 ms  -172/0 (0%) 
46:29.4: [  8]   5.00-6.00   sec   246 KBytes  2.02 Mbits/sec  4.971 ms  -174/0 (0%) 
46:30.4: [  8]   6.00-7.00   sec   242 KBytes  1.98 Mbits/sec  5.427 ms  -171/0 (0%) 
46:31.4: [  8]   7.00-8.00   sec   246 KBytes  2.02 Mbits/sec  5.356 ms  -174/0 (0%) 
46:32.4: [  8]   8.00-9.00   sec   243 KBytes  1.99 Mbits/sec  5.389 ms  -172/0 (0%) 
46:33.4: [  8]   9.00-10.00  sec   246 KBytes  2.02 Mbits/sec  5.580 ms  -174/0 (0%) 
46:34.4: [  8]  10.00-11.00  sec   243 KBytes  1.99 Mbits/sec  5.046 ms  -172/0 (0%) 
46:35.4: [  8]  11.00-12.00  sec   243 KBytes  1.99 Mbits/sec  5.526 ms  -172/0 (0%) 
46:36.4: [  8]  12.00-13.00  sec   243 KBytes  1.99 Mbits/sec  4.986 ms  -172/0 (0%) 
46:37.4: [  8]  13.00-14.00  sec   246 KBytes  2.02 Mbits/sec  4.939 ms  -174/0 (0%) 
46:38.4: [  8]  14.00-15.00  sec   245 KBytes  2.00 Mbits/sec  6.100 ms  -173/0 (0%) 
46:39.4: [  8]  15.00-16.00  sec   243 KBytes  1.99 Mbits/sec  5.215 ms  -172/0 (0%) 
46:40.4: [  8]  16.00-17.00  sec   245 KBytes  2.00 Mbits/sec  5.513 ms  -173/0 (0%) 
46:41.4: [  8]  17.00-18.00  sec   243 KBytes  1.99 Mbits/sec  5.874 ms  -172/0 (0%) 
46:42.4: [  8]  18.00-19.00  sec   242 KBytes  1.98 Mbits/sec  5.172 ms  -171/0 (0%) 
46:43.4: [  8]  19.00-20.00  sec   247 KBytes  2.03 Mbits/sec  5.680 ms  -175/0 (0%) 
46:44.4: [  8]  20.00-21.00  sec   242 KBytes  1.98 Mbits/sec  5.185 ms  -171/0 (0%) 
46:45.4: [  8]  21.00-22.00  sec   245 KBytes  2.00 Mbits/sec  4.800 ms  -173/0 (0%) 
46:46.4: [  8]  22.00-23.00  sec   245 KBytes  2.00 Mbits/sec  4.909 ms  -173/0 (0%) 
46:47.4: [  8]  23.00-24.00  sec   245 KBytes  2.00 Mbits/sec  4.643 ms  -173/0 (0%) 
46:48.4: [  8]  24.00-25.00  sec   245 KBytes  2.00 Mbits/sec  5.953 ms  -173/0 (0%) 
46:49.4: [  8]  25.00-26.00  sec   243 KBytes  1.99 Mbits/sec  5.300 ms  -172/0 (0%) 
46:50.4: [  8]  26.00-27.00  sec   246 KBytes  2.02 Mbits/sec  5.048 ms  -174/0 (0%) 
46:51.4: [  8]  27.00-28.00  sec   245 KBytes  2.00 Mbits/sec  5.019 ms  -173/0 (0%) 
46:52.4: [  8]  28.00-29.00  sec   243 KBytes  1.99 Mbits/sec  5.198 ms  -172/0 (0%) 
46:53.4: [  8]  29.00-30.00  sec   243 KBytes  1.99 Mbits/sec  5.016 ms  -172/0 (0%) 
46:54.4: [  8]  30.00-31.00  sec   243 KBytes  1.99 Mbits/sec  5.106 ms  -172/0 (0%) 
46:55.7: [  8]  31.00-32.00  sec   245 KBytes  2.00 Mbits/sec  3.244 ms  -173/0 (0%) 
46:55.7: - - - - - - - - - - - - - - - - - - - - - - - - -
46:55.7: [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
46:55.7: [  8]   0.00-32.02  sec  7.64 MBytes  2.00 Mbits/sec  0.000 ms  0/5529 (0%)  sender
46:55.7: [SUM]  0.0-32.0 sec  5525 datagrams received out-of-order
46:55.7: [  8]   0.00-32.00  sec  7.63 MBytes  2.00 Mbits/sec  3.244 ms  388013/393539 (99%)  receiver
  • servidor iperf3 (línea de comandos y salida):
iperf3 --octoerror --bind=192.168.222.4 --forceflush --interval=1 --port=24731 --server


46:15.4: -----------------------------------------------------------
46:15.4: Server listening on 24731
46:15.4: -----------------------------------------------------------
46:23.3: time: Thu, 31 Oct 2019 17:46:23 GMT  timesecs: 1572543983  Server mode: accepted_connection  host: 192.168.222.202  port: 33344
46:23.3: Accepted connection from 192.168.222.202, port 33344
46:24.3: [  7] local 192.168.222.4 port 24731 connected to 192.168.222.202 port 34524
46:24.3: protocol: UDP  num_streams: 1  blksize: 1448  omit: 0  duration: 32  bytes: 0  blocks: 0  reverse: 1
46:24.3: [ ID] Interval           Transfer     Bitrate         Total Datagrams
46:24.3: [  7]   0.00-1.00   sec   245 KBytes  2.00 Mbits/sec  173 
46:25.3: [  7]   1.00-2.00   sec   245 KBytes  2.00 Mbits/sec  173 
46:26.3: [  7]   2.00-3.00   sec   243 KBytes  1.99 Mbits/sec  172 
46:27.3: [  7]   3.00-4.00   sec   245 KBytes  2.00 Mbits/sec  173 
46:28.3: [  7]   4.00-5.00   sec   245 KBytes  2.00 Mbits/sec  173 
46:29.3: [  7]   5.00-6.00   sec   243 KBytes  1.99 Mbits/sec  172 
46:30.3: [  7]   6.00-7.00   sec   245 KBytes  2.00 Mbits/sec  173 
46:31.3: [  7]   7.00-8.00   sec   245 KBytes  2.00 Mbits/sec  173 
46:32.3: [  7]   8.00-9.00   sec   243 KBytes  1.99 Mbits/sec  172 
46:33.3: [  7]   9.00-10.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:34.3: [  7]  10.00-11.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:35.3: [  7]  11.00-12.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:36.3: [  7]  12.00-13.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:37.3: [  7]  13.00-14.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:38.3: [  7]  14.00-15.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:39.3: [  7]  15.00-16.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:40.3: [  7]  16.00-17.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:41.3: [  7]  17.00-18.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:42.3: [  7]  18.00-19.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:43.3: [  7]  19.00-20.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:44.3: [  7]  20.00-21.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:45.3: [  7]  21.00-22.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:46.3: [  7]  22.00-23.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:47.3: [  7]  23.00-24.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:48.3: [  7]  24.00-25.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:49.3: [  7]  25.00-26.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:50.3: [  7]  26.00-27.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:51.3: [  7]  27.00-28.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:52.3: [  7]  28.00-29.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:53.3: [  7]  29.00-30.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:54.3: [  7]  30.00-31.00  sec   245 KBytes  2.00 Mbits/sec  173 
46:55.3: [  7]  31.00-32.00  sec   243 KBytes  1.99 Mbits/sec  172 
46:55.4: [  7]  32.00-32.02  sec  5.66 KBytes  2.38 Mbits/sec  4 
46:55.4: - - - - - - - - - - - - - - - - - - - - - - - - -
46:55.4: [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
46:55.4: [  7]   0.00-32.02  sec  7.64 MBytes  2.00 Mbits/sec  0.000 ms  0/5529 (0%)  sender

Caso 2:

  • Solo he visto esto una vez hasta ahora. La prueba parece ejecutarse con normalidad, pero el último intervalo tiene un valor de paquete perdido negativo (de lo contrario, todo lo demás parece estar bien (es decir, sin paquetes cero o valores con picos)).

  • Cliente iperf3 (línea de comandos y salida):

iperf3 --octoerror --bind=192.168.222.202 --bitrate=2m --client=192.168.222.4 --connect-timeout=500 --dscp=0 --forceflush --interval=1 --mongo --parallel=1 --port=14069 --reverse --set-mss=8000 --time=32 --udp --window=2M

41:23.9: time: Thu, 31 Oct 2019 15:41:23 GMT  timesecs: 1572536483  Client mode: connecting_to  host: 192.168.222.4  port : 14069
41:23.9: Connecting to host 192.168.222.4, port 14069
41:23.9: Reverse mode, remote host 192.168.222.4 is sending
41:24.9: [  8] local 192.168.222.202 port 49732 connected to 192.168.222.4 port 14069
41:24.9: protocol: UDP  num_streams: 1  blksize: 1448  omit: 0  duration: 32  bytes: 0  blocks: 0  reverse: 1
41:24.9: [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
41:24.9: [  8]   0.00-1.00   sec   245 KBytes  2.00 Mbits/sec  5.052 ms  0/173 (0%) 
41:25.7: [  8]   1.00-2.00   sec   243 KBytes  1.99 Mbits/sec  4.923 ms  0/172 (0%) 
41:26.8: [  8]   2.00-3.00   sec   245 KBytes  2.00 Mbits/sec  5.997 ms  0/173 (0%) 
41:27.4: [  8]   3.00-4.00   sec   243 KBytes  1.99 Mbits/sec  6.019 ms  0/172 (0%) 
41:28.4: [  8]   4.00-5.00   sec   245 KBytes  2.00 Mbits/sec  4.799 ms  0/173 (0%) 
41:29.4: [  8]   5.00-6.00   sec   245 KBytes  2.00 Mbits/sec  6.097 ms  0/173 (0%) 
41:30.4: [  8]   6.00-7.00   sec   245 KBytes  2.00 Mbits/sec  5.287 ms  0/173 (0%) 
41:31.4: [  8]   7.00-8.00   sec   245 KBytes  2.00 Mbits/sec  5.652 ms  0/173 (0%) 
41:32.4: [  8]   8.00-9.00   sec   243 KBytes  1.99 Mbits/sec  4.803 ms  0/172 (0%) 
41:33.4: [  8]   9.00-10.00  sec   246 KBytes  2.02 Mbits/sec  5.248 ms  0/174 (0%) 
41:34.4: [  8]  10.00-11.00  sec   243 KBytes  1.99 Mbits/sec  5.175 ms  0/172 (0%) 
41:35.4: [  8]  11.00-12.00  sec   245 KBytes  2.00 Mbits/sec  4.627 ms  0/173 (0%) 
41:36.4: [  8]  12.00-13.00  sec   242 KBytes  1.98 Mbits/sec  5.089 ms  0/171 (0%) 
41:37.4: [  8]  13.00-14.00  sec   247 KBytes  2.03 Mbits/sec  5.438 ms  0/175 (0%) 
41:38.4: [  8]  14.00-15.00  sec   240 KBytes  1.97 Mbits/sec  5.313 ms  0/170 (0%) 
41:39.4: [  8]  15.00-16.00  sec   246 KBytes  2.02 Mbits/sec  5.015 ms  0/174 (0%) 
41:40.4: [  8]  16.00-17.00  sec   243 KBytes  1.99 Mbits/sec  5.195 ms  0/172 (0%) 
41:41.4: [  8]  17.00-18.00  sec   246 KBytes  2.02 Mbits/sec  5.085 ms  0/174 (0%) 
41:42.4: [  8]  18.00-19.00  sec   243 KBytes  1.99 Mbits/sec  7.104 ms  0/172 (0%) 
41:43.4: [  8]  19.00-20.00  sec   245 KBytes  2.00 Mbits/sec  5.546 ms  0/173 (0%) 
41:44.4: [  8]  20.00-21.00  sec   243 KBytes  1.99 Mbits/sec  5.211 ms  0/172 (0%) 
41:45.4: [  8]  21.00-22.00  sec   245 KBytes  2.00 Mbits/sec  4.971 ms  0/173 (0%) 
41:46.4: [  8]  22.00-23.00  sec   245 KBytes  2.00 Mbits/sec  4.990 ms  0/173 (0%) 
41:47.4: [  8]  23.00-24.00  sec   240 KBytes  1.97 Mbits/sec  5.803 ms  0/170 (0%) 
41:48.4: [  8]  24.00-25.00  sec   246 KBytes  2.02 Mbits/sec  6.120 ms  0/174 (0%) 
41:49.4: [  8]  25.00-26.00  sec   246 KBytes  2.02 Mbits/sec  5.042 ms  0/174 (0%) 
41:50.4: [  8]  26.00-27.00  sec   243 KBytes  1.99 Mbits/sec  5.061 ms  0/172 (0%) 
41:51.4: [  8]  27.00-28.00  sec   243 KBytes  1.99 Mbits/sec  5.063 ms  0/172 (0%) 
41:52.4: [  8]  28.00-29.00  sec   246 KBytes  2.02 Mbits/sec  4.918 ms  0/174 (0%) 
41:53.4: [  8]  29.00-30.00  sec   243 KBytes  1.99 Mbits/sec  5.847 ms  0/172 (0%) 
41:54.4: [  8]  30.00-31.00  sec   242 KBytes  1.98 Mbits/sec  4.966 ms  2/173 (1.2%) 
41:55.4: [  8]  31.00-32.00  sec   247 KBytes  2.03 Mbits/sec  5.648 ms  -2/173 (-1.2%) 
41:55.4: - - - - - - - - - - - - - - - - - - - - - - - - -
41:55.4: [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
41:55.4: [  8]   0.00-32.01  sec  7.63 MBytes  2.00 Mbits/sec  0.000 ms  0/5527 (0%)  sender
41:55.4: [SUM]  0.0-32.0 sec  13 datagrams received out-of-order
41:55.4: [  8]   0.00-32.00  sec  7.63 MBytes  2.00 Mbits/sec  5.648 ms  0/5526 (0%)  receiver
  • servidor iperf3 (línea de comandos y salida):
iperf3 --octoerror --bind=192.168.222.4 --forceflush --interval=1 --port=14069 --server

41:23.4: time: Thu, 31 Oct 2019 15:41:23 GMT  timesecs: 1572536483  Server mode: accepted_connection  host: 192.168.222.202  port: 40600
41:23.4: Accepted connection from 192.168.222.202, port 40600
41:24.4: [  7] local 192.168.222.4 port 14069 connected to 192.168.222.202 port 49732
41:24.4: protocol: UDP  num_streams: 1  blksize: 1448  omit: 0  duration: 32  bytes: 0  blocks: 0  reverse: 1
41:24.4: [ ID] Interval           Transfer     Bitrate         Total Datagrams
41:24.4: [  7]   0.00-1.00   sec   245 KBytes  2.00 Mbits/sec  173 
41:25.4: [  7]   1.00-2.00   sec   245 KBytes  2.00 Mbits/sec  173 
41:26.4: [  7]   2.00-3.00   sec   243 KBytes  1.99 Mbits/sec  172 
41:27.4: [  7]   3.00-4.00   sec   245 KBytes  2.00 Mbits/sec  173 
41:28.4: [  7]   4.00-5.00   sec   245 KBytes  2.00 Mbits/sec  173 
41:29.4: [  7]   5.00-6.00   sec   243 KBytes  1.99 Mbits/sec  172 
41:30.4: [  7]   6.00-7.00   sec   245 KBytes  2.00 Mbits/sec  173 
41:31.4: [  7]   7.00-8.00   sec   245 KBytes  2.00 Mbits/sec  173 
41:32.4: [  7]   8.00-9.00   sec   243 KBytes  1.99 Mbits/sec  172 
41:33.4: [  7]   9.00-10.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:34.4: [  7]  10.00-11.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:35.4: [  7]  11.00-12.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:36.4: [  7]  12.00-13.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:37.4: [  7]  13.00-14.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:38.4: [  7]  14.00-15.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:39.4: [  7]  15.00-16.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:40.4: [  7]  16.00-17.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:41.4: [  7]  17.00-18.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:42.4: [  7]  18.00-19.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:43.4: [  7]  19.00-20.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:44.4: [  7]  20.00-21.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:45.4: [  7]  21.00-22.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:46.4: [  7]  22.00-23.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:47.4: [  7]  23.00-24.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:48.4: [  7]  24.00-25.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:49.4: [  7]  25.00-26.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:50.4: [  7]  26.00-27.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:51.4: [  7]  27.00-28.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:52.4: [  7]  28.00-29.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:53.4: [  7]  29.00-30.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:54.4: [  7]  30.00-31.00  sec   245 KBytes  2.00 Mbits/sec  173 
41:55.4: [  7]  31.00-32.00  sec   243 KBytes  1.99 Mbits/sec  172 
41:55.4: [  7]  32.00-32.01  sec  2.83 KBytes  2.59 Mbits/sec  2 
41:55.4: - - - - - - - - - - - - - - - - - - - - - - - - -
41:55.4: [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
41:55.4: [  7]   0.00-32.01  sec  7.63 MBytes  2.00 Mbits/sec  0.000 ms  0/5527 (0%)  sender
41:55.4: iperf test finished.
41:55.4: -----------------------------------------------------------
41:55.4: Server listening on 14069
41:55.4: -----------------------------------------------------------

Hola chicos, ¿habéis superado este problema?
Estoy experimentando un problema similar, no sé qué significa eso.

Accepted connection from 172.16.0.1, port 48634
[  5] local 172.16.0.3 port 5201 connected to 172.16.0.1 port 42108
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  4.53 MBytes  38.0 Mbits/sec  0.060 ms  -1931109556/-1931109555 (0%)  
[  5]   1.00-2.00   sec  4.77 MBytes  40.0 Mbits/sec  0.084 ms  0/0 (0%)  
[  5]   2.00-3.00   sec  4.77 MBytes  40.0 Mbits/sec  0.133 ms  0/0 (0%)  
[  5]   3.00-4.00   sec  4.76 MBytes  40.0 Mbits/sec  0.048 ms  0/0 (0%)  
[  5]   4.00-5.00   sec  4.56 MBytes  38.2 Mbits/sec  0.277 ms  0/0 (0%)  
[  5]   5.00-6.00   sec  4.80 MBytes  40.3 Mbits/sec  0.093 ms  0/0 (0%)  
[  5]   6.00-7.00   sec  4.54 MBytes  38.1 Mbits/sec  0.116 ms  0/0 (0%)  
[  5]   7.00-8.00   sec  4.77 MBytes  40.0 Mbits/sec  0.044 ms  0/0 (0%)  
[  5]   8.00-9.00   sec  4.77 MBytes  40.0 Mbits/sec  0.059 ms  0/0 (0%)  
[  5]   9.00-10.00  sec  4.38 MBytes  36.7 Mbits/sec  0.175 ms  0/0 (0%)  
[  5]  10.00-10.05  sec   119 KBytes  19.8 Mbits/sec  0.155 ms  0/0 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[SUM]  0.0-10.0 sec  34730 datagrams received out-of-order
[  5]   0.00-10.05  sec  46.8 MBytes  39.0 Mbits/sec  0.155 ms  -1931109556/-1931109555 (0%)  receiver

(reformateado para mayor claridad)

Hola,
El valor negativo de los paquetes perdidos parece estar bien en general. Significa que se recibieron los paquetes que se consideraron perdidos en intervalos anteriores. Por ejemplo, en el siguiente caso dado anteriormente:

41:54.4: [  8]  30.00-31.00  sec   242 KBytes  1.98 Mbits/sec  4.966 ms  2/173 (1.2%) 
41:55.4: [  8]  31.00-32.00  sec   247 KBytes  2.03 Mbits/sec  5.648 ms  -2/173 (-1.2%)

Los -2 paquetes perdidos significan que los dos paquetes perdidos en el intervalo 30,00-31,00 se recibieron en el intervalo 31,00-32,00.

El total real de paquetes recibidos en el intervalo es, por lo tanto, "Total" - "Perdidos" (por ejemplo, 173 - (- 2) = 175 paquetes recibidos en el intervalo 31.00-32.00)

Para el caso original publicado, faltan datos con respecto al intervalo 20.000105-21.000194. Como en el intervalo 21.000194-22.000068, 146 - (- 111) = 257 paquetes fueron recibidos, parece que hubo un serio almacenamiento en búfer y reorden en la red en el intervalo 20.000105-21.000194, lo que provocó que un paquete llegara antes que los 111 paquetes anteriores, y el 111 los paquetes llegaron solo durante el siguiente intervalo.

Parece que el problema principal es que a veces el primer paquete se recibe con un recuento de paquetes distorsionado o se recibe truncado, por lo que el contador de paquetes se distorsiona. Por ejemplo, en:

46:24.9: [ ID] Interval          Transfer    Bitrate         Jitter          Lost/Total Datagrams
46:24.9: [  8] 0.00-1.00   sec   246 KBytes  2.02 Mbits/sec  2567541.936 ms  393365/393539 (1e+02%)

probablemente hubo un problema con el primer paquete que se supuso que se recibió, por lo que su recuento de paquetes confusos fue 393539. Prácticamente, 393539-393365 = 174 paquetes se recibieron en el primer intervalo. Todos los intervalos siguientes muestran un número negativo de paquetes perdidos, ya que cada paquete recibido se considera recuperación del paquete perdido desde el primer intervalo, hasta que se reciban más de 393539 paquetes.

Más tarde, enviaré una solicitud de extracción con cambios sugeridos para evitar el uso de un contador de paquetes ilegibles.

¿Fue útil esta página
0 / 5 - 0 calificaciones