Estou vendo tempos de ping irregulares e às vezes muito longos no meu roteador wifi, a apenas um salto de distância. 192.168.1.1Às vezes, o ping fornece trechos de latências de 400 a 800 ms.

Há muitas coisas para tentar (firmware, posicionamento do roteador, canal AP, etc.), mas eu gostaria de atacar esse problema um pouco mais metodicamente:

• Primeiro, como posso visualizar o desempenho da minha rede?
• Então, como posso comparar o desempenho de uma determinada configuração, para poder comparar de forma confiável depois de fazer os ajustes?

Esta resposta de falha no servidor tem boas orientações de alto nível sobre o que fazer - então comece com isso. Esse último passo é realmente confuso: presumivelmente você (quero dizer, eu) não quer investir em hardware dedicado para isso ...

Abaixo estão algumas boas ferramentas, primeiro para entender a integridade da conectividade na rede wifi local e, em seguida, para um ponto de extremidade da Internet.

Ferramentas Wifi

NetSpot (para mac)

Ele rastreia os pontos de acesso WiFI locais e fornece dados básicos como SNR, Canal, Intensidade do sinal. Também pode fazer uma pesquisa básica no local para um espaço físico indicando pontos fortes e interferências. No modo de descoberta de ponto de acesso, você também pode traçar a intensidade do sinal ao longo do tempo, permitindo testar canais e ajustar as possibilidades de interferência.

Teste de velocidade Wifi para Android

Muito útil. Você executará um servidor python simples em sua máquina e o aplicativo poderá testar alguns cenários, fornecendo feedback de velocidade em tempo real.

O Wifi Analyzer , outro ótimo aplicativo para Android, tem algumas visualizações valiosas sobre quais canais Wi-Fi AP estão ativos. Pode ser a melhor ferramenta gratuita para a escolha do canal AP sem muito trabalho.

iPerf

Ferramenta bem respeitada para entender o desempenho da rede local. Você precisa de duas caixas, uma como servidor e outra como cliente. Você pode configurar vários parâmetros, executar um teste e ver os resultados de largura de banda e tremulação. Eu prefiro usá-lo com a jPerf GUI para gráficos de resultados e ajustes de parâmetros.

brew install iperf
iperf -s # on server, next one on client
iperf -c 192.168.1.XXX -P 1 -i 1 -p 5001 -f m -t 60

Saúde da conectividade com a Internet

mtr (ping e traceroute combinados)

Pings todos os seus lúpulos traceroute. Fornece dados de tendência. Louco demais.

brew install mtr
mtr 8.8.4.4

speedtest-cli

A versão CLI da coisa comum do ookla speedtest.net. O mantenedor do projeto declara que não é consistente, mas ainda assim, é útil tentar avaliar grandes diferenças.

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
speedtest-cli --list | head # and chose a top server (sorted by distance)
speedtest-cli --server 2761 # re-use the same server

NPAD : caminho de rede e diagnóstico de aplicativos

Servidor de diagnóstico automático para solucionar problemas de sistemas finais e de última milha na rede. Depois de executar uma bateria de testes, fornece uma página Resumo dos resultados como esta . Eu recomendo usar este link de redirecionamento do servidor NPAD para encontrar o servidor NPAD mais próximo (todos eles estão acabados) e usar esse nome de host para seus testes.

  wget http://netspeed.usc.edu:8000/diag-client.c
  cc diag-client.c -o diag-client
# ./diag-client <server_name> <port> <target_RTT> <target_data_rate_in_MB/S>
  ./diag-client ps.psc.xsede.org 8001 30 5

Meus resultados pessoais:

Passei algumas horas fazendo tudo isso, tentando coisas diferentes (alternando do DD-WRT para o firmware do Tomato) e lendo. Acontece que não era uma camada de rede e era uma boa e velha interferência de RF, principalmente do Bluetooth! Eu tinha meu computador, um mouse e teclado bluetooth a menos de um metro e meio do roteador. (E roteador antigo ainda em 2.4Ghz onde eles se chocam.)

Para isso, tirei o máximo proveito do Wifi Speed ​​Test para Android , executando isso regularmente enquanto movia as coisas pelo apartamento. Uma vez que relata atualizações a cada 200ms, mais ou menos, comunicava-se claramente quando a interferência estava descartando meus pacotes.

Definitivamente, recomendo a leitura do guia Common Sources of Interference de Metageek. (Eles também fabricam o InSSIDer e outras ferramentas de análise Wifi que parecem boas.)

Uma ferramenta que eu não tinha era um medidor de análise de espectro físico. Telefones e laptops podem detectar apenas pontos de acesso Wifi, mas não conseguem captar interferências de Bluetooth ou outras tecnologias baseadas em RF. Metageek tem algumas soluções legais nesse espaço ( Wi-Spy e inSSIDer Office ) e esperamos ver mais ferramentas surgindo como o AirShark .

Conforme observado no meu comentário acima: As ferramentas comumente usadas para diagnosticar problemas de Wi-Fi podem realmente causar esse problema. Ao procurar redes Wi-Fi, o rádio precisa sair do canal, normalmente diz ao AP para armazenar em buffer quadros para que ele possa "dormir" e depois muda de canal para varredura.

Além disso, o iOS e o OS X desde que o AirDrop foi introduzido retirarão o rádio Wi-Fi do canal para procurar outros serviços do AirDrop e, uma vez que a Yosemite periodicamente sairá do canal para oferecer suporte à transferência.

Então, eu também tinha essas flutuações de ping do Wi-Fi no roteador.

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=63 time=2.334 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=1.813 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2749.664 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=1748.912 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=748.162 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=1.796 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=1.806 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=1.991 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=1.797 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=1.832 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=1.713 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=1.819 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=1.616 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=1.748 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=1.677 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=3427.213 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=2426.371 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=1425.634 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=424.834 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=1.829 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=1.691 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=2.038 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=1.679 ms
^C--- 192.168.0.1 ping statistics ---
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.616/564.346/3427.213/1015.102 ms

Troquei o roteador (de TL-WR743ND para DIR-815), tentei vários adaptadores USB Wi-Fi (principalmente TP-LINKs, embora acho que também tive o problema com o D-Link DWA-160), passou de 2,5 GHz para 5GHz e vasculhou os canais. Sem sorte, o problema persistiu.

Até que notei que, quando faço um teste de velocidade da rede ou executo um cliente bittorrent, o ping está correto. Apenas flutua quando a rede está ociosa.

Pode ser um problema do Windows 7 ou algo dos meus adaptadores TP-LINK, mas quando dou uma carga no Wi-Fi, a flutuação desaparece e a rede funciona bem.

Até agora, criei um pequeno programa Rust para manter minha rede Wi-Fi ativa.

// Need a constant wifi load in order not to have the ping drops.
fn wifi_load() {
  // This *might* be useful if the router suddenly supports Keep-Alive.
  // Not the case with DIR-815 though, we'll keep making new connections to it.
  let config = hyper::client::pool::Config {max_idle: 1};

  let client = hyper::client::Client::with_pool_config (config);
  loop {
    let url = "http://192.168.0.1/css/init.css";
    if let Err (err) = client.get (url) .send() {
      log! ("wifi_load] Error fetching {}: {}", url, err);
      sleep (Duration::from_secs (9));}
    sleep (Duration::from_millis (100));}}