Question Comment diagnostiquer et visualiser les temps de ping élevés sur le routeur wifi?


Je vois des temps de ping irréguliers et parfois très longs sur mon routeur wifi qui ne fait que passer. Cingler 192.168.1.1 donne parfois des allongements de 400-800ms de latences.

Il y a plein de choses à essayer (micrologiciel, placement de routeur, canal AP, etc.), mais j'aimerais aborder ce problème un peu plus méthodiquement:

  • D'abord, comment puis-je visualiser la performance de mon réseau?
  • Alors, comment puis-je référence la performance d'une configuration donnée, afin que je puisse comparer de manière fiable après avoir effectué des ajustements?

65
2018-01-03 19:16


origine


Quel routeur et / ou logiciel de routeur intégré utilisez-vous s'il ne s'agit pas de l'installation du stock? - Jeff Clayton
@JeffClayton Linksys WRT54GSv2 (old-school) en cours d'exécution Tomato (Shibby). Utilisé pour exécuter DD-WRT mais il a été buggé et difficile à maintenir. - Paul Irish
Avez-vous un problème réel ou est-ce purement un problème cosmétique? Les routeurs WiFi ne sont généralement pas conçus pour être des répondeurs de ping ultra-rapides, ils ont un réel travail à faire. - David Schwartz
@DavidSchwartz nous devrions être en mesure d'effectuer un tour complet vers un AP wifi en moins de 10ms, non? Si votre temps de latence intra-wifi est supérieur à 500ms, EVERY PACKET vous tirera également de cette latence. C'est un tueur. - Paul Irish
@PaulIrish Tout est vrai, mais cela n'a rien à voir avec les temps de ping. Ping mesure la somme de la latence du réseau et de la latence de la réponse ping elle-même. Les routeurs SoHo WiFi ne sont pas conçus pour être des répondeurs de ping efficaces. L'utilisation de ping pour mesurer la latence du réseau n'est donc pas recommandée. - David Schwartz


Réponses:


Cette réponse par défaut de serveur a de bonnes directives de haut niveau sur la marche à suivre - commencez par là. Cette dernière étape est une véritable bêtise cependant: sans doute vous (je veux dire, moi) ne veulent 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 sur un point d'extrémité 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, Channel, Signal Strength. Il peut également effectuer une étude de site de base pour un espace physique indiquant les forces et les interférences. En mode découverte AP, vous pouvez également tracer la force du signal au fil du temps, ce qui vous permet de tester les emplacements et d'ajuster les possibilités d'interférence. enter image description here enter image description here enter image description here

Test de vitesse Wifi pour Android

Très utile. Vous exécuterez un serveur python simple sur votre machine et l'application pourra tester quelques scénarios en vous fournissant des informations en temps réel sur la vitesse.

enter image description here

Analyseur Wifi, une autre grande application Android, a quelques points de vue précieux sur les canaux wifi AP sont actifs. Peut-être le meilleur outil gratuit pour choisir le canal AP sans faire beaucoup de travail.

iPerf

Outil bien respecté pour comprendre la performance du réseau local. Vous avez besoin de deux boîtes, une en tant que serveur, une en tant que client. Vous pouvez configurer un certain nombre de paramètres, exécuter un test et voir les résultats concernant la bande passante et la gigue. Je préfère l'utiliser avec le jPerf GUI pour tracer les résultats et modifier les 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

enter image description here

Connectivité Internet Santé

mtr (ping & traceroute combiné)

Pings tous vos sauts de traceroute. Fournit des données de tendance. Crazy 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 qu’il n’est pas cohérent, mais néanmoins, il est utile d’essayer d’évaluer les 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 de chemin d'accès et d'application réseau

Serveur de diagnostic automatique pour dépanner les systèmes d'extrémité et les problèmes de réseau du dernier kilomètre. Après avoir effectué une batterie de tests, donne une Page de résumé de résultat comme ceci. Je recommande d'utiliser ceci Lien de redirection du serveur NPAD pour trouver le serveur NPAD le plus proche (ils sont partout) et 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

enter image description here


Mes résultats personnels:

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

Pour cela, j'ai tiré le meilleur parti de Test de vitesse Wifi pour Android, courant régulièrement pendant que je bougeais les choses dans l'appartement. Comme il signale des mises à jour toutes les 200 ms ou plus, il est clairement indiqué que des interférences entraînent la perte de mes paquets.

Je recommande vraiment de lire le Sources d'Interférence Communes guide de Metageek. (Ils rendent également InSSIDer et d’autres outils d’analyse Wifi qui semblent bons.)

enter image description here

L'un des outils que je n'avais pas était un analyseur 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 détecter les interférences provenant de Bluetooth ou d'autres technologies RF. Metageek a de belles solutions dans cet espace (Wi-Spy et Bureau inSSIDer) et j'espère que nous voyons plus d'outils émergent comme AirShark.


78
2018-01-03 19:16



Ce sont de beaux outils, mettant à jour mes notes. - Jeff Clayton
Un autre outil "rapide et sale" qui est précieux car son portable est Wifi Analyzer pour les appareils Android. - davidgo
Toujours. J'ai brièvement mentionné l'analyseur WiFi ce pourrait être le meilleur outil pour comprendre l'interférence des canaux AP, bien que dans mon cas, cela ne posait pas de problème. Cela dit, c'est vraiment bien fait. - Paul Irish
Grande liste, merci Une autre chose à essayer est de voir ce qui se passe sans pour autant Wifi. Une fois que j'ai eu ce que je pensais être un problème de wifi, mais branché directement sur le câble alimentant le wifi AP et en cours d'exécution iPerf a révélé un mauvais câble comme le véritable coupable! - Ryan Dlugosz
Hmmmm. Il est très improbable que Bluetooth provoque le type d'interférence que vous décrivez, il est normal que le motif de saut AFS évite un signal Wi-Fi typique de 20 MHz à 2,4 GHz. Vous n'utilisiez pas des canaux de 40Mhz? - alfwatt


Comme indiqué dans mon commentaire ci-dessus: Les outils couramment utilisés pour diagnostiquer les problèmes de connexion Wi-Fi peuvent effectivement causer ce problème. Lors de la recherche de réseaux Wi-Fi, la radio doit s’éteindre du canal. En règle générale, elle indique au point d’accès de la protéger afin qu’il puisse «passer en mode veille», puis change de canal pour le scanner.

De plus, depuis le lancement d'AirDrop, iOS et OS X utilisent le canal radio Wi-Fi pour rechercher d'autres services AirDrop et depuis que Yosemite quittera périodiquement le canal pour prendre en charge le transfert intercellulaire.


4
2018-01-05 16:21



Très utile de savoir Merci! - Paul Irish
Un grand point - j'ai remarqué ce problème avec InSSIDer dans le passé - c'est bien d'avoir une explication. - Nick


J'ai donc eu ces fluctuations de ping Wi-Fi au 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 commuté le routeur (de TL-WR743ND à DIR-815), essayé plusieurs adaptateurs USB Wi-Fi (principalement des TP-LINK, même si je pense que j’ai eu le problème avec D-Link DWA-160), est passé de 2,5 GHz à 5 GHz et récurer les chaînes. Pas de chance, le problème a persisté.

Jusqu'à ce que je remarque que lorsque je teste la 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 Wi-Fi, la fluctuation disparaît et le réseau fonctionne correctement.

Jusqu'à présent, j'ai réalisé un petit programme Rust pour garder mon réseau Wi-Fi en place.

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

3
2017-12-02 21:37