[GTER] Teste de link com Internet para aceitação: dúvida trivial

[casfre at gmail.com]

Pessoal,

     Agradeço, novamente, a todos que enviaram suas idéias. Certamente
me ajudaram muito. Consegui fazer o teste, usando um servidor de FTP
dentro da operadora e obtive bons resultados, melhores até do que eu
esperava.

     Basicamente tenho gráficos de +-24 horas, usando FTP para enviar
e receber, simultaneamente, arquivos do servidor dentro da operadora.
Para 'abrandar' o comportamento do TCP, usei um wget com banda
limitada para o download e um script de controle de banda, usando tc,
para controlar o upload e alocar banda para os ACKs. Esse script pode
ser visto em http://lartc.org/howto/lartc.cookbook.ultimate-tc.html.

     Fiz ajustes para aumentar a banda e fui 'regulando' até conseguir
um equilíbrio entre up/down. O valor para o wget (- -limit-rate )
ficou em 468Kbytes/s e o UPLINK usado no script ficou em
4600(kbits/s). A propósito, a parte que controla o INGRESS eu não
usei. O tráfego no canal ficou ( com pequenas oscilações ) em torno de
4096 kbits/s ( 512KBytes/s ) nos dois sentidos, o que eu considerei
como muito bom.

     Durante estes testes, segundo informações da operadora, não houve
registro de erros de CRC nas interfaces do roteador, o que indica que
aquele problema havia sido resolvido.

     Além destes testes, fiz outros, usando o Iperf, nos dois
sentidos, simultaneamente, só que com UDP. O resultado foi bastante
parecido, no entanto, nesse caso, não houve necessidade do controle de
banda, como sugerido aqui.

     Os testes continuam e, até o momento, ainda não houve degradação
do link. Apenas para informação, o limite de banda fornecido pela tele
está sendo feito nas duas interfaces do roteador que fica na empresa.

     Uma vez mais, obrigado a todos pela ajuda.

Cássio

Em 23/05/07, Julio Arruda<jarruda-gter at jarruda.com> escreveu:
>
> Se voce fizer uma captura com tcpdump, e fizer um tcptrace no mesmo,
> voce chegaria a ter uma ideia da banda 'usada' e etc, retransmissoes e
> outras coisitas mais. O WireShark tem ferramentas similares (o tcptrace
> e' melhor para 'automatizar' relatorios e etc).
>
> Um fator importante e' que o limite da banda 'usada' e' baseada no
> produto entre a banda e o delay, e dependendo da sua janela TCP
> oferecida, voce pode ter melhor ou pior performance.
>
> Como voce menciona que com UDP esta tudo 'wirespeed' :-), parece que
> voce esta sofrendo efeitos sim do comportamento do TCP.
>
> Outra coisa tambem, perda de pacotes geralmente cria uma diminuicao de
> velocidade em tcp (em UDP na verdade ele esta se lixando), pois o TCP
> tenta se ajustar a rede (entra em congestion window e blabla).
>
>
> casfre at gmail.com wrote:
> >      Basicamente, o problema era testar um link de 4Mbits, simétrico,
> > fornecido por uma tele local. Os testes feitos com um aplicativo de
> > nome tfgen (UDP) mostraram, segundo gráficos da fornecedora, que as
> > velocidades estavam sendo atingidas e/ou superadas (tudo dentro de seu
> > backbone, claro).
> >      Meus testes usaram HTTP/FTP, logo, TCP e, nesses testes, os
> > valores ficaram bem abaixo do esperado. Durante tais testes, mesmo que
> > o valor de download estivesse, por exemplo, em 1 Mbits/s, um upload
> > de, por exemplo, 2.5Mbits/s era suficiente para fazer cair a taxa de
> > download para cerca de 700Kbits/s.
> >      Todas as minhas medidas foram feitas em um Slackware 11
> > (2.6.17.13), com iptraf, em um P4HT 3.2, 512MB, SATA II, Intell e1000
> > on board.
> >      Minha idéia é de que, se houver banda disponível para o fluxo de
> > download e upload e, obviamente, reserva desta banda para os ACKs, nos
> > dois sentidos, o tráfego não poderia sofrer a diminuição que sofreu e
> > deveria se manter próximo do que foi contratado.