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?

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.

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.

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

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

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.)

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 .

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.

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