For international communications with large delays and fluctuations, I would like to find out whether the outbound or inbound journey affects the communications. I want to measure the outbound and inbound routes separately, not the RTT delay measurement by Ping. Currently, the reason why one-way delay is difficult is that the time of the two nodes to be measured must be accurately synchronized. However, since the international line like this time has RTT 100ms, the nearest NTP synchronization is good. It is assumed that the error is several ms at most, the theoretical shortest one-way delay can be estimated, and the NTP synchronization deviation value can be estimated to some extent from it. Also, considering the processing overhead, it should not be processed by a script, but if it is a script, it will not cause an error of 1 ms with a recent server, so I chose easy Python. To put it simply, "Roughly, cut it out"
1 round trip upd packet between client and server
#!/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)
#!/usr/bin/env python import socket import time host = 'localhost' #Specify your own IP for the time being 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()
Actually, Pakeros is also terrible, so retry processing and timeout processing are required, and I implemented it with output that is a little easier to handle, but I omitted it now.
Conducted within the same host (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
It is at least an order of magnitude less accurate than ping. .. .. The overhead of the outbound route is mainly heavy. Well, the difference in accuracy between 10 μs and 100 μs is almost as expected. You can ignore it on international lines. (Giving up is important)
Blue line: round trip, orange: outbound, green: inbound. You can run it in batch for about half a day and read it as a graph
By the way, when I tried it on different instances in the same data center, the future time came back about 1 microsecond.
2017/2/26: I wrote the equivalent code in C, but it decreased by about 150μs. It didn't improve as much as I expected. For the time being, python is fine.