[ntp:questions] Polling interval in FreeBSD vs. Windows

David Woolley david at ex.djwhome.demon.invalid
Tue Jan 18 12:49:52 UTC 2011


Miroslav Lichvar wrote:

> The trouble is with "when locked". When the jitter reaches a certain
> point (or better the ratio between jitter and clock stability --
> usually expressed as Allan intercept in the NTP docs), the PLL won't
> be able to get a good lock and the clock accuracy will be limited only
> by the clock stability, not the jitter.

Are you suggesting that the assumed Allan intercept if a couple of 
orders of magnitude too high?

> 
> As ntpd fixes the time constant to the polling interval, the only
> thing you can do is to use a lower polling interval. If ntpd was able

Linking them makes total sense.  The poll interval needs to be a small 
submultiple of the time constant, so that there is reasonable 
oversampling and allowance is made for the subsetting of the samples in 
the initial filter.  Polling faster than this adds very little 
information to the timing solution and polling slower will break the 
Nyquist criterion.

> to change time constant and PLL/FLL mode independently from polling
> interval, it would be a huge improvement. Would be very tricky though.
> 
> I'd suggest you to look at the clknetsim graphs, I think you can get a
> very good understanding how is time and frequency accuracy affected by
> jitter/wander, poll interval and the PLL gain.
> 
> http://mlichvar.fedorapeople.org/clknetsim/
> 
You are measuring (RMS) offset, which is not the same as error, and you 
are not accounting for network wander, which can reach 100s of ms, if 
NTP isn't prioritised.

Actually, I suspect the big problem with NTP's theory is that it assumes 
that both the jitter and wander come from the clock.  It breaks down if 
jitter comes from the measurements (network) and wander from the clock 
(favours short time constant) or jitter comes from the clock and wander 
from the network (favours long time constant).




More information about the questions mailing list