Por que a discrepância entre Speedtest e Wget?

18

Meu cliente reclama de baixas velocidades de internet. Quando medido com o Speedtest.net, as velocidades são aceitáveis. Downloads medidos periódicos são de 10% a 30% da velocidade nominal. Eu não posso explicar isso.

Algum plano de fundo. A conexão problemática está em uma daquelas ilhas ensolaradas do Caribe, onde a internet rápida não é o maior patrimônio. Ultimamente, a velocidade da internet se tornou decente, até 200 Mbps. Mas a viagem de ida e volta para (digamos) Amsterdã é de cerca de 180 ms.

O cliente possui uma conexão de fibra de 100 Mbps. Ao executar um teste de velocidade em uma máquina Windows (speedtest.net) para o provedor de serviços de Internet, obtemos 95 Mbps. Ao usar o mesmo teste de velocidade em Amsterdã, chegamos a 60-70 Mbs. Totalmente aceitável.

Há algum tempo, instalei um RasPi que periodicamente retira o arquivo de um dos meus servidores em Amsterdã. Em um datacenter, diretamente conectado ao AMS-IX. Usando este comando:

wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt

O arquivo .txt tem 23 MByte de números. (Na verdade, é o único, mas maior Mersenne Prime, 23e6 dígitos)

Quando faço o download desse arquivo na rede problemática, o wget relata o seguinte:

dev/null 100%[====================================================================>]  22.81M  11.6Mb/s   in 17s    

2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]

Isso é ao mesmo tempo que o speedtest.net relata 60-70 Mbps.

Eu sei que o Raspi tem suas limitações. Mas essa velocidade varia muito. Uma vez que o RasPi relata esses 11 Mbps, na próxima vez 22 Mbps. Mas, às vezes, tão baixo quanto 1,5 Mbps.

Quando faço esse teste com um laptop realmente poderoso, as velocidades máximas são um pouco mais altas (até 30 Mbps), mas também mostram os mesmos pontos baixos. Portanto, indica uma limitação do RasPi no lado alto, mas não os 10 Mbps no lado baixo.

Emiti exatamente o mesmo comando de um servidor em Munique, Alemanha, em um datacenter. Velocidade 96 Mbps.

Em seguida, de um consumidor de conexão de fibra de 100 Mbps na Holanda: 65 Mbps.

Então, na minha casa, que tem ADSL nominal de 10 Mbps. Speedtest mostra 10Mbps. O Wget oferece 8,5 Mbps. O que é igual no meu livro.

Isso exclui qualquer limitação no servidor que atua como host para o download do arquivo.

Não espero que alguém possa apontar a causa da lentidão da conexão nas instalações do cliente. Mas alguém pode explicar a discrepância entre o speedtest.net e o wget?

Existe algo que o speedtest ignora ou mede apenas os picos? Ou o wget é seriamente influenciado por longos tempos de ping?

Eu sinto que o teste wget fornece a velocidade real e efetiva, enquanto o speedtest é principalmente para mostrar a velocidade anunciada.

— Hans Linkels
fonte

Outra maneira de verificar a velocidade é fazer isso ssh personal-server cat /dev/zero | pv > /dev/null, em um servidor pessoal que você sabe que a taxa não é limitada a ser mais lenta do que a velocidade esperada.

— JoL

Eu olhei sua pergunta. E parece que você tem uma grande largura de banda e talvez um cenário significativo de atraso de ida e volta, também conhecido como "rede longa e gorda". Eu experimentei esse tipo de coisa pessoalmente e resolvi abrindo muitas conexões (eu usei o rsync). Você pode tentar abrir várias instâncias do wget (tente 5, 10, 20)? A página da Wikipedia é: produto de atraso de largura de banda.

— Trevor Boyd Smith

Relatórios do Wget em bytes por padrão: [james @ root de lamia] $ wget -O / dev / null 10.32.48.1/t1 / dev / null 100% [================= ====>] 100.00M 112MB / s em 0.9s [james @ lamia root] $ wget --report-speed = bits -O / dev / null 10.32.48.1/t1 / dev / null 100% [=== ==================>] 100.00M 932Mb / s em 0.9s

— james

Considere executar um servidor iperf para tcp e um segundo para udp em sua máquina hospedada em DC. Então, como parte do trabalho cron, chame um teste do seu cliente e veja como as velocidades se comparam com o http.

— Criggie

Que tipo de arquivo é esse? É compressível e o servidor suporta compactação http? Embora não seja possível corrigir problemas de largura de banda, você poderá diminuir o arquivo.

— Salman A

16

Além dos outros motivos publicados, as conexões TCP não funcionam bem com arquivos grandes quando o produto de atraso de largura de banda se torna grande.

Como em uma conexão rápida com uma ilha.

Veja a entrada da Wikipedia sobre ajuste de TCP .

Portanto, o Speedtest pode despejar um arquivo pequeno por meio da conexão a 95 mb / s, mas wgetpode obter apenas 10 mb / s em um arquivo de 20 MB.

— Andrew Henle
fonte

2

Este é um novo conhecimento para mim. Muito bom. De fato, o produto de atraso de largura de banda é alto (2,25 MB, se calculado corretamente). Uma rápida olhada mostrou um buffer padrão de 87kB e um máximo de 3,5 MB. (Presumo Byte não bits). Eu tenho que mergulhar mais profundamente nisso para melhor avaliar. Se, em conjunto, o speedtest baixa muitos arquivos pequenos e registra a velocidade máxima, isso explica muito.

— Hans Linkels

21

Os ISPs geralmente priorizam o tráfego no speedtest.net para que eles possam se gabar da rapidez com que suas conexões são, enquanto na realidade eles não fornecem tanta largura de banda. Eles estão perfeitamente cientes de que a maioria dos usuários verifica apenas esse site para confirmação.

Você também deve ter em mente que a velocidade de transferência depende do cliente e do servidor. No mundo de hoje, a maioria dos servidores acelera de uma maneira ou de outra.

Por fim, não faz sentido esperar largura de banda estável para conexões no exterior. Simplesmente não existe tal coisa. Ele precisa passar por um número infinito de comutadores, fibras e datacenters para chegar ao local final. E basta apenas uma parte móvel para diminuir a velocidade.

— bviktor
fonte

Entendo suas declarações, exceto pela limitação no lado do servidor. É meu próprio servidor e, quando o cliente está em um data center diferente (a cerca de 1200 km), a velocidade é consistentemente de 95 Mbps. Mesmo se o cliente estiver em uma conexão de consumidor de 100 Mb, é de 65 Mbps.

— Hans Linkels

9

Você pode documentar sua reivindicação? "ISPs geralmente priorizam o tráfego no speedtest.net"

— Soleil em

1

@Soleil Não demorou muito no Google: myce.com/news/…

— MonkeyZeus

6

Um provedor de serviços de Internet que priorize o tráfego do speedtest é tão provável quanto um grande fabricante de carros falsificando testes de emissão.

— Barmar

3

Curiosamente, uma vez fui capaz de "consertar" um fluxo gaguejante do Super Bowl enviando tráfego para speedtest.net repetidamente a partir de um Raspberry Pi. Parecia que eles priorizavam toda a minha conexão, desde que houvesse tráfego de velocidade mais rápida - diferença de dia e noite. Não há muita evidência de que os ISPs façam coisas obscuras, mas é alguma coisa.

— Desfazer

7

wgetdê uma boa medida prática da velocidade. Os testes do Speedtest provavelmente incluem um tipo de paralelismo que pode explicar números mais altos.

Para um bom teste de velocidade média, acho que o tempo para o download deve ser de pelo menos 90 a 120 segundos (para obter uma boa média)

— Romeo Ninov
fonte

Estou trabalhando na instalação de um computador de registro mais poderoso e para aumentar o tamanho do arquivo.

— Hans Linkels

Você pode desenvolver "tipo de paralelismo"? Não vejo nenhuma maneira / razão, pois existe uma conexão a priori 1.

— Soleil

1

@ Soleil, IMHO eles baixam alguns arquivos, não apenas um. Você pode testá-lo executando poucos wgete somar a velocidade

— Romeo Ninov

1

Eu poderia paralelizar minha medição, mas qual é o benefício? Eu já demonstrei que outros clientes atingem velocidade máxima. A diferença é que a conexão problemática tem uma latência de 180 ms. As conexões rápidas <10 ms. Paralela diminuiria os efeitos de latência? Só perguntando.

— Hans Linkels

1

@ RomeoNinov eu verifiquei, não existe esse paralelismo (speedtest.net). Um arquivo por upload e um por download ([1-2] MB cada).

— Soleil

3

Um motivo pode ser que muitas vezes a velocidade máxima não pode ser alcançada por apenas uma única conexão TCP.

O Speedtest.net introduziu recentemente um único modo de conexão. Tente isso e veja se isso faz diferença.

Em seguida, para o download, use, por exemplo, aria2 com parâmetros para usar várias conexões e comparar. por exemploaria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt

— Josef
fonte

2

Use o Fast.com Internet Speed Test , este é um teste de velocidade baseado na Netflix, o que significa que não pode ser diferenciado pelos ISPs da própria Netflix.

Este é um teste mais preciso do que qualquer outro teste em geral. As pessoas não ficarão preocupadas com a rapidez com que uma página da web é carregada, mas com a rapidez com que os vídeos são armazenados em buffer devido ao aumento da largura de banda necessária para exibir um vídeo.

Os ISPs geralmente aumentam a velocidade com base no domínio ao qual alguém está se conectando, se for um teste de velocidade ou usando a porta 8080. Enquanto o Netflix usa a porta 80, uma porta mais lenta quando está sendo priorizada.

— Jonathan
fonte

1

"significando que não pode ser diferenciado pelos provedores de Internet da própria Netflix" - Isso é falso, o ISP pode ver definitivamente a solicitação de DNS e o SNI na conexão HTTPS.

— Kevin

O @Kevin fast.com contata os servidores netflix para fazer o download, o que significa que emula vídeos do próprio netflix. Embora eu conceda a você, os provedores de serviços de Internet podem entender o fato de que a conexão a esse site específico que posteriormente entra em contato com servidores da Netflix exige uma priorização semelhante à speedtest.net

— Jonathan

Não é exatamente ciência de foguetes. Tudo o que eles precisam fazer é desacelerar o Netflix por alguns minutos ou horas depois de verem uma conexão fast.com. O lado positivo, é claro, é que você pode acessar o site fast.com para se controlar, fechar a guia e assistir à Netflix de verdade.

— Kevin

Pessoalmente, suspeito que seja ciência da computação ou pelo menos relacionada a ela, e não ciência do foguete. Parece que alguns dos maiores ISPs (por exemplo, Bell) não conseguiram acessar o fast.com nos últimos anos. De qualquer maneira, executar um script no seu computador que se conecte ao fast.com para aumentar a velocidade do seu download a cada momento, se a limitação for ruim o suficiente, seria viável.

— Jonathan

0

Sou eu ou ninguém percebeu que ele disse Mbps e a lista de comandos do wget "MB / s".

60mbp / s e, na verdade, obter 11.2Mb's é normal.

Mbps e MB / s são duas velocidades diferentes.

"um Megabit é 1/8 do tamanho de um Megabyte, o que significa que para baixar um arquivo de 1 MB em 1 segundo, você precisará de uma conexão de 8 Mbps." Então 11mbx8 = 88mbps ... 11,2Mb é realmente bom para um relatório de conexão 60-70mbps.

As pessoas que têm memória perdem a importância disso. Você nunca terá 70mb / s com uma velocidade mais rápida de 70Mbps

— blá Chesley
fonte

A saída de wgeté Mb / s, que se traduz em Megabits / s . MB / s seriam traduzidos para MegaBytes / s . Basta executar seu próprio wgetcomando e verificar o resultado.

— Thomas

1

@james: Sim, por padrão, mas no OP o wgetcomando inclui --report-speed=bitsquais resultados Mb/ssão quais Mbit/s. Correr sem --report-speed=bitsdá o MB/sque se traduz em MByte/s. Observe o be B.

— Thomas