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

unruh unruh at wormhole.physics.ubc.ca
Tue Jan 18 19:22:45 UTC 2011


On 2011-01-18, David Woolley <david at ex.djwhome.demon.invalid> wrote:
> 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?

It depends. There is not one correct Allan intercept. The correct value
depends on lots of stuff, including how the computer is used (thermal
effects). ntpd assumes one value, measured about 15 years ago. The fact
that chrony does 3-20 times better than ntpd at controlling the clock
with exactly the same data that ntpd uses suggests that ntpd is far from
optimal.

>
>> 
>> 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.

??? I have never seen 100s of ms. I have rarely seen 1ms. 


>
> 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