Kernel NTP flipping between FLL and PLL modes

[Peter Jeremy]

On Fri, 2005-Apr-01 19:38:41 +0300, Andriy Gapon wrote:
>I can second that. I have never seen anything like this with 5.2.1 as
>soon as I upgraded to 5.3 I started seeing messages like these:
...
>Mar 29 22:15:40 oddity ntpd[400]: time reset -0.288522 s
>Mar 29 22:15:40 oddity ntpd[400]: kernel time sync enabled 6001
>Mar 29 23:09:19 oddity ntpd[400]: time reset +0.530732 s
>Mar 29 23:09:19 oddity ntpd[400]: kernel time sync enabled 2001
>Mar 29 23:35:18 oddity ntpd[400]: time reset -0.165853 s
>Mar 30 00:41:14 oddity ntpd[400]: time reset -0.199104 s
>Mar 30 11:21:21 oddity ntpd[400]: kernel time sync enabled 6001
>Mar 30 11:38:27 oddity ntpd[400]: kernel time sync enabled 2001
>Mar 30 17:22:37 oddity ntpd[400]: time reset -0.392425 s
>Mar 30 17:22:37 oddity ntpd[400]: kernel time sync enabled 6001
>Mar 30 17:26:06 oddity ntpd[400]: kernel time sync enabled 2001
>Mar 30 17:28:15 oddity ntpd[400]: time reset +0.309711 s
>Mar 30 18:07:02 oddity ntpd[400]: time reset +0.164515 s
>Mar 30 18:41:43 oddity ntpd[400]: time reset -0.391355 s
>Mar 30 19:00:17 oddity ntpd[400]: time reset +0.598313 s
>Mar 30 19:47:45 oddity ntpd[400]: time reset -0.276978 s
>Mar 30 21:26:24 oddity ntpd[400]: time reset +0.158781 s
>Mar 30 23:18:01 oddity ntpd[400]: time reset +0.160708 s
...
>2001<->6001 flips do not trouble me a bit (but annoying), time resets
>are not a good thing definitely.

I've seen similar reset behaviour in the past.  The investigating I
did suggested that the PLL could become unstable under some conditions
(though I never managed to work out exactly what triggered the
mis-behaviour).  It would either lock up around +/- 500ppm and
regularly jump in one direction to compensate or it would start
swinging wildly and regularly jump back and forth with the net time
jumped close to zero (in the latter case, looking at the loopstats
showed that the frequency offset would start oscillating with the
swings getting larger over time).  Manually setting ntp.drift to a
realistic value and restarting ntpd seemed to cure the problem (at
least temporarily).

I haven't seen that problem recently - I think it was in the early 4.x
period.

>I suppose that it might be possible that the root cause is in my local
>network conditions,

If it is network conditions, enabling huff-puff might help.  If possible,
work out what the real drift on that system is and re-initialise
ntp.drift as well.

-- 
Peter Jeremy