[ntp:questions] Fwd: Re: [ntpwg] Idea to improve ntpd accuracy
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
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.
More information about the questions