Je vois des temps de ping irréguliers et parfois très longs avec mon routeur wifi qui se trouve à un bond de distance. Pinging 192.168.1.1
donne parfois des étendues de latences 400-800ms.
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:
Cette réponse par défaut de serveur contient de bons conseils 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.
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 au fil du temps, ce qui vous permet de tester les emplacements et d'ajuster les possibilités d'interférences.
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 grande application Android, offre quelques vues précieuses sur les canaux actifs des points d'accès wifi. Peut-être le meilleur outil gratuit pour choisir un canal AP sans faire beaucoup de travail.
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 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
Ping tous vos traceroute Houblon. Fournit des données de tendance. Fou génial.
brew install mtr
mtr 8.8.4.4
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
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 récapitulative Result comme ceci . Je vous 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
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 RF interférence, principalement due à 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 ce faire, j’ai tiré le meilleur parti de Test de vitesse WiFi pour Android, en l’utilisant régulièrement pendant que je déplaçais des choses 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 Sources courantes 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 peuvent uniquement détecter 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 quelques solutions intéressantes 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 de basculer 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), 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 de 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));}}