Veo tiempos de ping erráticos y a veces muy largos en mi enrutador wifi que está a solo un salto de distancia. Pinging a 192.168.1.1veces da tramos de latencias de 400-800ms.

Hay muchas cosas para probar (firmware, ubicación del enrutador, canal AP, etc.), pero me gustaría atacar este problema de manera más metódica:

• Primero, ¿cómo puedo visualizar el rendimiento de mi red?
• Entonces, ¿cómo puedo comparar el rendimiento de una configuración dada para poder comparar de manera confiable después de hacer ajustes?

Esta respuesta predeterminada del servidor tiene una buena guía de alto nivel sobre qué hacer, así que comience con eso. Sin embargo, el último paso es realmente deslumbrante: presumiblemente usted (quiero decir, yo) no desea invertir en hardware dedicado para esto ...

A continuación se presentan algunas buenas herramientas, primero para comprender el estado de la conectividad dentro de la red wifi local y luego a un punto final de Internet.

Herramientas wifi

NetSpot (para mac)

Realiza un seguimiento de los puntos de acceso WiFI locales y proporciona datos básicos como SNR, Canal, Intensidad de la señal. También puede hacer un estudio básico del sitio para un espacio físico que indique las fortalezas y la interferencia. En el modo de descubrimiento AP, también puede trazar la intensidad de la señal a lo largo del tiempo, lo que le permite probar ubicaciones y ajustar las posibilidades de interferencia.

Prueba de velocidad de Wifi para Android

Muy útil. Ejecutará un servidor Python simple en su máquina y la aplicación puede probar algunos escenarios, proporcionándole comentarios sobre la velocidad en tiempo real.

Wifi Analyzer , otra gran aplicación de Android, tiene algunas vistas valiosas de qué canales wifi AP están activos. Podría ser la mejor herramienta gratuita para elegir el canal AP sin hacer mucho trabajo.

iPerf

Herramienta muy respetada para comprender el rendimiento de la red local. Necesita dos cajas, una como servidor y otra como cliente. Puede configurar una serie de parámetros, ejecutar una prueba y ver los resultados de ancho de banda y fluctuación de fase. Prefiero usarlo con la GUI jPerf para trazar resultados y ajustar 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

Salud de conectividad a internet

mtr (ping y traceroute combinados)

Hace sonar todos tus saltos de traceroute. Proporciona datos de tendencias. Loco impresionante.

brew install mtr
mtr 8.8.4.4

speedtest-cli

La versión CLI de la cosa común de ookla speedtest.net. El responsable del proyecto declara que no es consistente, pero aún así, es útil tratar de medir grandes diferencias.

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 : ruta de red y diagnóstico de aplicaciones

Servidor de diagnóstico automático para solucionar problemas de sistemas finales y problemas de red de última milla. Después de ejecutar una batería de pruebas, aparece una página de Resumen de resultados como esta . Recomiendo usar este enlace de redireccionamiento del servidor NPAD para encontrar el servidor NPAD más cercano (están todos) y usar ese nombre de host para sus pruebas.

  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

Mis resultados personales:

Pasé unas buenas horas haciendo todo esto, probando cosas diferentes (cambiando de DD-WRT a firmware de tomate) y leyendo. Resulta que no era una capa de red y era una buena interferencia de RF, ¡principalmente de Bluetooth! Tenía mi computadora, un mouse bluetooth y un teclado a menos de 5 pies del enrutador. (Y el antiguo enrutador todavía está en 2.4Ghz donde chocan).

Para esto, aproveché al máximo la prueba de velocidad de Wifi para Android , ejecutándola regularmente mientras movía las cosas en el apartamento. Dado que informa actualizaciones cada 200 ms aproximadamente, se comunicó claramente cuando la interferencia estaba cayendo mis paquetes.

Definitivamente recomiendo leer la guía de Fuentes comunes de interferencia de Metageek. (También hacen InSSIDer y otras herramientas de análisis Wifi que parecen buenas).

Una herramienta que no tenía era un medidor de análisis de espectro físico. Los teléfonos y las computadoras portátiles solo pueden detectar APs Wifi, pero no pueden detectar la interferencia de Bluetooth u otras tecnologías basadas en RF. Metageek tiene algunas buenas soluciones en este espacio ( Wi-Spy e inSSIDer Office ) y esperamos ver surgir más herramientas como AirShark .

Como se señaló en mi comentario anterior: las herramientas comúnmente utilizadas para diagnosticar problemas de Wi-Fi en realidad pueden causar este problema. Al buscar redes Wi-Fi, la radio tiene que salir del canal, por lo general, le dice al AP que la guarde en tramas para que pueda 'dormir' y luego cambia los canales para buscar.

Además, iOS y OS X desde que se introdujo AirDrop, quitarán la radio Wi-Fi del canal para buscar otros servicios de AirDrop y dado que Yosemite se desconectará periódicamente del canal para admitir la transferencia.

Así que también tuve estas fluctuaciones de ping de Wi-Fi en el enrutador.

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

Cambié el enrutador (de TL-WR743ND a DIR-815), probé varios adaptadores USB de Wi-Fi (en su mayoría TP-LINK, aunque creo que también tuve el problema con D-Link DWA-160), pasé de 2.5 GHz a 5GHz y recorrió los canales. Sin suerte, el problema persistió.

Hasta que noté que cuando hago una prueba de velocidad de red o ejecuto un cliente bittorrent, el ping está bien. Solo fluctúa cuando la red está inactiva.

Puede ser un problema de Windows 7 o algo con mis adaptadores TP-LINK, pero cuando le doy un poco de carga al Wi-Fi, la fluctuación desaparece y la red funciona bien.

Hasta ahora he hecho un pequeño programa de Rust para mantener activa mi red Wi-Fi.

// 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));}}