Comment diagnostiquer et visualiser les temps de réponse élevés au routeur wifi?


65

Je vois des temps de ping irréguliers et parfois très longs avec mon routeur wifi qui se trouve à un bond de distance. Les pings 192.168.1.1donnent parfois des latences de 400 à 800 ms.

Il y a beaucoup de choses à essayer (firmware, emplacement du routeur, canal AP, etc.), mais je voudrais attaquer ce problème un peu plus méthodiquement:

  • Premièrement, comment puis-je visualiser les performances de mon réseau?
  • Ensuite, comment puis-je comparer les performances d'une configuration donnée, afin de pouvoir comparer de manière fiable après des ajustements?

Quel routeur et / ou logiciel de routeur intégré utilisez-vous s'il ne s'agit pas d'une installation en stock?
Jeff Clayton

@JeffClayton Linksys WRT54GSv2 (vieille école) utilisant Tomato (Shibby). Utilisé pour exécuter DD-WRT mais sa maintenance a été problématique et complexe.
Paul irlandais le

1
Avez-vous un problème réel ou s'agit-il d'un problème purement esthétique? Les routeurs WiFi ne sont généralement pas conçus pour être des répondeurs ping ultra-rapides, ils ont un vrai travail à faire.
David Schwartz

1
@ DavidSchwartz, nous devrions pouvoir effectuer un aller-retour complet vers un point d'accès wifi en moins de 10 ms, non? Si votre latence intra-wifi est supérieure à 500 ms, CHAQUE PAQUET extrait du Web / Internet subit également cette latence. C'est un tueur.
Paul irlandais le

1
@PaulIrish Tout à fait, mais cela n'a rien à voir avec les temps de ping. Ping mesure la somme de la latence du réseau plus la latence de la réponse du ping elle-même. Les routeurs WiFi SoHo ne sont pas censés être des répondeurs ping efficaces. Il est donc déconseillé d'utiliser ping pour mesurer la latence du réseau.
David Schwartz

Réponses:


78

Cette réponse serverfault propose de bonnes instructions de haut niveau sur ce qu'il faut faire - commencez par là. Cette dernière étape est cependant un véritable doozy: vraisemblablement, vous (je veux dire, moi) ne voulez pas investir dans du matériel dédié pour cela ...

Vous trouverez ci-dessous de bons outils, d'abord pour comprendre la santé de la connectivité au sein du réseau wifi local, puis vers un point de terminaison Internet.

Outils Wifi

NetSpot (pour mac)

Il suit les points d'accès WiFI locaux et fournit des données de base telles que SNR, canal, puissance du signal. Il peut également effectuer une analyse de site de base pour un espace physique indiquant les forces et les interférences. En mode de découverte de point d'accès, vous pouvez également cartographier la puissance du signal dans le temps, ce qui vous permet de tester les emplacements et d'ajuster les possibilités d'interférences. entrez la description de l'image ici entrez la description de l'image ici entrez la description de l'image ici

Test de vitesse Wifi pour Android

Très utile. Vous allez exécuter un simple serveur python sur votre machine et l'application peut tester plusieurs scénarios en vous donnant un retour d'informations sur la vitesse en temps réel.

entrez la description de l'image ici

Wifi Analyzer , une autre application Android géniale, offre quelques vues précieuses sur les canaux actifs de l'AP wifi. Peut-être le meilleur outil gratuit pour choisir un canal AP sans faire beaucoup de travail.

iPerf

Outil respecté pour comprendre les performances du réseau local. Vous avez besoin de deux boîtes, une en tant que serveur et une en tant que client. Vous pouvez configurer un certain nombre de paramètres, exécuter un test et voir les résultats pour la bande passante et la gigue. Je préfère l'utiliser avec l' interface graphique de jPerf pour la représentation graphique des résultats et le réglage des paramètres.

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

entrez la description de l'image ici

Connectivité Internet Santé

mtr (ping & traceroute combinés)

Ping tous vos sauts traceroute. Fournit des données de tendance. Fou génial.

brew install mtr
mtr 8.8.4.4

speedtest-cli

La version CLI de la chose commune ookla speedtest.net. Le responsable du projet déclare que ce n'est pas cohérent, mais il est quand même pratique d'essayer de jauger de grandes différences.

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 : diagnostic du chemin d'accès et de l'application

Serveur de diagnostic automatique pour le dépannage des problèmes de réseau des derniers systèmes et du dernier kilomètre. Après avoir exécuté une batterie de tests, affiche une page de résumé des résultats comme celle-ci . Je recommande d'utiliser ce lien de redirection de serveur NPAD pour trouver le serveur NPAD le plus proche (ils sont partout) et d'utiliser ce nom d'hôte pour vos tests.

  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

entrez la description de l'image ici


Mes résultats personnels:

J'ai passé de bonnes heures à faire tout cela, à essayer différentes choses (passer du micrologiciel DD-WRT au micrologiciel Tomato) et à lire. Il s'avère que ce n'était pas une couche réseau et que c'était une bonne vieille interférence RF, principalement de Bluetooth! J'avais mon ordinateur, une souris Bluetooth et un clavier à moins de 5 pieds du routeur. (Et ancien routeur toujours sur 2.4Ghz où ils s'affrontent.)

Pour cela, j'ai tiré le meilleur parti du test de vitesse Wi - Fi pour Android , que j'ai régulièrement utilisé pendant que je déplaçais des objets dans l'appartement. Comme il rapporte des mises à jour toutes les 200 ms environ, il indique clairement quand les interférences laissaient tomber mes paquets.

Je recommande vivement de lire le guide sur les sources communes d’interférences de Metageek. (Ils rendent également InSSIDer et d'autres outils d'analyse Wifi qui semblent bons.)

entrez la description de l'image ici

Un outil que je n'avais pas était un compteur d'analyse de spectre physique. Les téléphones et les ordinateurs portables ne peuvent détecter que les points d'accès Wi-Fi, mais ne peuvent capter les interférences de Bluetooth ou d'autres technologies basées sur la RF. Metageek a de bonnes solutions dans cet espace ( Wi-Spy et inSSIDer Office ) et nous espérons voir plus d'outils émerger comme AirShark .


Ce sont de beaux outils, mettant à jour mes notes.
Jeff Clayton

Un autre outil "rapide et sale" qui est inestimable parce que son portable est Wifi Analyzer pour les appareils Android.
davidgo

Toujours. J'ai mentionné l'analyseur WiFi brièvement; ce pourrait être le meilleur outil pour comprendre les interférences de canaux AP, bien que dans mon cas, cela ne soit pas un problème. Cela dit, c'est vraiment bien fait.
Paul irlandais le

Grande liste, merci. Une autre chose à toujours essayer est de voir ce qui se passe sans wifi. Une fois, j'ai eu ce que je pensais être un problème de wifi, mais le fait de brancher directement le câble alimentant le point d'accès wifi et de faire fonctionner iPerf a révélé qu'un mauvais câble était le véritable coupable!
Ryan Dlugosz

1
Hmmmm. Il est très peu probable que Bluetooth provoque le type d'interférence que vous décrivez. Son schéma habituel de sauts AFS permet d'éviter un signal Wi-Fi 20 MHz typique à 2,4 GHz. Vous ne couriez pas les canaux 40Mhz étiez-vous?
alfwatt

4

Comme indiqué dans mon commentaire ci-dessus: Les outils couramment utilisés pour diagnostiquer les problèmes de Wi-Fi peuvent en réalité causer ce problème. Lors de la recherche de réseaux Wi-Fi, la radio doit désactiver le canal. Elle demande généralement à l'AP de mettre en mémoire tampon des trames pour pouvoir se mettre en veille, puis bascule les canaux à balayer.

En outre, iOS et OS X depuis l'introduction d'AirDrop, la radio Wi-Fi sera désactivée pour rechercher d'autres services AirDrop et, étant donné que Yosemite désactivera périodiquement le canal pour prendre en charge le transfert.


1
Excellent point - j'ai déjà remarqué ce problème avec InSSIDer par le passé - c'est bien d'avoir une explication.
Nick

3

J'ai donc eu ces fluctuations de ping Wi-Fi sur le routeur aussi.

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

J'ai changé de routeur (de TL-WR743ND à DIR-815), essayé plusieurs adaptateurs USB Wi-Fi (principalement des TP-LINK, bien que je pense avoir eu le problème avec le D-Link DWA-160 également), passé de 2,5 GHz à 5 GHz et parcouru les canaux. Pas de chance, le problème a persisté.

Jusqu'à ce que je remarque que lorsque je fais un test de vitesse du réseau ou que je lance un client BitTorrent, le ping est correct. Il ne fluctue que lorsque le réseau est inactif.

Peut-être un problème avec Windows 7 ou un problème avec mes adaptateurs TP-LINK, mais lorsque je charge un peu le réseau Wi-Fi, la fluctuation disparaît et le réseau fonctionne correctement.

Jusqu'ici, j'ai créé un petit programme Rust pour maintenir mon réseau Wi-Fi actif.

// 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));}} 
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.