[GTER] RES: Duvida IPERF

[Patrick Tracanelli]

On 28/05/2015, at 11:21, Fabio Focking <focking at univali.br> wrote:
> 
> Olá.
> 
> Realmente o meu link é ponto a ponto, roteamento L3 via rip.
> 
> Então quer dizer que essa perda de pacotes UDP não representa, necessariamente, um problema no transporte?
> 
> Atenciosamente,
> 
> Fábio Focking 
> Administrador de Redes
> 
> 
> 
> -----Mensagem original-----
> De: gter [mailto:gter-bounces at eng.registro.br] Em nome de Carlos Ribeiro
> Enviada em: quinta-feira, 28 de maio de 2015 10:43
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] Duvida IPERF
> 
> Fabio,
> 
> Não está claro se seu link é um ponto a ponto ou se é um link Internet (como é IP privado, imagino que seja ponto a ponto, mas você poderia ter um NAT e uma VPN e minha hipótese vai por água abaixo).
> 
> Entre outras coisas, a transferência TCP é sensível a latência. Você pode estar experimentando alguns tipos de perda ou timeout que não representam problemas no link em si, apenas características naturais do TCP.
> 
> Tente rodar dois iperfs ao mesmo tempo em paralelo, e some os resultados.
> Talvez faça alguma diferença.
> 
> Tente também rodar o teste de UDP.
> 
> Espero ter ajudado...
> 
> *Carlos Ribeiro*
> *Sócio*
> Cel: +55 (31) 9303-3366
> Tel: +55 (31) 3305-5620
> Geral: +55 (31) 3305-5600
> cribeiro at telbrax.com.br
> www.telbrax.com.br
> 
> Em 28 de maio de 2015 08:39, Fabio Focking <focking at univali.br> escreveu:
> 
>> Bom dia Pessoal.
>> 
>> Estou com uma dúvida referente ao report do iperf. Alguém poderia 
>> esclarecer por gentileza?
>> 
>> Tenho um link de 100Mbps e utilizei o iperf para homologar o link.
>> 
>> Eis os comandos:
>> 
>> Do lado do servidor: iperf -s -u -i 10 -p 43116 Do lado do cliente: 
>> iperf -c 10.7.100.5 -i 5 -u -p 43116 -b 92M -t 60
>> 
>> Resultado do teste: [  1]  0.0-300.0 sec   771 MBytes  21.6 Mbits/sec
>> 1.024 ms 1818199/2368030 (77%)
>> 
>> Isso quer dizer que o meu link está com 77% de perdas? Ele está ruim, 
>> certo?
>> Os testes TCP mostram que o link está ok, infelizmente não peguei o 
>> resultado dos testes TCP.
>> 
>> Alguém poderia confirmar se o teste que realizei está correto? Posso 
>> confiar nessa ferramenta?
>> 


Eu gosto do iperf mas noto divergencia em cada sistema. Com FreeBSD eu uso sempre iperf2 e não iperf3, em Linux ja vi variando os resultados dependendo de distro, versão de glibc, mas sempre a variação maior é nos testes UDP exatamente o que você fez.

Eu recomendo pra UDP sempre deliberadamente definir o bandwidth (você fez) mas também o tamanho dos pacotes (-l, só funciona UDP)

No seu teste você tentou mandar 92M mas a transmissão foi de 21M e 23% de drop. Você quer testar realmente paralelismo, resiliência a transmissão desordenada?

Sugiro que teste em modo TCP e compare os resultados. Teste bidirecional (-r) e teste paralelo (-P N) em modo TCP ja que provavelmente em TCP voce vai ter resultados melhores.. rode verbose a cada 1 segundo e veja os logs de sequencia errada entre server-client em modo UDP… 

Fazendo diversos probes vc vai entender a real condição do link.

No caso de TCP não da pra definir tamanho dos pacotes, ai o jeito é vc apelar e mudar a MTU de quem transmite (ou de ambos no teste bidirecional).

Só que dependendo da placa de rede Linux é bugado e se descer a MTU pode nunca mais subir sem rebootar a maquina. Boa sorte se for Linux e se a rede não for Intel. E não se engane o ifconfig vai dizer que a MTU voltou pro 1500 mas se vc ver com tcpdump a MTU ainda estará no valor anterior. Descer desce de boa mas subir pra MTU total quase sempre requer reboot, então se for testar algo parecido com RFC-2544 em frame sizes vai descendo sempre…

Resumindo, teste:

- UDP com pacotes de 64bytes, 512bytes e full MTU (se tiver tempo sobrando testa todos os frame sizes da RFC), ao menos 2 testes de cada, bidirecional/unidirecional e com bandwidth declarada no que voce espera, e com bandwidth 20% abaixo (se vc contratou 100M teste com -b 80M além de -b100M). Ou seja 3 tamanhos, 2 fluxos, 3 bandas, são pelo menos 12 testes.

- TCP com MTU 64bytes/72bytes (dependendo do Linux 64 n vai rolar pro iperf), 512bytes, full MTU, bidirecional, unidirecional, single flow ou paralelo (de novo são pelo menos 12 testes podendo ser ainda mais se vc ver que o paralelismo gera divergência, exemplo sem -P com MTU padrão se comporta de uma forma, com -P 2 com a mesma MTU se comporta de outra forma mas -P5 com a mesma MTU diverge muito do esperado, testa -P3, -P7, etc…)

Enfim testar é preciso, mas não acho justo com o fornecedor não fazer testes variados. Nem te respalda em nada, por exemplo, testar TCP com MTU FULL e dar OK no link contratado sem paralelismo pq simplesmente na vida real seus pacotes não vão passar com MSS no talo. Se vc busca fluxo de internet precisaria testar nos sizes 512-768 pra maior parte do tamanho médio. Da mesma forma que um resultado bem estranho pra UDP como esse que voce esta tendo, também não pode ser subsídio pra você dar pau no fornecedor.

Testa com tempo e sem pressa, prepara um shell script pra automatizar os cenários pra você. iperf é bom :) Um testador RFC2544 da Fluke, JDSU ou Ixia porém, seria mais uniforme e mais prático (e mais caro hehe), então reserva um tempo pros testes com iperf pra ter resultados mais conclusivos.

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"