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

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