mesurer la latence unidirectionnelle / la gigue / la perte de paquets


10

Je reçois une latence accrue et StDev en raison de la congestion des routes et de la perte de paquets , mais les chemins aller et retour passent par des réseaux distincts (par exemple, l'un étant init7.net, l'autre étant he.net), il est donc très difficile de comprendre quel réseau ou hôte est responsable de l'encombrement, de la perte de paquets, de la gigue et de la latence accrue.

Existe-t-il un moyen de réduire le blâme après l' mtréchec de la marche avant et arrière pour identifier le coupable exact, et les contacts NOC @ ne répondent pas ou affirment ne subir aucune perte sur le chemin en question? (J'utilise OpenBSD.)

J'ai même essayé de faire un contact mtrdirect avec certains clients des deux réseaux qui pourraient rencontrer la congestion, mais je n'ai pas vraiment trouvé de problème de cette façon, d'autant plus que, par exemple, he.net a de nombreux POP, et souvent des routes distinctes sont prises entre une entrée et une sortie POP données, donc lorsque j'essaie de rejoindre mtrleurs hôtes (comme le tserv) directement à la sortie POP vers laquelle je risque de perdre des paquets dans leur réseau, un chemin he.net différent est pris pour atteindre le même POP, et aucune perte de paquets ne se produit, ce qui ne prouve rien d'intérêt (à part une éventuelle suggestion qu'ils pourraient en effet surcharger certaines routes, tout en garantissant que d'autres restent non encombrées, tout en ignorant les demandes NOC @ de non-clients).


Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.
Ron Maupin

Réponses:


9

Une façon de le faire est l'horodatage ICMP, qui est en millisecondes à partir de minuit UTC. Il a l'avantage supplémentaire que vous n'avez pas nécessairement besoin de contrôler les deux extrémités, tant que l'extrémité distante n'est pas protégée par un pare-feu, il y a de fortes chances que cela fonctionne.

Cependant, pour avoir des mesures unidirectionnelles fiables, vous avez besoin du même temps de manière fiable aux deux extrémités. Comme l'horodatage ICMP n'a qu'une précision de 1 ms (ce qui n'est pas suffisant pour de nombreuses applications, mais suffisant pour cela), il est raisonnablement facile de trouver même des hôtes non coopérants où l'horodatage ICMP fournira des données utiles.

Si vous contrôlez les deux extrémités, assurez-vous que vous synchronisez NTP avec seulement 1 serveur et le même serveur. L'horloge absolue n'est pas très importante, il est juste important que vous viviez le plus près possible du même temps.

Si l'horodatage ICMP n'est pas suffisant, il est très facile d'écrire 10 lignes de ruby ​​/ perl / python ou même C pour faire des mesures lorsque vous contrôlez les deux extrémités.

Je ne peux pas vraiment suggérer un logiciel pour effectuer des mesures d'horodatage ICMP unidirectionnellement, hping2 prend en charge l'envoi d'horodatage ICMP mais pour une raison quelconque, il ne génère pas de valeurs unidirectionnelles. J'ai écrit un patch pour hping2 pour afficher les latences unidirectionnelles.


Wow, votre hping --icmp-tsarithmétique supplémentaire est tellement géniale! Trop paresseux pour obtenir les sources et recompiler le binaire, je me suis procuré une version shell de votre patch hping ( stackoverflow.com/q/20172028/1122270 ), et cela montre un temps à peu près constant sur le chemin init7 vers hetzner, et un variance sur toute la carte avec le chemin he.net de hetzner! J'ai enfin la preuve définitive qu'init7 dit la vérité! Bien que je m'oppose à l'utilisation du même serveur ntp juste pour cela: assurez-vous simplement qu'un ntpd est vivant (je n'ai pas eu à changer de paramètres du tout, mais les valeurs semblent raisonnables).
2013

1
Si vous vous souciez de l'heure exacte du mur, vous aurez besoin d'au moins 3 serveurs NTP (pour pouvoir détecter un faux ticker, 2 serveurs NTP est la pire option que vous puissiez faire). Mais ici, nous ne nous soucions pas de l'heure du mur, nous nous soucions de cocher avec précision à la même horloge, quel que soit le mur. Ainsi, pour une mesure unidirectionnelle, les résultats optimaux proviennent d'une horloge précise, l'heure du mur étant sans importance. Heureux d'apprendre que vous avez obtenu des résultats!
ytti
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.