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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
