¿Cómo puedo diagnosticar y visualizar los tiempos de ping altos en el router wifi?

Estoy viendo tiempos de ping erráticos ya veces muy largos a mi enrutador wifi que está a sólo un salto de distancia. Pinging 192.168.1.1 veces da tramos de latencias de 400-800ms.

Hay un montón de cosas para probar (firmware, ubicación del router, canal de AP, etc.), pero me gustaría atacar este problema un poco más metódicamente:

  • En primer lugar, ¿cómo puedo visualizar el rendimiento de mi red?
  • Entonces, ¿cómo puedo comparar el rendimiento de una configuración dada, para que pueda comparar confiablemente después de hacer ajustes?

Esta respuesta serverfault tiene buena guía de alto nivel sobre qué hacer – así que comience con eso. Ese último paso es un doozy real sin embargo: presumiblemente usted (quiero decir, yo) no quieren invertir en hardware dedicado para esto …

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

Herramientas Wifi

NetSpot (para mac)

Rastrea los puntos de acceso WiFI locales y proporciona datos básicos como SNR, Channel, Signal Strength. También puede realizar una inspección básica del sitio para un espacio físico que indique fortalezas e interferencias. En el modo de descubrimiento de AP, también puede graficar la intensidad de la señal en el tiempo, lo que le permite probar ubicaciones y ajustar las posibilidades de interferencia. Introduzca aquí la descripción de la imagenIntroduzca aquí la descripción de la imagenIntroduzca aquí la descripción de la imagen

Prueba de velocidad Wifi para Android

Muy útil. Ejecutarás un sencillo servidor python en tu máquina y la aplicación podrá probar algunos escenarios que te proporcionarán retroalimentación en tiempo real.

Introduzca aquí la descripción de la imagen

Wifi Analyzer , otra gran aplicación para Android, tiene algunas valiosas vistas de lo que los canales wifi de AP están activos. Puede ser la mejor herramienta gratuita para elegir el canal de AP sin hacer mucho trabajo.

IPerf

Herramienta bien respetada para entender el rendimiento de la red local. Usted necesita dos cajas, una como servidor, una como cliente. Puede configurar un número de parámetros, ejecutar una prueba y ver los resultados de ancho de banda y jitter. I perfer con el uso de la jPerf GUI para gráficos de resultados y ajustar los 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 -fm -t 60 

Introduzca aquí la descripción de la imagen

Salud de conectividad a Internet

Mtr (ping y traceroute combinados)

Pings todos sus traceroute saltos. Proporciona datos de tendencias. Loco increíble.

 brew install mtr mtr 8.8.4.4 

Speedtest-cli

La versión CLI de la cosa común 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 la aplicación

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, proporciona una página Resumen de resultados como ésta . Recomiendo usar este enlace de redireccionamiento del servidor NPAD para encontrar el servidor NPAD más cercano (ya 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 

Introduzca aquí la descripción de la imagen


Mis resultados personales:

Pasé unas pocas horas haciendo todo esto, probando cosas diferentes (cambiando de DD-WRT a firmware Tomato) y la lectura. Resulta que no era la capa de red y era buena vieja interferencia de RF, la mayoría de Bluetooth! Tenía mi computadora, un ratón bluetooth y un teclado dentro de 5 pies del enrutador. (Y el viejo enrutador todavía en 2.4Ghz donde chocan.)

Para esto, conseguí el máximo provecho de la prueba de velocidad Wifi para Android , corriendo con regularidad mientras me mudaba las cosas en el apartamento. Dado que informa actualizaciones cada 200 ms o menos, se comunica 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.)

Introduzca aquí la descripción de la imagen

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

Como se señaló en mi comentario anterior: Las herramientas comúnmente utilizadas para diagnosticar problemas con Wi-Fi pueden causar realmente este problema. Al escanear las redes Wi-Fi, la radio tiene que apagar el canal, normalmente le dice al AP que almacene los fotogramas para que pueda 'dormir' y cambie los canales a escanear.

Además, iOS y OS X desde que AirDrop fue introducido, tomará la radio Wi-Fi fuera del canal para buscar otros servicios de AirDrop y ya que Yosemite periódicamente apagará el canal para apoyar el traspaso.

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

 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), intentado varios adaptadores del USB de Wi-Fi (sobre todo TP-LINKs, aunque creo que tenía el problema con D-Link DWA-160 también), pasó de 2.5 GHz a 5GHz y limpiar los canales. Sin suerte, el problema persistió.

Hasta que me di cuenta de que cuando hago una prueba de velocidad de red o ejecutar un cliente bittorrent el ping está bien. Sólo fluctúa cuando la red está inactiva.

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

Hasta ahora he hecho un pequeño programa de Rust para mantener 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));}}