[GTER] Melhor maneira de mensurar throughput em uma rede WAN
Alfredo Dal´Ava Júnior
alfredo.dalava at gmail.com
Fri Sep 4 17:37:43 -03 2009
Ola pessoal,
Eu penso que se o teste é para atestar a performance, o teste então deveria
ser misto entre TCP/UDP/ICMP, com diferentes tamanhos de pacotes, próximo de
uma média de tráfego real.
O objetivo principal de um teste assim não é ver simplesmente quantos Mbps
se consegue passar, e sim quanto se consegue passar com qualidade, sem
aumento de latência nem perda de pacotes. De que adianta passar 32Mbps no
teste sendo que aos 25Mbps começa alta latência e perda de pacotes quando se
coloca o "tráfego real"?
Portanto, na ausência de ferramentas mais precisas, eu costumo medir trafego
via iperf com TCP mesmo, e verificar o máximo que se consegue passar sem
perda de pacotes. Com o resultado do teste, jogo a garantia do enlace de
rádio pra um valor entre 10 e 20% abaixo do resultado do teste, como margem
de segurança.
Vale lembrar que os enlaces de rádio são sensíveis à outros fatores tão
importantes quanto o "Mbps", ex: quantidade de pacotes por segundo, chuva,
neblina, tempestades, inteferências constantes ou ocasionais, pequenas
movimentações da torre/antena por causa do vento....
Pra mim o throughput mais "honesto" é encontrado nos testes baseados
próximos do "pior caso". O que se consegue a partir daí é lucro.
Obs: minha experiencia se limita a enlaces de rádio de baixo custo, em
frequencia livre.
[]'s
Alfredo
2009/9/4 Julio Arruda <jarruda-gter at jarruda.com>
> Diego Eduardo wrote:
>
>> Egberto,
>>
>> Não testamos UDP ainda, mas eu acho que não vamos encontrar resultados
>> diferentes...
>>
> Sim, voces vao...TCP, ainda mais com perda de pacotes, vai ter uma
> performance muito inferior. Nao quer dizer que e' melhor, mas com UDP, oce
> pode chegar a quanto esta passando, nao importanto o que o link esta
> droppando, com TCP, TCP vai tentar contornar o gargalo, e seu goodput vai
> ser com certeza pior..
> Eu testaria com UDP, gradualmente crescendo os volumes, ate o ponto antes
> de perder pacotes.
>
>
More information about the gter
mailing list