0

With tcpdump, I dumped a trace of around 2800 outgoing packets and just as many corresponding incoming ICMP packets. Then, I computed the RTT for each outgoing packet with a simple subtraction.

It turns out that, even though there are no duplicates among my timestamps (outgoing, incoming, or even when merged together!), there are always a few hundred duplicates in my RTTs. I found this very odd.

Does it have to do with floating point precision? I tried with python's built-in float and with numpy, but I got the same result just described (I checked for duplicates with set in Python).

EDIT: Here is an example of an RTT appearing 4 times with different timestamps

# a contains timestamps for outgoing packets
# b contains timestamps for incoming answers
# c contains corresponding RTTs (c[i]=b[i]-a[i])
OneRtt = 0.002665996551513672
>>> indices = [i for i, x in enumerate(c) if x == 0.002665996551513672]
>>> indices
[737, 1711, 2499, 2713]
>>> b[737]
1369237439.238884
>>> a[737]
1369237439.236218
>>> c[737]
0.002665996551513672
>>> b[1711]
1369237485.874826
>>> a[1711]
1369237485.87216
>>> c[1711]
0.002665996551513672
>>> b[2499]
1369237524.170485
>>> a[2499]
1369237524.167819
>>> c[2499]
0.002665996551513672
>>> b[2713]
1369237535.293074
>>> a[2713]
1369237535.290408
>>> c[2713]
0.002665996551513672
Ricky Robinson
  • 21,798
  • 42
  • 129
  • 185
  • Well, are you sure that you really don't have duplicates? Find out which differences are identical. – Blender May 22 '13 at 16:40
  • It's possible that `a`,`b`,`c`,`d` are all unique values and yet `d-c == b-a`. – interjay May 22 '13 at 16:42
  • Sure. I added an example of an RTT value appearing 4 times in the same trace. I just find it very odd that at the precision of 6 decimal digits and with uplicates...no more than a few thousand (packet, answer) pairs, I am getting RTT duplicates. It looks like it's exactly this case, though. DO you guys agree? – Ricky Robinson May 22 '13 at 17:39
  • Yeah, well... all subtractions result in 0.002666. At the precision of 6 decimal digits it really looks like this happens really often. – Ricky Robinson May 22 '13 at 18:00
  • I suspect that the clock you're using for timing only has a precision of 0.002666. – Mark Ransom May 22 '13 at 18:16
  • No no, I also have lower values. I took this RTT because it's the one it appears more often in my trace. There are many that appear only twice, no matter if they are smaller or greater than this one. – Ricky Robinson May 22 '13 at 18:42
  • It might be that RTT distribution has a peak. The float precision is rather increasing the number of different values you get, for example 1369237439.238886-1369237439.236220 != 1369237439.238884-1369237439.236218 . Note that one ULP is about 2e-7 on these times – aka.nice May 22 '13 at 23:49
  • Oh then that I didn't know. In my case I have around 3000 values which are all more or less around 1 or 2 milliseconds and the precision of my measurements is 10^-6. So that's why also, if I take a much larger trace than the one in this example I get even more duplicates. – Ricky Robinson May 23 '13 at 11:42
  • Your clock may return values in microseconds (10^-6) but it may also only have a *resolution* of 2.666 milliseconds - in other words it jumps a "quantum" value of 2.666ms every time it 'ticks'. Yes it would be very silly for your clock to be "deceptive" like this but, in reality many system clocks are. The quantum might also be 1.333 milliseconds, or 0.666 milliseconds, and then if your RTTs routinely fall within 3ms they will be truncated to the largest quantum value less than the actual RTT. – duanev Apr 04 '16 at 21:14

0 Answers0