Comment diable ce temps de ping d'une heure peut-il être réel?

J'ai récemment passé le jour férié de Pâques avec mes parents, qui vivent dans une zone très rurale du Royaume-Uni. Ils ont une connexion Internet ADSL (terrible), qui fonctionne sur plusieurs kilomètres de cuivre douteux et est périodiquement interrompue lorsque les agriculteurs voisins inversent leurs tracteurs dans les lignes téléphoniques.

J'ai remarqué que leur routeur abandonnait à plusieurs reprises la pptppoignée de main et la renégociait, tuant la connexion efficacement. C'était frustrant. Donc, pour éviter de devenir fou, je lui ai dit de doubler la marge SNR minimale acceptable et de prendre la main pour des vitesses inférieures:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

Cela a amélioré les choses, et la chose a obtenu un tuyau (quelque peu) stable, si incroyablement lent, vers le monde extérieur:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

À peu près à ce stade, la vraie vie est intervenue et j'ai ensuite passé plusieurs heures à jouer avec des chats, à regarder des gifs de chats sur mon téléphone, à parler à ma famille , etc. J'ai oublié que j'avais laissé ce processus de ping en cours et je suis revenu un jour plus tard pour frapper ctrl-c.

Les statistiques sommaires présentées m'ont terrassé:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

Comme vous pouvez le voir, le temps de réponse maximum enregistré pour un paquet ICMP effectuant un court saut transatlantique vers le serveur DNS de Google est de 3600577,732 ms . C'est presque exactement une heure , et certainement beaucoup plus longtemps que pingle délai d'expiration par défaut.

Comment diable cela peut-il être? Est- ce exact? Quel routeur tiendra volontiers un paquet pendant soixante minutes avant de l'envoyer en route? Pourquoi ce paquet n'a-t-il pas été abandonné? Est-ce le résultat d'un débordement du compteur de paquets 8 bits combiné à de grandes latences?

Enfin, je serais intéressé de savoir s'il existe un code de conduite au Royaume-Uni indiquant que les connexions ADSL grand public devraient avoir moins de latence et une meilleure gestion du trafic que celles des RFC 1149 et RFC 2549 ;-).

networking routing adsl

— Landak
source

un routeur qui n'est pas surchargé de spam.

— monstre à cliquet

Un routeur gourmand;) Je dois juste jouer cela lorsque vous remarquez qu'il est prévu d'attendre une heure avant de transmettre le paquet. youtube.com/watch?v=moSFlvxnbgk

— Cestarian

Est-il possible que, puisque vous avez dit que vous l'avez laissé pendant la nuit, votre ordinateur a appliqué la +1 heure au début de l'heure d'été et cela a gêné le calcul du RTT d'un paquet particulier?

— kenkh

@kenkh - Non; Je suis sûr que le jour où les horloges ont changé n'était pas celui-là. En outre, en regardant le ping code source (à partir de ~ l 761), je peux voir que les fuseaux horaires sont ignorés dans le calcul suivant ( gettimeofday(nv, NULL)renvoie l'époque en microsecondes). Cela a vraiment pris une heure!

— Landak

si vous avez accès au système, pourriez-vous exécuter le pathping sur celui-ci? Indiquerait à peu près où se situe le ralentissement

— Journeyman Geek

Réponses:

Le paquet ICMP et la réponse pour le ping sont chacun de 32 octets, il semble donc que pour un ping d'une heure, chaque octet prenait presque une minute à transmettre.

Cela ne s'explique que par un nombre de tentatives d'erreur très généreux (ce que vous faites?), Couplé à un routeur très lent et à une attente ou à de nouvelles tentatives douloureuses pour chaque octet transmis.

Le protocole Internet (IP) transmet les données par datagrammes et essaie de ne pas en envoyer de partiels. Une fois la transmission démarrée, elle attendra par défaut 200 millisecondes pour que plus d'octets soient ajoutés au datagramme. Passé ce délai, le logiciel / micrologiciel enverra tout ce qu'il contient en un seul datagramme. Dans le cas du temps de ping d'une heure, la charge utile du paquet peut avoir été aussi petite qu'un octet. Tant que les données arrivent toujours, la connexion ne sera pas interrompue par les deux parties participantes.

Ce que tu peux faire :

Si d'autres téléphones, télécopieurs ou autres appareils sont connectés à la même ligne téléphonique, vérifiez s'ils sont protégés par des filtres DSL . Assurez-vous de ne pas mettre de filtre sur la ligne allant à votre modem DSL.
Essayez un autre routeur - une fois que vous avez un mauvais appareil, vous ne pouvez absolument rien y faire, sauf le jeter et obtenir quelque chose de mieux.
Si aucun autre routeur n'est disponible, contactez votre FAI - ils peuvent exécuter des tests utiles de leur côté.
Si le FAI ne trouve rien, essayez quand même de demander un routeur / modem de remplacement.
Si le même problème se produit avec un autre routeur, contactez la compagnie de téléphone.

Il peut être assez compliqué de localiser un commutateur problématique, comme cela peut être le cas avec la compagnie de téléphone, mais le FAI peut également avoir ses propres commutateurs. Normalement, un problème avec un commutateur est à l'échelle de la zone, ce qui permet de localiser le commutateur défectueux. Mais dans une zone rurale où pas trop d'abonnés utilisent ce commutateur, cela pourrait ne pas être détecté. Si certains voisins utilisent le même FAI, essayez de savoir à quoi ressemble leur connexion.

— harrymc
source

Je tournerais 2 et 3 autour. Il est beaucoup plus facile d'appeler le FAI en premier. Ils peuvent faire un test. S'ils voient des problèmes, ils enverront un nouveau modem (pas nécessairement un routeur). Si un nouveau modem ne résout pas le problème, le FAI doit contacter la compagnie de téléphone. C'est ainsi que cela fonctionne ici, mais cela peut être différent au Royaume-Uni.

— SPRBRN

Je voulais dire que l'on devrait exécuter autant de points ci-dessus en parallèle que possible. Dans mon cas, mon FAI pourrait décider d'envoyer un technicien, mais si le problème est aussi trivial que les filtres DSL inutilisés, il peut décider de facturer des frais.

— harrymc

Pouah. Les commentaires se réfèrent à des nombres dans une liste numérotée. Ensuite, l'affiche de la réponse a édité la réponse pour supprimer les chiffres, faisant ainsi paraître les commentaires hors de propos. TTT ... TTT.

— TOOGAM

200 ms : Ceci est intégré au logiciel Windows / Linux. Je l'ai trouvé lors de l'analyse des raisons pour lesquelles le produit de mon entreprise avait un débit TCP / IP trop faible sur les petits datagrammes, puis j'ai trouvé les appels système qui sont "envoyés immédiatement" sur le socket. Charge utile des paquets : cela n'est pas négocié, un datagramme TCP / IP trop volumineux sera coupé en plusieurs parties lorsqu'il rencontrera un chemin où le MTU est trop petit. Modem DSL : il est possible que la modification des paramètres compense quelque peu les mauvaises lignes téléphoniques / commutateurs, mais il devrait être corrigé plutôt que compensé.

— harrymc

Un autre ajustement: désactivez l'ADSL2 + et restez avec l'ADSL1 pour la stabilité. Quel que soit le routeur que vous achetez, assurez-vous que vous pouvez modifier correctement les marges SNR (quelques informations ici ). Des milliards de routeurs sont bons, tout comme Netgear (je préfère les modèles qui prennent en charge DD-WRT avec une installation simple). Cet article peut vous donner plus d'idées et jeter un œil au diagramme distance / vitesse.

— harrymc

Je vois ce cas très lié à la gestion de la congestion des données, bien qu'un très mauvais géré, quelle qu'en soit la raison. À ma connaissance, il y a un tampon de paquets le long du système de transmission - mal géré, ce qui provoque cette anomalie dans les paquets de demande / réponse d'écho ICMP.

Ainsi, la combinaison d'avoir une mauvaise politique de gestion de la congestion et d'avoir une session ping ouverte pendant des heures peut résulter dans un scénario aussi étrange.

Plus d'informations sur la gestion de la congestion ici .

— Tamadite
source