Kernel NTP flipping between FLL and PLL modes

Peter Jeremy PeterJeremy at optushome.com.au
Tue Apr 5 12:32:40 PDT 2005


On Tue, 2005-Apr-05 15:01:07 +0300, Andriy Gapon wrote:
>on 01.04.2005 20:40 Bob Bishop said the following:
>> 
>> Unlikely I think. As I said, I've got several machines on the same LAN:
>> the 5.3's misbehave; the others don't.
>
>#define       CLOCK_ALLAN     1500.
>...
>double        allan_xpt = CLOCK_ALLAN;
>...
>if (ULOGTOD(sys_poll) > allan_xpt / 2) {
>...
>
>if I understand the above "random" lines of code in
>contrib/ntp/ntpd/ntp_loopfilter.c correctly, then PLL<->FLL switch
>occurs when polling interval goes 512<->1024, which is perfectly
>possible under certain conditions with default ntp settings: minpoll=64,
>maxpoll=1024 if ntp.conf(5) can be trusted.

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.

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

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

-- 
Peter Jeremy


More information about the freebsd-stable mailing list