Iperf: comportamento estranho incompatível UDP FORA DE ORDEM

Isso significa que o servidor iperf3 está recebendo os pacotes de teste UDP em uma ordem diferente daquela que foram enviados do cliente iperf3. Pode haver uma variedade de explicações para esse fenômeno, desde pacotes que seguem caminhos diferentes pela rede até bugs nos drivers de rede.

Seriam necessárias mais informações para que alguém o ajudasse a diagnosticar o problema. Se você pegar um rastreamento de pacote (digamos usando tcpdump) no destino, você pode realmente decodificar os números de sequência iperf3 nos pacotes e ver se os pacotes chegaram intactos, fora de ordem, etc.

pode haver um link vinculado ou NIC vinculado? Isso geralmente leva a pacotes fora de serviço.

Além disso, veja se 3.1.6 corrige isso.

@ bmah888 :

Dado que o UDP como protocolo não garante que os pacotes chegarão na mesma ordem em que foram enviados, por que os pacotes fora de ordem são contados como pacotes "perdidos" na saída de estatísticas?

Por exemplo, na saída do teste UDP abaixo usando o último commit f1415a0d98b de iperf em ambas as extremidades e usando o comando iperf3 -R -u --get-server-output -b 4M -c <my_server_hostname> , há várias mensagens "FORA DE ORDEM", então imediatamente depois, os pacotes fora de ordem são relatado como pacotes perdidos (por exemplo, 2/342 ). Por que eles são considerados perdidos? Isso é UDP, portanto, pacotes fora de ordem são algo que pode acontecer em circunstâncias totalmente normais.

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 : Não tenho certeza, para ser totalmente honesto, por que está contando erros dessa maneira. O código em questão foi escrito antes de eu começar a trabalhar neste projeto, ou mesmo antes de entrar na ESnet.

Meu palpite (e isso é tudo) é que, se dois pacotes foram trocados, parece haver uma lacuna nos números de sequência recebidos, o que é (erroneamente) contabilizado como uma perda. Em outras palavras, se os pacotes foram enviados na ordem ABCD, mas recebidos na ordem ACBD, então iperf3 pode estar pensando que houve um pacote perdido entre B e D. Isso não foi o que aconteceu, é claro. Não tenho nenhuma visão mais profunda neste momento.

Acho que o ideal é que o iperf3 seja inteligente o suficiente para rastrear separadamente as perdas e as falhas. Claramente, os pacotes fora de ordem não devem aparecer no contador de 'perdas'.

O código em questão está em iperf_udp_recv , um trecho está abaixo:

    /* 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 é o número de sequência lido de um pacote UDP que chega. sp->packet_count é o número de sequência mais alto visto até agora. Sim, parece ter um nome incorreto, esse valor pode não ter nenhuma relação com o número total de pacotes recebidos no fluxo. Basicamente, a primeira verificação condicional para ver se o pacote que chega faz com que os números de sequência avancem ou retrocedam. Se for para frente, então contamos as lacunas (se houver) como pacotes perdidos, adicionando o tamanho da lacuna a sp->cnt_error . Em seguida, definimos o próximo número de sequência esperado.

Se os números da sequência do pacote retrocedem, incrementamos o contador fora de ordem sp->outoforder_packets e geramos uma mensagem de erro ligeiramente confusa com os números da sequência reais e esperados e o descritor de arquivo. A mensagem de erro vai para stderr , o que eu acredito ser um erro (observe que não registramos perdas de pacotes individuais) ... pode ser melhor esconder essa mensagem de erro atrás dos sinalizadores de depuração ou verboso.

Vamos supor que uma seqüência de pacotes seja enviada com números de seqüência (1, 2, 3, 4), mas de alguma forma recebida na seqüência (1, 3, 2, 4). O pacote 1 seria processado sem incidentes. A recepção do pacote 3 seria então considerada uma perda (porque iperf3 pensaria que o pacote 2 foi descartado), mas o receptor estaria esperando o pacote 4 em seguida. O pacote 2 é realmente recebido e isso aumenta o contador fora de ordem (mas o pacote 4 continua sendo o próximo pacote esperado). Finalmente o pacote 4 chega ao receptor, que é o valor esperado. Essa sequência de pacotes contaria como um pacote fora de ordem e uma perda, embora, na realidade, não houvesse perdas reais.

Eu postulo que seria (mais) correto que para cada pacote fora de ordem que recebemos, podemos decrementar o número de perdas (esse número deve ser sempre diferente de zero, porque temos que ter uma lacuna nos números de sequência para tem um pacote fora de ordem, supondo que não haja duplicação de pacotes). Tenho certeza de que existem alguns casos extremos estranhos com pacotes duplicados ou combinações de perda e reordenamento que farão isso cair, mas até onde posso dizer a única maneira de contar com precisão a perda em cenários como este é manter um bitmap de todos os números de sequência e marque os números de sequência que realmente vimos. Isso parece bastante complicado.

Portanto, neste ponto, estou considerando fazer aquele pequeno ajuste no processamento fora de ordem, alterando a mensagem de erro agora e adicionando alguma documentação interna explicando o que o código está fazendo. Não tenho uma maneira fácil de testar isso, entretanto ... Estou aberto para sugestões de como testar isso de uma forma um tanto controlada.

@ bmah888 Se você deseja testar pacotes fora de ordem e / ou perda de pacotes, você pode usar a ferramenta 'tc' no Linux:
https://wiki.linuxfoundation.org/networking/netem#packet -re-ordering

por exemplo:

# 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...

Após executar esses comandos, execute o iperf normalmente (use a máquina em que executou 'tc' como remetente) e observe a perda ou reordenação do pacote.

Você também deve ser capaz de usar esses comandos com "lo" em vez de "eth0" se quiser fazer o teste no adaptador de loopback.

(Provavelmente, existem maneiras mais concisas de usar esses comandos, mas este é o método ao qual estou acostumado.)

@AndrewJDR : Obrigado pela informação, foi uma grande ajuda para começar. Na VM CentOS 7 que estou usando, preciso fazer algo um pouco diferente, como este:

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

Agora testando com este servidor:

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

E este cliente:

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

Eu precisava aumentar a taxa de bits de envio de UDP no cliente, porque com o padrão, parece que os pacotes não estão espaçados o suficiente para que o reordenamento netem tenha algum efeito. 15Mbps parece ser rápido o suficiente para que vejamos alguma quantidade de reordenamento, mas não ficamos sobrecarregados com a saída.

@ bmah888 Obrigado por isso ... Vou tentar fazer isso da próxima vez que estiver executando alguns testes de iperf, e direi como funciona.

Eu mesclei essa solicitação de pull (# 589) para masterizar após alguns testes, com base no fato de que o comportamento anterior foi bastante interrompido e não é provável que piore mesmo se minha solução não funcionar. Não acho que seja completamente correto em todos os casos BTW, mas conta corretamente (ou perto de corretamente) nos casos que tenho testado. Fechando este problema por enquanto ... ele pode ser reaberto se necessário.