Améliorer la vitesse du wifi local

Ce comportement peut être causé par des fonctions de gestion de l'alimentation et n'indique pas un problème. Essayez d'installer Émulateur de terminal Android sur le téléphone et envoyer une commande ping au routeur ou à un PC normal (pas un autre téléphone) en exécutant ping -c 10 <address> à partir de là. Vous devriez remarquer que les résultats du ping dans cette direction sont meilleurs.

(Notez que sans le -c <n> vous devrez découvrir comment envoyer Ctrl+C au terminal pour arrêter ping il est possible d'utiliser un bouton de volume comme Ctrl si votre clavier ne fournit pas une telle touche).

La différence entre l'envoi d'une requête ping à un téléphone à partir d'un autre appareil et l'envoi d'une requête ping à partir du téléphone lui-même est que lorsque le téléphone lui-même envoie des requêtes ping, il est actif et peut recevoir la réponse ping sans délai important. Cependant, lorsque vous tentez d'envoyer une requête ping au téléphone depuis un autre appareil, le téléphone est très probablement dans un état de faible puissance, et le réveiller peut prendre un certain temps. Le Wi-Fi dispose également de certaines fonctions d'économie d'énergie (par exemple, le point d'accès peut mettre en mémoire tampon les paquets destinés à un appareil mobile et les transmettre uniquement selon un calendrier précis, de sorte que l'appareil mobile puisse rester dans un état de faible consommation entre ces interrogations programmées).

En raison de toutes ces fonctions d'économie d'énergie, vous ne pouvez pas tirer de conclusion sur la qualité de la liaison Wi-Fi à partir des résultats du ping, à moins de désactiver toute économie d'énergie pendant le test (voir ci-dessous pour un exemple de mes tests), ou au moins effectuer des tests du côté du téléphone.

Voici ce que je vois lorsque j'interroge mon Samsung Galaxy W (GT-I8150) en utilisant la ROM non officielle CyanogenMod 9, lorsque le téléphone est au repos avec l'écran éteint :

PING 192.168.43.114 (192.168.43.114) 56(84) bytes of data.
64 bytes from 192.168.43.114: icmp_req=1 ttl=64 time=690 ms
64 bytes from 192.168.43.114: icmp_req=2 ttl=64 time=418 ms
64 bytes from 192.168.43.114: icmp_req=3 ttl=64 time=329 ms
64 bytes from 192.168.43.114: icmp_req=4 ttl=64 time=54.7 ms
64 bytes from 192.168.43.114: icmp_req=5 ttl=64 time=579 ms
64 bytes from 192.168.43.114: icmp_req=6 ttl=64 time=306 ms
64 bytes from 192.168.43.114: icmp_req=7 ttl=64 time=217 ms
64 bytes from 192.168.43.114: icmp_req=8 ttl=64 time=557 ms
64 bytes from 192.168.43.114: icmp_req=9 ttl=64 time=467 ms
64 bytes from 192.168.43.114: icmp_req=10 ttl=64 time=195 ms

--- 192.168.43.114 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9006ms
rtt min/avg/max/mdev = 54.730/381.686/690.746/187.341 ms

Comme vous pouvez le voir, les résultats sont plutôt mauvais. Cependant, lorsque je commence Émulateur de terminal Android et sélectionner la commande "Take WifiLock" dans celui-ci, puis éteindre à nouveau l'écran, j'obtiens des résultats nettement meilleurs :

PING 192.168.43.114 (192.168.43.114) 56(84) bytes of data.
64 bytes from 192.168.43.114: icmp_req=1 ttl=64 time=95.5 ms
64 bytes from 192.168.43.114: icmp_req=2 ttl=64 time=2.66 ms
64 bytes from 192.168.43.114: icmp_req=3 ttl=64 time=94.3 ms
64 bytes from 192.168.43.114: icmp_req=4 ttl=64 time=2.62 ms
64 bytes from 192.168.43.114: icmp_req=5 ttl=64 time=88.9 ms
64 bytes from 192.168.43.114: icmp_req=6 ttl=64 time=3.14 ms
64 bytes from 192.168.43.114: icmp_req=7 ttl=64 time=91.9 ms
64 bytes from 192.168.43.114: icmp_req=8 ttl=64 time=5.57 ms
64 bytes from 192.168.43.114: icmp_req=9 ttl=64 time=93.9 ms
64 bytes from 192.168.43.114: icmp_req=10 ttl=64 time=2.62 ms

--- 192.168.43.114 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 2.622/48.136/95.551/44.845 ms

Et si je répète le même test avec l'écran allumé, le résultat du ping est encore meilleur :

PING 192.168.43.114 (192.168.43.114) 56(84) bytes of data.
64 bytes from 192.168.43.114: icmp_req=1 ttl=64 time=2.29 ms
64 bytes from 192.168.43.114: icmp_req=2 ttl=64 time=2.21 ms
64 bytes from 192.168.43.114: icmp_req=3 ttl=64 time=8.87 ms
64 bytes from 192.168.43.114: icmp_req=4 ttl=64 time=3.27 ms
64 bytes from 192.168.43.114: icmp_req=5 ttl=64 time=4.01 ms
64 bytes from 192.168.43.114: icmp_req=6 ttl=64 time=2.26 ms
64 bytes from 192.168.43.114: icmp_req=7 ttl=64 time=2.22 ms
64 bytes from 192.168.43.114: icmp_req=8 ttl=64 time=2.13 ms
64 bytes from 192.168.43.114: icmp_req=9 ttl=64 time=2.73 ms
64 bytes from 192.168.43.114: icmp_req=10 ttl=64 time=2.23 ms

--- 192.168.43.114 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 2.132/3.226/8.878/1.970 ms

(Pour une raison quelconque, le fait de relâcher le WifiLock et même de fermer l'émulateur de terminal ne rétablit pas le comportement original, jusqu'à ce que je désactive le Wi-Fi, puis le réactive - il y a probablement un bug quelque part).

Running ping à partir du téléphone lui-même donne environ 12 ms de RTT moyen sans prendre le WifiLock, et 1.95 ms après avoir pris le WifiLock - donc même en testant du côté du téléphone l'effet du WifiLock est significatif.