[ntp:questions] Idea to improve ntpd accuracy

Danny Mayer mayer at ntp.org
Fri Feb 26 03:50:33 UTC 2016

On 2/25/2016 10:29 PM, Weber wrote:
> Thanks for the link. I'm not surprised that someone else already had the
> idea. I was poking around and see that 1588 does something similar with
> a "follow up" packet.

I should have mentioned that this checksum trailer extension field is
needed to get the idea to work for NTP. Unfortunately you can't have
security or a MAC to do this as it needs to make changes to the
timestamps and then add the extension field to fix the UDP checksum. Tal
can say more.

> On 2/25/2016 7:09 PM, Danny Mayer wrote:
>> Already thought of so it's a good idea! See
>> https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/ for
>> details.
>> Danny
>> 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...?
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list