How to present ping data from ICMP timestamp The ICMP timestamp protocol is useful for determining which path — forward or reverse — is contributing to the jitter on the line.

In an ideal world, all computers would have an excellent ntpd, and time accuracy of about 1ms (the granularity of ICMP timestamp) should not be a problem:

0       145.5   146 = 75 + 71
1       142.7   142 = 72 + 70
2       140.7   140 = 70 + 70
3       146.7   146 = 76 + 70
4       148.3   148 = 77 + 71
5       157.5   157 = 87 + 70
6       167.1   167 = 96 + 71
7       166.3   166 = 95 + 71
8       167.7   167 = 97 + 70
9       159.0   159 = 88 + 71


However, in reality, as per https://stackoverflow.com/questions/20172028/awk-hping-print-difference-between-icmp-originate-receive/20186781#20186781, the data could be like this:

0       165.9   166 = -142113 + 142279
1       160.2   160 = -142118 + 142278
2       155.2   155 = -142122 + 142277
3       156.5   156 = -142121 + 142277
4       164.7   165 = -142112 + 142277
5       164.4   164 = -142111 + 142275
6       160.9   161 = -142114 + 142275
7       158.1   158 = -142117 + 142275
8       155.6   156 = -142119 + 142275
9       143.0   143 = -142131 + 142274
10      153.2   153 = -142120 + 142273
11      157.1   157 = -142115 + 142272
12      158.3   158 = -142114 + 142272
13      148.6   149 = -142123 + 142272
14      144.3   144 = -142127 + 142271
15      145.3   145 = -142125 + 142270


Which still shows that only one path is responsible for the jitter, since only one value jumps up and down randomly, whereas the other one is decreasing monotonically (probably due to an actively-running ntpd, which is correcting the time as we ping).

Another example could be less wrong-looking of the time not being synchronised, say:

0       165.9   166 = -113 + 279


Or, better yet:

0       165.9   166 = 7 + 159


Or, say, still wrong by some 10ms to 40ms, on a landline link from Alberta to Vogtland, but much less obvious:

0       165.9   166 = 59 + 107


How to make scientific sense of this data, for it to be easily presentable, and not blatantly wrong?

Feel free to assume to have between 10 to 1000 measurement points, measured over a couple of seconds or minutes.
You ask:


  How to make scientific sense of this data, for it to be easily presentable, and not blatantly wrong?


Well, the bottom line is: this data is blatantly wrong.  If your measurement method says that the latency on some link is negative 113 ms, there is something wrong with your measurement method.

Right now, you've got a "garbage in, garbage out" situation.  The data you've got does not survive simple cross-checks, which tells you that your measurement methods has problems.  What you need to do at this point is go back to the drawing board and devise a better measurement method.  For instance, maybe you can find some way to measure the offset between your clock and the remote machine's clock more precisely, and then adjust for that offset.

But in any case, it's pretty clear that the current measurement method isn't adequate on its own.