2

(Applogies for my bad english in advance. I'm not a native speaker)

I'm currently working on my Bachelors Thesis. The aim of my project is to accuratly and precisely timestamp Packages(it has to be at least precise in the tenth of microsecond range).

I am trying to accomplish hardware timestamping with tcpdump, but there are some problems I have encountered.

My Setup:

2 directly connected identical Servers.

Linux: Debian 3.16.7
Network Interface: Intel i350-T4

Used tcpdump command:

sudo /usr/sbin/tcpdump -i eth4 -s 59 port 33333 -x -n -tt -v -j adapter_unsynced --time-stamp-precision=nano -w name.pcap

Now, my results in itself make sense and would give me the desired results, but they have a big offset to them. 36 seconds to be exact.

The jitter of my results with the -j adapter_unsynced option are about 10 µs, If I use the -j adapter option I get a Jitter of ~100µs(too imprecise for my application), but not the 36 second offset.

All clocks are syncronised as far as I can see. The system clocks were both syncronised, and the PHC Clock of the NIC was too.

As a test run I changed the system clock of one of the servers and the change showed up on the results while using -j adapter_unsynced.

So my question is: What am I doing wrong, and is what I want to do even possible with tcpdump?

I'm thankfull for any advice.

Greetings, Christian

sel-fish
  • 4,308
  • 2
  • 20
  • 39
Saddun
  • 21
  • 1
  • 3
  • 2
    It is suspicious that the difference is 36 seconds. Are you sure its not 3600 seconds, and you're dividing by 100 somewhere? I ask, because 3600 seconds would be exactly 1 hour, which could be explained by DST or timezone conversion issues – Smeeheey Jun 08 '16 at 14:06
  • The Servers are both in the Same Timezone and all the clocks run accordingly(System clock an NIC PHC Clock are all synchronised). And yes, 36 seconds, the timestamp is directly taken from tcpdump, so no real chance for any divisions – Saddun Jun 09 '16 at 09:27

1 Answers1

3

36 seconds sounds like the difference between UTC and TAI (which has been 36 seconds since June 2015, and should become 37 with the leap second scheduled for Dec 2016).

So I'd look at how you are synchronising the two PHCs, and whether the software used to do this on both sides agree on the timebase: UTC or TAI, as the two differ on their use of leap-seconds and currently differ by exactly 36 seconds.

David Mirabito
  • 455
  • 5
  • 13