[ntp:questions] Idea to improve ntpd accuracy
wsdl at osengr.org
Fri Feb 26 03:29:38 UTC 2016
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.
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
> 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:
>> * 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
>> * 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