Re: NTPsec reports excessive jitter from GPSD/KPPS SHM

[Gary E. Miller]

Yo Nick!

On Fri, 06 Mar 2020 03:36:43 +0000
"Nick Burkitt" <address@hidden> wrote:

> Yes, I modified my driver to tell KPPS about the new "clear"
> interrupt. That's why KPPS now reports clear events. The code is
> below, for what it's worth.

So by "driver" you mean kernel driver?

> The machines (I have five of them) have all been getting NTP time
> from Internet sources for the better part of a year, so their system
> clocks' drifts should be well characterized by now.

Not really.  You are using the usa pool and getting horrible
chimers.  Plus, everytime you restart, ntpd has to pull the
system time, slowly, to correct.  This is because your
SHM(1) poll is too long.  Make it shorter so that it
locks first.  

My guess is that your server is locking to some far away pool server
and getting pulled off, then will take a long time to correct.

> NTPsec command line:
> /usr/local/sbin/ntpd -g -N -u ntp:ntp

Ah, good.  You do have the "-g".

> While the ntpmon snapshot I included showed SHM(1) being used,
> sometimes ntpd likes SHM(1), and sometimes it doesn't. Right now it's
> giving SHM(1) the silent treatment. In a while, it might have a
> change of heart.

Nothing really matters for the first hour.  How long have you been
waiting?

> 
>       remote           refid      st t when poll reach   delay
> offset jitter
>   SHM(0)          .GPS.            0 l   29   64  377   0.0000
> 49.6561 2.9519
> xSHM(1)          .PPS.            0 l   28   64  377   0.0000
> -27.0924 7.5853
> 
> Yep, there it goes:
> 
>       remote           refid      st t when poll reach   delay
> offset jitter
>   SHM(0)          .GPS.            0 l   50   64  377   0.0000
> 30.2184 16.2243
> *SHM(1)          .PPS.            0 l   48   64  377   0.0000
> -40.9404 13.4211
> 
> Here's a few minutes worth.

Which is not useful.  The long time constants in ntpd take hours
to settle.  And not helpful without seeing the other chimers.

> Here's a snapshot of ntpmon from a another copy of the device that's 
> been running for three days. This is using the assert-only KPPS
> driver, of course.
> 
>       remote           refid      st t when poll reach   delay
> offset jitter
>   SHM(0)          .GPS.            0 l   59   64  377   0.0000
> -2.3327 0.0396
> xSHM(1)          .PPS.            0 l   21   64  377   0.0000
> -133.573 3.4322

Not helpful without seeing your other chimers.

> Revised KPPS driver code:

And where does that code go?  In gpsd?  Or??  If it in the kernel then
I can't really say what may be right or wrong with it.

Making the unfounded assumption that your "driver code" is correct,
See what happens with the following changes:

set SHM(1) to poll faster:

refclock shm unit 1 minpoll 3 maxpoll 3 refid PPS prefer

And be sure it is at the top of the ntp.conf.

Then, pick some chimers that are local to you.  The pool ones you
have been getting are not so good.

If that does not help, then something strange is going on with your
(unspecified) system.  Maybe CPU sleeping, interrupts acting strangely,
CPU clock rate changing.  To eliminate those make sure your system
is running the "performance" governor.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp1PSFn0_gTx.pgp
Description: OpenPGP digital signature