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

Miroslav Lichvar mlichvar at redhat.com
Thu Oct 18 10:23:28 UTC 2012


On Thu, Oct 18, 2012 at 02:53:02AM -0700, gabs wrote:
> 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.

NTP supports interleaved mode in peer associations which does the
timestamp followup. It would be really nice if ntpd supported the
SO_TIMESTAMPING option.

http://www.eecis.udel.edu/~mills/ntp/html/xleave.html

> Both are running Linux kernel 3.3.4, tickless, no preemption,

You may want to try nohz=off, it seems there is a bug in the kernel
which can cause an extra jitter of couple microseconds in the
system clock readings when the system is idle.

> 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

Cool. Are those numbers nanoseconds?

-- 
Miroslav Lichvar


More information about the questions mailing list