[ntp:questions] Fwd: Re: [ntpwg] Idea to improve ntpd accuracy

Weber wsdl at osengr.org
Sun Feb 28 03:25:21 UTC 2016

Thank you to all who replied to my inquiry!

Regarding required accuracy...there really is none in my case. It's just 
a matter of "how good can this get?" However, the results may be of 
actual use to others, just not me.

I have gone to the effort of implementing the interleaved symmetric mode 
in the embedded NTP box. Most of the effort was just in figuring out how 
it's supposed to work. Some of the on-line documentation is a little 
rough around the edges and might not completely up to date w.r.t. the 
4.2.8 release. I used behaviors found in the current release in 
preference to other docs.

I am running tests now comparing a client/server box with symmetric peer 
and will send the results when available. After everything stabilizes on 
a quiet network hub, I'll plug it into another busy network (including 
NTP packets to the embedded boxes) and see what happens. Should be 
interesting. I think as part of this I'll get a measurement of the delay 
inherent in the Linux machine's transmit softstamp, and can compare that 
to other published numbers.

The implementation was pretty easy because the embedded NTP box does not 
really care to find out anything about the clocks of its symmetric 
peers. It treats symmetric polls more like a client request, providing 
valid data in the response. Perhaps that's a perversion of symmetric 
mode but it's the only way to get transmit hardstamps into the mix and 
it seems to work. The Linux test machine happily accepts the symmetric 
peer as the system peer so it seems like a viable way to do things.

On Fri, Feb 26, 2016 at 02:21:47PM +0100, Martin Burnicki wrote:
>  Tal Mizrahi wrote:
>  >  Sounds a bit like interleave mode, right (a bit similar to PTP two-step clocks)?
>  But the problem is still that (again, AFAIK) NTP interleave mode works
>  only in broadcast mode.

It works also in the symmetric mode.

>  In broadcast mode ntpd only tries to measure the packet delay when the
>  association is first created, but the network route etc. can change at
>  any time, so IMO interleave mode provides only limited benefit.

It probably wouldn't be difficult to modify ntpd to run the delay
measurement periodically.

A bigger problem is that the delay is measured using the client/server
mode packets, for which there is no interleaved mode. If the delay is
inaccurate, the offset is inaccurate too, even if the tx timestamp in
the broadcast packet was accurate.

Broadcast clients would need to create ephemeral symmetric
associations with the server in order to measure the delay accurately.

Miroslav Lichvar

More information about the questions mailing list