Iperf: Valores negativos no relatório de perdas com UDP

Criado em 29 set. 2019  ·  4Comentários  ·  Fonte: esnet/iperf

# Contexto

  • Versão do iperf3: 3.7+
  • Hardware: Intel
  • Sistema operacional: servidor Ubuntu14.04.6 em execução na VM (virtualBox 5.2.28)

# Relatório de erro
Obteve um relatório com valores negativos nos contadores lost_packets e losr_percent no arquivo de log do lado do servidor.

  • Comportamento 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 }
    O relatório de fluxo acima apareceu como esperado no mesmo arquivo de log do próximo relatório de fluxo (aquele com valores negativos)

  • Comportamento 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 }

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

Eu reproduzi vários desses testes entre hosts diferentes e isso acontece aleatoriamente, por isso é difícil de reproduzir.

Estou empregando o Mininet 2.2.1 na VM para implantar uma rede com 23 nós e 36 links.
Estou gerando quantidades específicas de tráfego de hosts em minha rede em relação a uma matriz de tráfego (é isso que eu defino um valor -b no lado do cliente). Acabei de perceber esse problema ao analisar todos os arquivos de log. O que posso estar fazendo de errado? Eu aprecio sua ajuda. Obrigado!

bug
Fonte
picture danielaCasasv

Comentários muito úteis

Oi,
O valor de pacotes perdidos negativos parece estar geralmente ok. Isso significa que os pacotes que foram considerados perdidos em intervalos anteriores foram recebidos. Por exemplo, no seguinte caso dado acima:

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%)

Os -2 pacotes perdidos significam que os dois pacotes perdidos no intervalo 30,00-31,00 foram recebidos no intervalo 31,00-32,00.

O total real de pacotes recebidos no intervalo é, portanto, "Total" - "Perdido" (por exemplo, 173 - (- 2) = 175 pacotes foram recebidos no intervalo 31,00-32,00)

Para o caso original lançado, faltam dados relativos ao intervalo 20.000105-21.000194. Como no intervalo 21.000194-22.000068, 146 - (- 111) = 257 pacotes foram recebidos, parece que houve um sério armazenamento em buffer e reordenação da rede no intervalo 20.000105-21.000194, o que fez com que um pacote chegasse antes dos 111 pacotes anteriores, e os 111 os pacotes chegaram apenas durante o intervalo seguinte.

Parece que o principal problema é que, às vezes, o primeiro pacote é recebido com uma contagem distorcida de pacotes ou é recebido truncado, portanto, o contador de pacotes é distorcido. Por exemplo, em:

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%)

provavelmente houve um problema com o primeiro pacote considerado recebido, então sua contagem de pacotes distorcidos foi de 393539. Praticamente, 393539-393365 = 174 pacotes foram recebidos no primeiro intervalo. Todos os intervalos seguintes mostram um número negativo de pacotes perdidos, uma vez que cada pacote recebido é considerado recuperação do pacote perdido desde o primeiro intervalo, até que mais de 393539 pacotes sejam recebidos.

Posteriormente, enviarei uma solicitação pull com sugestões de alterações para evitar o uso do contador de pacotes ilegíveis.

picture davidBar-On em 25 fev. 2020
❤2

Todos 4 comentários

Eu concordo que esses valores não devem ser negativos! No momento, não tenho nenhuma ideia de como eles ficaram assim ... não parece que você esteja fazendo nada particularmente incomum que possa causar esse problema.

bmah888 picture bmah888 em 18 out. 2019

Oi,

Também estou vendo um comportamento semelhante onde pacotes negativos perdidos estão sendo relatados. Como o pôster original, isso acontece apenas esporadicamente. Eu vi isso presente de duas maneiras diferentes.

Configurar:

  • Estamos usando uma versão iperf3 ligeiramente modificada (baseada na v3.5) para que os resultados do intervalo sejam lançados em um banco de dados Mongo também (você verá abaixo alguns sinalizadores de comando extras para oferecer suporte a isso), mas nenhum código de tráfego real ficou emocionada. Nosso teste tem 32 pares cliente / servidor iperf3 simultâneos executando tráfego udp entre 2 dispositivos Linux (um Ubuntu 18.04 e um yocto). Só vi um par afetado de cada vez, embora a pessoa que me relatou tenha dito que viu vários pares afetados.

Caso 1:

  • Este é o caso mais comum. O primeiro intervalo mostra grandes jitter, pacotes e valores de pacotes perdidos, mas taxa de transferência normal. Então, todos os intervalos subsequentes terão valores de pacote zero e pacotes perdidos negativos (taxa de transferência e jitter parecem normais). Curiosamente, a transposição do valor absoluto dos valores de lostPacket / pacote forneceria o resultado esperado.
  • O jitter inicial alto é trazido no Problema # 842, onde a sincronização NTP é mencionada. Temos nossos dois dispositivos NTP sincronizados e os outros 31 pares (nos mesmos dois dispositivos) que estão funcionando simultaneamente não apresentam o mesmo problema.

  • Há uma linha em iperf_api.c (linha 2745 no último mestre) que corresponde ao cálculo de pacotes perdidos (cnt_error) em um intervalo: temp.interval_cnt_error = sp->cnt_error - irp->cnt_error; Não sou muito de um programador C, então rapidamente se perdeu, mas acho que se por algum motivo o cnt_error para o stream fosse 0 e o valor em iperf_interval_results não fosse, então um valor negativo poderia ocorrer. Talvez seja apenas uma coincidência, mas parece estranho que os valores dos pacotes perdidos (por exemplo, -170) sejam negativos dos valores que eu esperaria para os pacotes (por exemplo, 170).

  • Cliente iperf3 (linha de comando e saída):

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 (linha de comando e saída):
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:

  • Só vi isso uma vez até agora. O teste parece ser executado normalmente, mas o último intervalo tem um valor de pacote perdido negativo (caso contrário, todo o resto parece ok (ou seja, nenhum pacote zero ou valores com pico)).

  • Cliente iperf3 (linha de comando e saída):

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 (linha de comando e saída):
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: -----------------------------------------------------------
dmozzoni picture dmozzoni em 1 nov. 2019

Oi pessoal vocês superaram esse problema?
Estou tendo um problema semelhante, não sei o que isso significa.

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

(reformatado para maior clareza)

Carlitops picture Carlitops em 6 fev. 2020

Oi,
O valor de pacotes perdidos negativos parece estar geralmente ok. Isso significa que os pacotes que foram considerados perdidos em intervalos anteriores foram recebidos. Por exemplo, no seguinte caso dado acima:

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%)

Os -2 pacotes perdidos significam que os dois pacotes perdidos no intervalo 30,00-31,00 foram recebidos no intervalo 31,00-32,00.

O total real de pacotes recebidos no intervalo é, portanto, "Total" - "Perdido" (por exemplo, 173 - (- 2) = 175 pacotes foram recebidos no intervalo 31,00-32,00)

Para o caso original lançado, faltam dados relativos ao intervalo 20.000105-21.000194. Como no intervalo 21.000194-22.000068, 146 - (- 111) = 257 pacotes foram recebidos, parece que houve um sério armazenamento em buffer e reordenação da rede no intervalo 20.000105-21.000194, o que fez com que um pacote chegasse antes dos 111 pacotes anteriores, e os 111 os pacotes chegaram apenas durante o intervalo seguinte.

Parece que o principal problema é que, às vezes, o primeiro pacote é recebido com uma contagem distorcida de pacotes ou é recebido truncado, portanto, o contador de pacotes é distorcido. Por exemplo, em:

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%)

provavelmente houve um problema com o primeiro pacote considerado recebido, então sua contagem de pacotes distorcidos foi de 393539. Praticamente, 393539-393365 = 174 pacotes foram recebidos no primeiro intervalo. Todos os intervalos seguintes mostram um número negativo de pacotes perdidos, uma vez que cada pacote recebido é considerado recuperação do pacote perdido desde o primeiro intervalo, até que mais de 393539 pacotes sejam recebidos.

Posteriormente, enviarei uma solicitação pull com sugestões de alterações para evitar o uso do contador de pacotes ilegíveis.

davidBar-On picture davidBar-On em 25 fev. 2020
❤2
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

thx1111 picture thx1111  ·  11Comentários
ili101 picture ili101  ·  4Comentários
smcifrankp picture smcifrankp  ·  4Comentários
Surendraknatarajan picture Surendraknatarajan  ·  9Comentários
KevinJosephMorin picture KevinJosephMorin  ·  5Comentários