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

Wed May 23 17:55:25 -03 2007

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:
> Pessoal,
> 
>      Recebi várias sugestões para resolução do problema que
> apresentei. Agradeço por todas elas. Na tentativa de otimizar a
> leitura e reduzir o número de respostas para a lista, fiz um resumo do
> problema e das sugestões.
> 
>      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.
> 
>      Com relação às sugestões recebidas:
> 
> Cristiano R. Maciel <cristiano.maciel at inovatelecom.com.br> 	
> 
>> humm... eu verificaria as rotas que estão sendo utilizadas para estes
>> servidores que você está testando... tente pegar servidores que não
>> compartilhem a mesma rota a partir da saída do backbone da sua
>> operadora.
> 
>      Os testes foram feitos, também, com servidores que ficam dentro
> da própria tele. Na fase final dos testes, chegaram a configurar outro
> servidor, pois estavam desconfiando do anterior. Neste novo servidor,
> os testes não prosseguiram, devido aos motivos que explico no final
> desta msg.
> ===================================================================
> 
> Christian Lyra <lyra at pop-pr.rnp.br> 	
> 
>>>       Bem, nos testes que fiz, havia um dload de ftp a 1000 kbit/s,
>>> que permanece estável ( pequenas oscilações ). Quando faço um
>>> upload, mesmo que esse upload esteja longe dos 4.0 mbits/s
>>> (exemplo, 3 mbits/s), o dload cai para valores em torno de 600-700
>>> kbits/s. Se eu apenas faço um upload (sem dload), ele fica próximo
>>> dos 4.0 mbits.
> 
>>       Isso era mais ou menos esperado... Provavelmente, como vc
>> saturou o link, vc tá perdendo uns ACKs do TCP, isso faz com o
>> próprio protocolo tente se ajustar a nova situação.
> 
>      Sim, no entanto, mesmo antes dos números atingirem o limite do
> canal, saturando o link, já havia perda de velocidade. Teoricamente,
> penso eu, mesmo usando TCP, se houver banda suficiente para manter os
> ACKs e o fluxo de dados, nos dois sentidos, a perda de velocidade não
> deveria ocorrer ou, no pior caso, ser menos drástica.
> 
>>       Acho que um teste melhor seria usar UDP nos dois sentidos,
>> porque dai vc consegue saturar as duas direções de forma
>> independente.
> 
>      Certamente. Aliás, isso é o que acontece com o chamado tfgen. No
> entanto, como eu disse no e-mail original, a minha intenção era
> testar, na prática, o que aconteceria com o uso normal da rede, ou
> seja, tráfego quase que total de HTTP/FTP.
> ===================================================================
> 		
> allan <allan.linuxmg at gmail.com> 	
> 
>> Os sites remotos de down/upload suportão essa velociadade?
> 
>      Conforme citei antes, há servidores de testes dentro da própria
> tele que, segundo eles mesmos, suportam tais velocidades, pois são
> usados para testar, inclusive, serviços com bandas maiores.
> ===================================================================
> 
> Rafael Possamai <rafaelpossa at gmail.com> 	
> 
>> Vale lembrar que os 4mbits são alcançados em condições muito boas,
> tanto no >seu lado como no outro lado... O gargalo pode estar na sua
> estrutura, ou na >estrutura da tele ou na estrutura da outra ponta,
> um site que você faz download >por exemplo...
> 
>      Certamente que o gargalo poderia estar na estrutura da empresa
> cliente. No entanto, a máquina usada consegue, em uma LAN, manter
> taxas muito maiores, usando o mesmo conjunto ( soft/hard ). Apenas a
> máquina de testes estava ligada ao roteador. O switch usado, novo e
> testado (3COM baseline 2250plus), tem 48 portas e somente duas estavam
> ativas. Logo, creio eu que a estrutura da empresa não estava causando
> o problema.
>      Além disso, segundo os gráficos da tele, o tráfego com o
> aplicativo de testes estava ok e, segundo eles, há estrutura, no lado
> de lá e no caminho entre as pontas, suportam sem problemas a banda que
> estava sendo requisitada.
> 
>> Além de fazer o que o pessoal sugeriu, eu faria testes em diversos
> links >diferentes (na medida do possível é claro) todos com o mesmo
> site'/servidor, e >analisaria as rotas por eles utilizadas, aí dá pra
> ter uma noção mais ou menos >se vc realmente está com seus 4mbits em
> dia ou se tiver algum problema, ver se >é contigo, com a tele ou com a
> outra ponta...
> 
>      Bem, testes com vários links não será possível, no entanto, a
> tele já preparou um segundo servidor, como citei antes, para fazer
> novos testes. Como o tráfego está todo dentro do backbone da tele, a
> probabilidade de problemas é menor. Não me lembro de quantos saltos da
> origem ao destino, mas farei novamente o traceroute nos novos testes.
> Acredito, no entanto, que serão poucos.
> 
>> Uma outra coisa que vale levar em conta é que esses testes geralmente
>> alcançam o máximo da estrutura permitida na rede. Em casa tenho uma
> rede >simples de 100mbits e com esses testes consigo 94mbits... Agora
> com apache, >samba, ftp e ssh os valores alcançados são inferiores,
>> as vezes metade.
> 
>      Sim, concordo, pois o número de fatores envolvidos aumenta (
> disco, aplicação etc ). No entanto, testes locais (LAN), usando
> equipamentos menos 'potentes', mantiveram taxas de dload e upload,
> simultâneos, muito acima de 4mbits/s, ou seja, o gargalo,
> teoricamente, não seria a estrutura (software e hardware, no caso).
> 
>> Tente ver também no contrato quando desse link é garantido, pq as
> vezes vc tem > 4mbits só em teoria, vamos dizer. Depende muito do
> serviço prestado.
> 
>      Esse tópico foi bem negociado no princípio e, pelo menos no
> backbone da tele, são 4 mbits/s em teoria e prática, motivo pelo qual
> minha insistência nos testes.
> ===================================================================
> 
> Eduardo Ellery <eellery at rapix.com.br> 	
> 
>> Recomendo o programa IPERF!
> 
>      Já baixei, compilei e instalei para testes. Aliás, já tinha tempo
> que queria ter feito isso. :-)
>      Quando voltar aos testes, vou usar os comandos que sugeriu. No
> entanto, o que eu quero 'ver' é o funcionamento do serviço quando
> exposto ao tráfego real da rede, ou seja, qual seu comportamento
> quando eu realmente for usá-lo.
> ===================================================================
> 
>      Bem, reforço minhas desculpas pelo tamanho do texto.
> 
>      Agradeço a todas as sugestões que recebi, pois todas elas
> ajudaram a levantar novas questões, a corroborar algumas de minhas
> idéias e todas elas serão aproveitadas.
> 
>      Nesse momento, a tele recolheu o equipamento usado pois, no
> último dos testes, com um novo servidor que disponibilizaram, o
> técnico responsável percebeu que havia, segundo ele mesmo, MUITO erro
> de CRC na interface do roteador que estava ligada ao link de fibra
> ótica e, por isso, fariam novos testes, em laboratório, com o
> conjunto.
> 
>      Quando retornarem, colocarei em prática tudo o que está nesse
> e-mail e, espero eu, postarei aqui as notícias de que tudo está
> funcionando como devia.
> 
>      Um abraço a todos e obrigado pela atenção.
> 
> Freitas
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter