[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7

[David Lord]

Martin Burnicki wrote:
> David Lord wrote:
>> I had maxpoll set at 10 when I first setup my network but sometimes
>> at that poll rate combined with daily temperature variations offsets
>> would gradually increase both in +ve and -ve directions. This could
>> clearly be seen in mrtg graphs. Solution was to reduce maxpoll to 7
>> or 8. I never thought of this as a bug. There was a daily variation
>> depending on season and a variation due to system load.
>>
>> This has been with NetBSD 1997 to date and a period of a few years
>> when running FreeBSD. Currently NetBSD-6, ntp-dev-4.2.7p401, four
>> of the servers are in the pool.
> 
> I think we need to distinguish if there's a computational problem in the 
> code due to a rounding error, range overflow, or similar, or a 
> systematic problem, where ntpd is in general unable to apply adjustments 
> fast enough to compensate frequency drifts varying fast with temperature 
> changes.
> 
> Which the former can be fixed in the code once the wrong code has been 
> detected, the latter can only be changed by redesigning ntpd's behavior.
> 
> As far as I know long polling intervals are used preferably to increase 
> the accuracy of the drift measurement. For example, if you want to see 
> if your wrist watch goes fast or slow, you can't see this properly if 
> you check it once per minute. However, if you check it after one day you 
> see how many seconds the wrist watch has gained or lost.
> 
> However, as I understand this, this only yields proper results if the 
> frequency doesn't vary too much over the measurement interval.
> 
> So if ntpd only compares the time once every 1024 s the frequency may 
> have increased and decreased again during this interval, e.g. due to 
> varying CPU load, without this being noticed by ntpd. So the correction 
> computed in such case is probably not optimal.
> 
>  From my understanding it would be better if ntpd polled in shorter 
> intervals to detect if the frequency drift is constant, or not. If it is 
> not it could decrease the polling interval to react faster on frequency 
> changes.
> 
> However, changing the latter would need some reengineering of the 
> control loop.
> 

My server with Sure gps/pps has offset below 3 us other than when
nightly cron jobs give a couple of 35 us spikes. From loop_summary
over 7 days, typical range for rms offset is 3.9-6.1.

Over 7 days my four pool servers have following rms offset ranges
ntp0=784-1646, ntp1=405-837, ntp2=310-434, ntp3=586-1270 but there
were numerous reboots and ntpd restarts over that period.

I want to try using a stable external system clock source, TCXO,
OCXO or rubidium laser.


David