Mesure de retard unidirectionnelle du réseau par python

motivation

Pour les communications internationales avec des retards et des fluctuations importants, je voudrais vérifier si le voyage aller ou retour affecte les communications. Je souhaite mesurer séparément les itinéraires aller et retour au lieu de mesurer le délai RTT par ping. Actuellement, la raison pour laquelle le retard unidirectionnel est difficile est que le temps des deux nœuds à mesurer doit être synchronisé avec précision. Cependant, comme la ligne internationale comme cette fois a RTT 100ms, la synchronisation NTP la plus proche est bonne. On suppose que l'erreur est de plusieurs ms au plus, le retard unidirectionnel théorique le plus court peut être estimé et la valeur de l'écart de synchronisation NTP peut être estimée dans une certaine mesure à partir de celui-ci. De plus, compte tenu de la surcharge de traitement, il ne devrait pas être traité par un script, mais s'il s'agit d'un script, cela ne provoquera pas d'erreur de 1 ms avec un serveur récent, j'ai donc choisi Python facile. Pour le dire simplement, "grosso modo, découpez-le"

Méthode

1 paquet de mise à jour aller-retour entre le client et le serveur

1. Le client (a) enregistre l'heure de début et demande au serveur l'heure d'arrivée des paquets.
2. Le serveur (b) renvoie l'heure à laquelle il a reçu le paquet au client.
3. Le client (c) enregistre l'heure à laquelle il a reçu la réponse du serveur
4. (b) - (a) = Retard à l'arrivée / (c) - (b) = Retard à l'arrivée

Code (minimum)

Server

owpingserver.py

#!/usr/bin/env python

import socket
import time

host = '0.0.0.0'
port = 12345
bufsize = 512

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((host,port))
while True:
   data,addr = sock.recvfrom(bufsize)
   sock.sendto("%.6f" % time.time(), addr)

Client

owpingclient.py

#!/usr/bin/env python

import socket
import time

host = 'localhost' #Spécifiez votre propre IP pour le moment
port = 12345
bufsize = 512

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
stime = "%.6f" % time.time()
sock.sendto(stime, (socket.gethostbyname(host), port))
data, addr = sock.recvfrom(bufsize)
etime = "%.6f" % time.time()

print  "forward : " + str(float(data) - float(stime))
print  "backward: " + str(float(etime) - float(data))
print  "total:    " + str(float(etime) - float(stime))

time.sleep(1)
sock.close()

En fait, Pakeros est également terrible, donc le traitement des nouvelles tentatives et le traitement du délai d'expiration sont nécessaires, et je l'ai implémenté avec une sortie un peu plus facile à gérer, mais je l'ai omis maintenant.

Exécuter sur l'hôte local pour le moment

Conduit au sein du même hôte (localhost)

$ python owpingserver.py &
$ python owpingclient.py
forward : 0.000324964523315
backward: 4.81605529785e-05
total:    0.000373125076294

$ ping localhost -c 1
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.017 ms

--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.017/0.017/0.017/0.000 ms

C'est au moins un ordre de grandeur moins précis que le ping. .. .. Les frais généraux sortants sont principalement lourds. Eh bien, la différence de précision entre 10 μs et 100 μs est presque celle attendue. Vous pouvez l'ignorer sur les lignes internationales. (Abandonner est important)

Résultats de mesure sur les lignes internationales réelles

Ligne bleue: aller-retour, orange: aller, verte: aller. Vous pouvez l'exécuter par lots pendant environ une demi-journée et le lire sous forme de graphique

1. De toute évidence, l'effet du retard sortant sur le retard RTT est énorme
2. La route géographique est (devrait) être presque la même, et je pense que 15 ms dans un sens est un peu court, de sorte que le temps de nœud peut être décalé jusqu'à 3 ms.
3. Qu'est-ce que je fais depuis le petit matin des vacances?

À propos, lorsque je l'ai essayé sur différentes instances du même centre de données, l'heure future est revenue d'environ 1 microseconde.

Postscript

2017/2/26: J'ai écrit le code équivalent en C, mais il a diminué d'environ 150 μs. Cela ne s'est pas amélioré autant que je m'y attendais. Pour le moment, python va bien.