iperf dando resultados incorretos

3

Acabei de instalar uma nova banda larga e queria testar sua taxa de transferência usando o iperf3. No entanto, parece estar dando resultados consideravelmente diferentes do que os testes de velocidade mais convencionais.

E:\tmp> iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  sender
[  4]   0.00-10.01  sec  13.1 MBytes  11.0 Mbits/sec                  receiver

Considerando que os testes de velocidade on-line mostram os resultados esperados de ~ 150 Mbits

3.testdebit.info foi testado a partir do azure e é consistentemente em torno de 330Mbits (embora quem sabe o que isso significa mais!)

Eu tentei vários servidores diferentes, incluindo uma caixa linux hospedada no azure - que entrega ~ 100Mbits para outra caixa azul. Isso também foi executado na porta 80, para descartar qualquer limitação do ISP. Todos esses resultados são comparáveis.

Baixando um arquivo de 3.5gb em 210 segundos, funciona para aproximadamente 130Mbit

Alguém pode lançar alguma luz sobre por que o iperf3 pode ser tão baixo (ou eu estou sendo muito estúpido e lendo algo errado!)

Estes estão todos no mesmo computador, através de ethernet, então sem wireless, etc, para atrapalhar.

editado para adicionar

Realizar o mesmo teste com o iperf2 (no Windows Client (iPerf 2.0.5-3) e no Ubuntu (iperf versão 2.0.5)) fornece estes resultados

E:\tmp\iperf2> iperf -c <hidden>.cloudapp.net -p 5201
------------------------------------------------------------
Client connecting to <hidden>.cloudapp.net, TCP port 5201
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 51816 connected with <hidden> port 5201
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  12.1 MBytes  10.0 Mbits/sec

O mesmo realizado a partir de um NAS baseado em linux

Nas:~# iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  14.5 MBytes  12.2 Mbits/sec                  receiver

E com o sinalizador -R

E:\tmp> iperf3 -c 3.testdebit.info -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  58.0 MBytes  48.6 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  57.0 MBytes  47.8 Mbits/sec                  receiver

Para garantir que não seja um problema no servidor, atualizei a VM do azure para um tamanho que agora retira 600 Mbit / 1Gbit do servidor 3.testdebit.info

Em resposta à resposta de John Looker

Meu principal objetivo da questão foi tentar entender por que o iperf estava dando resultados tão variados. Entendo que os envios são muito compartilhados e não estão muito preocupados com isso (ou pelo menos é uma pergunta diferente!)

Os servidores do Azure que eu estava usando estavam no norte e no oeste da Europa (acredito que Amsterdã e Irlanda) e com um teste de velocidade on-line alcançado na área de 240Mb / s

No entanto, parece que o multithreading foi o problema. Acabei de executar novamente o teste, usando quatro threads em vez do padrão -

E:\tmp>iperf3 -c 3.testdebit.info -R -P 5
Connecting to host 3.testdebit.info, port 5201
Reverse mode, remote host 3.testdebit.info is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[SUM]   0.00-10.00  sec   195 MBytes   163 Mbits/sec   50             sender
[SUM]   0.00-10.00  sec   190 MBytes   160 Mbits/sec                  receiver
    
por Michael B 13.08.2015 / 19:32

2 respostas

1
  1. Os bons testes de velocidade convencionais são multiencadeados e criam várias conexões ao servidor de teste de velocidade. Assim, maximizando sua conexão com todo o seu potencial.

link

  1. iPerf3 parece criar apenas duas conexões (usando as opções padrão), o que pode não ser suficiente para maximizar sua banda larga de 152Mb, particularmente quando o congestionamento entra em ação.

  2. Seu teste de download também sugere conexões multi-threaded.

Downloading a 3.5gb file in 210 seconds, works out to approximately 130Mbit

Seu cálculo está errado, no entanto.

((3,5 GB x 8bits x1024x1024x1024) / 210s) / 1000000Mbit = média de 143Mb / s.

Uma velocidade média de 143Mb / s é boa para um download no nível de 152Mb.

Enquanto o nível de 152Mb atinge o máximo da velocidade de download de 161Mb / s (seu modem possui perfil excessivo para garantir velocidades), as velocidades médias costumam ser ligeiramente menores devido a vários fatores.

  • Taxa de limitação pelo servidor.
  • A Janela de Recepção TCP precisa de tempo para aumentar a velocidade.
  • Ciclo de concessão de solicitações de modem a cabo.
  • Congestionamento no nó. Você está compartilhando sua conexão a cabo (e, portanto, seus canais downstream) com centenas de outras pessoas. Os 8x 256 canais QAM downstream que você bloqueou em seu modem a cabo têm uma largura de banda máxima utilizável de 400Mb no total, proveniente do nó. Isso é compartilhado entre você e todos os outros usuários em seu cabo com os mesmos canais que você. Quando outros usuários estão usando a conexão durante o download, as velocidades variam um pouco.
  • Congestionamento na rota.
  • Congestionamento no servidor.
  • Qualquer perda de pacotes e retransmissão.

A largura de banda upstream é altamente sustentada por outros usuários em seu cabo para o nó.

Se você tem 2 x 16 canais upstream QAM bloqueados, então você está compartilhando 2 x 17Mb = 34Mb com muitos outros usuários. Se você tem 2 canais de upstream de QAM 64 bloqueados, então você está compartilhando 2 x 27Mb = 54Mb com muitos outros usuários.

  1. Em longas distâncias, a latência se tornará um fator nas velocidades que você pode alcançar.

Você não declarou qual servidor do Azure estava usando, seja no Reino Unido, na Europa ou na América.

O seu servidor iPerf3 está na França e pode ou não encaminhar através do LINX, dependendo da sua localização. O congestionamento na rota pode ser um problema, às vezes, uma vez que deixa a rede da VM, especialmente nos pontos de peering.

  1. Portas não padrão geralmente são tratadas como tráfego P2P. link

Embora não haja gerenciamento de tráfego downstream em downloads, streaming, jogos e assim por diante, nos níveis de 30Mb e acima, se seu tráfego for classificado como P2P, ele será gerenciado pelo tráfego e a velocidade reduzida durante os horários de pico.

A razão é que a largura de banda do upstream é muito escassa, pois é compartilhada por centenas de usuários, e assim qualquer programa que possa inundar o upstream seria muito ruim para todos no seu cabo. É também por isso que o upstream ainda é gerenciado pelo tráfego.

Fora do horário de pico, você deve conseguir maximizar sua conexão da maneira que desejar.

  1. Cuidado com testes que usam arquivos pequenos. Há uma variedade de arquivos de teste que você pode usar aqui: link

  2. Seu download provavelmente não será entregue por um CDN ou armazenado em cache dentro da rede da VM. Quando eu estava no 152Mb eu baixei regularmente e transmiti em 161Mb diretamente dos servidores. Os CDN tendem a tornar a entrega mais lenta do que mais rápida!

Você precisa fornecer mais detalhes sobre sua estratégia de teste para responder à pergunta original.

    
por 21.08.2015 / 05:50
3

Tenha em atenção que o IPerf assume como padrão um teste de "upload": O cliente IPerf ( -c ) envia dados TCP para o servidor IPerf ( -s ). Parece que você estava executando o cliente em sua LAN e conectando-se a um servidor IPerf hospedado na Internet pública, então você estava testando o upload, não o download, a velocidade da sua nova conexão de banda larga.

Para testar sua velocidade de download, inverta a extremidade que você chama como -s / -c ou use -r para especificar que você deseja fazer um teste "reverso" (download) depois que ele fizer o normal teste.

Tenha em atenção que, se a sua máquina LAN estiver por trás de um NAT ou firewall, poderá ter de abrir / mapear / encaminhar uma porta de forma adequada para que o teste de transferência funcione.

    
por 13.08.2015 / 20:10