Kernel NTP flipping between FLL and PLL modes

[Andriy Gapon]

on 05.04.2005 22:32 Peter Jeremy said the following:
> Note that this code doesn't exist in 5.3.  It was introduced sometime
> between 5.3 and 5.4.  In any case, looking at the associated comments,
> this only affects the FLL/PLL loop gain.

Yes, I see that I looked in a wrong place.

> The FLL/PLL switch is set is in sys/kern/kern_ntptime.c:hardupdate()
> using:
>         time_status &= ~STA_MODE;
>         if (mtemp >= MINSEC && (time_status & STA_FLL || mtemp > MAXSEC)) {
>                 L_LINT(ftemp, (time_monitor << 4) / mtemp);
>                 L_RSHIFT(ftemp, SHIFT_FLL + 4);
>                 L_ADD(time_freq, ftemp);
>                 time_status |= STA_MODE;
>         }
> and this code hasn't changed.  MINSEC is 256 (which matches the comments)
> MAXSEC is either 1200 or 2048 (depending on which header file is active),
> though the comments imply it is 1024.  mtime is the time since the last
> adjustment (call to hardupdate()).

MAXSEC==2048 is used, the contrib header file could not be included
because its directory is not included with -I. Besides I've verified it
by sneaking in -E

> STA_FLL is set in ntpd/ntp_loopfilter.c:
>         if (sys_poll > NTP_MAXDPOLL)
>                 ntv.status |= STA_FLL;
> though the associated comment states "for legacy only".  (And I'm
> never seeing STA_FLL transitions in syslog).  This sets STA_FLL if the
> polling interval is > 2^10 (1024).  By default, sys_poll is limited to
> NTP_MAXDPOLL so this should never occur.  (You can over-ride it with
> "maxpoll N" on peer/server config lines).

I am using the default value of maxpoll, no overrides.
So, IMO this leaves one possibility: mtemp > 2048, i.e. hardupdate() was
not called for longer than this time i.e. either ntp_adjtime() was not
called or it was called without MOD_OFFSET.
It looks like it is not trivial to find the cause of this.

BTW, what is the best way to get out of ntpd everything it can tell
about its operations ?

-- 
Andriy Gapon