[ntp:questions] Idea to improve ntpd accuracy

Weber wsdl at osengr.org
Thu Feb 25 21:52:03 UTC 2016


This may or may not be worthwhile, but I thought I'd throw it out there 
and see what happens:

Recent work testing some microsecond-accurate NTP servers lead me to an 
idea that could improve accuracy of measurements made by ntpd. These NTP 
servers have hardware timestamps on receive but that's not possible on 
transmit w/o a custom NIC. I've seen this issue discussed before.

The next best thing is to generate the transmit timestamp based on a 
guess as to how long it takes the NIC to get on the wire and send the 
packet. That works pretty well as long as there's no other network 
traffic. In this situation, it is possible to make use of microsecond 
accuracy in an NTP server.

Now, add some typical network traffic and the time it takes the NIC to 
get on the wire becomes unpredictable to the tune of 200us or more (for 
100 base-T Ethernet). The server's microsecond accuracy is largely lost 
in the noise.

The NIC generates an interrupt after the packet is sent which can result 
in a fairly accurate trailing hardstamp. The problem is...the packet is 
already gone and has the wrong transmit timestamp.

Here's my idea:

What if the poll response packet contained a flag or indication of some 
sort which means "this is an approximate transmit timestamp". That 
packet would then be immediately followed by a second response packet 
with a more accurate transmit time. The second packet could be otherwise 
identical to the first, or it could be a new flavor of packet that 
contained only the transmit time (that would save on network bandwidth).

The ntpd process would need to use the receive time of the first packet 
(the one with an approximate tx timestamp) and merge in the following 
accurate tx timestamp before performing the normal processing associated 
with a poll response.

Here are the pros and cons I can think of:

Pros

* Possible accuracy improvement of 1-2 orders of magnitude. I know ntpd 
already does some work to try and filter out network delay variation so 
the improvement might not be a full 2 orders of magnitude.
* Could potentially be made compatible backwards compatible with ntp 3/4 
protocols

Cons

* Increased network traffic
* Improvement to that level of accuracy might not be of interest to anyone
* Could be a fair bit of work for at least a couple of folks
* I may have (or probably) missed some stuff regarding network behavior 
that would reduce the level of improvement that could be realized.
* Perhaps this is less of an issue on G-bit Ethernet?

Wondering if anyone thinks this idea is worth pursuing further...?



More information about the questions mailing list