[ntp:questions] NTP server with Garmin GPS 18 LVC

unruh unruh at invalid.ca
Fri Dec 20 18:48:07 UTC 2013


On 2013-12-20, Harlan Stenn <stenn at ntp.org> wrote:
> David Lord writes:
>> If ntpd is throwing away 7 out of 8 polls I'd say their results
>> could be similar to mine.
>
> ntpd doesn't throw away 7 out of 8 polls, Bill just likes to say that.
>
> ntpd chooses the best data it sees (for its definition of "best") and
> uses those.

Yes, and with its defintion of "best" it throws away roughly 7 of 8
pieces of data that it collects. Roughly it looks through the last 8
polls of from a remote server, and takes the one with the minimum delay. 
The other 7 are not used. Now it does this on every poll, so if the
delay consistantly decreases, it could take every poll and use it. But
in general, once things have settled down, it takes roughly on in every
8 (and I emphasise roughly) even if those other 7 have very similar but
slightly larger delays. Now, IF the variation in the offsets is caused
primarily by the variations in one  of the trip times (outbound or
inbound),
then this might be a good strategy. But if the variation is caused for
example by noise from that remote system say, or noise from your
system's reading of its own clock, then that is very bad strategy. You
get far more out of averaging those 8 ofsets say (or doing a linear
regression as chrony does)-- random noise can be averaged out.
Systematic noise (which is the model that is used to justify that clock
filter) cannot.  
While delays in one of the paths to or from the remote system might well
be the dominant noise source for that nptd over Malaysian bush telegraph
that Mills quotes, it is not at all clear to me that that is true of the
vast majority of ntpd uses today. It needs research. 

If you look at www.theory.physics.ubc.ca/chrony/chrony.html, I have a
whole bunch of scatter plots ( offset vs delay) of the machines I have
here. It is clear that some of the noise, especially the ones with a
large delay, fit in with that "systematic" scenario. But much of the
noise, including delay noise is clearly random and can be averaged away. 

Now it would be good to also have a local PPS type refclock against
which to judge the network timing, to see both the true one way delays,
and the systematic errors, but I have not set that up. 

But the short of it is that throwing away 7 of 8 offset data points,
which is the effect of the ntpd clock filter, is almost certainly not
the optimal use of the data collected by ntpd. 

Note-- the above is the behaviour with external sources, not with
refclock sources. There the popcorn filter throws away about 40% of the
data ( those offsets with the largest deviation of the median offset in
a set of data (eg 16 data points with a poll of 4)) The justification of
this is stronger. The distribution of the data noise is almost certainly
not gaussian, and has a component with "long tails" probability
distribution   and this is a crude attempt to eliminate those data
points which are extremely hard to estimate (See Talib's "Black Swans"). 
This also could do with more research, but I am much less worried about
this use of the data. Still, IF the noise really is gaussian, then this
procedure still increases the fluctuations by about 50%, and makes ntpd
about 50% worse than it could be in its estimation of the true time and
rate. This might be worth paying, especially as the data (once per
second) is so abundant. The 7/8 discard for rare data (once per 20 min
at poll 10) is far less justifiable. 



 

>
> H



More information about the questions mailing list