[ntp:questions] Idea to improve ntpd accuracy

Danny Mayer mayer at ntp.org
Fri Feb 26 03:09:51 UTC 2016

Already thought of so it's a good idea! See
https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/ for


On 2/25/2016 4:52 PM, Weber wrote:
> 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