[ntp:questions] SO_TIMESTAMPING experiments (sub-us jitter over LAN)

gabs gsricalde at gmail.com
Thu Oct 18 09:53:02 UTC 2012


SO_TIMESTAMPING [1] is a socket option for obtaining transmit and receive
timestamps. ntpd uses SO_TIMESTAMP to get receive timestamps. Transmit
timestamps require NIC driver support [2] and the application gets the
timestamp after the packet is sent.

A PTP-like protocol is used to measure the delay and offset between the
client and server. The first part is a message exchange similar to
NTP [3], except the client gets a more accurate transmit timestamp
(T1) from the kernel after sending the packet. The server, after sending
its reply, gets the kernel transmit timestamp (T4), then sends another
packet containing T4 (similar to the PTP Sync Follow message). The
median of 6 offsets are sent to the client's ntpd thru the SHM driver.


Test setup:

Server:
Pentium M 1.6 GHz
ntpd synced to GPS PPS on parallel port
Intel PRO/100 Ethernet (e100)

Client:
Intel Atom N450 1.66 GHz
ntpd synced to SHM driver
Atheros AR8132 Fast Ethernet (atl1c)

Both are running Linux kernel 3.3.4, tickless, no preemption,
Ethernet drivers patched with skb_tx_timestamp [2], software timestamps.
The SHM driver at the client is modified to accept nanosecond timestamps.
While ntpd runs on both devices, NTP is not used.


Sample measurements (raw):
left: delay
right: offset (in microseconds)

91509  509
89577 -991
88365 -795
89574 -731
90593 -163
89360 -1067

92650 -318
90634 -910
89455 -989
89511 -1080
88874 -693
88534 -1140

When the clock is drifting slowly, the kernel PLL offsets are less than 0.5 us.
Way better than I expected, but there is an unknown offset due to delay
asymmetry.

----------
[1] http://lwn.net/Articles/325929/
[2] http://stackoverflow.com/questions/11731445/timestamp-outgoing-packets
[3] http://www.eecis.udel.edu/~mills/time.html



More information about the questions mailing list