Re: NTPsec reports excessive jitter from GPSD/KPPS SHM

[Gary E. Miller]

Yo Nick!

On Fri, 06 Mar 2020 00:23:53 +0000
"Nick Burkitt" <address@hidden> wrote:

> Yes, the u-blox PPS is 100 ms wide. We use the rising edge for other 
> purposes, so I've implemented a second interrupt for the falling edge 
> (Zynq GIC interrupts are rising edge/high level only). Now I'm
> capturing both assert and clear. It doesn't seem to have made any
> difference, though.

Really?  It should have moved the offset of SHM(1) by 100 millisec!
Unless (see below).

Since you are not using the gpsd code for KPPS it is hard to know
what is going on.  Did you change your code as well as adding clear?
Your code was only looking at assert.

> root@MPM-4006:~# ppstest /dev/pps0
> source 0 - assert 1583451764.950840664, sequence: 1111 - clear  
> 1583451764.050612818, sequence: 1110

Yup, there is the 100 msec pulse width.  It does appear that the assert
is the correct KPPS edge to use.  And your system clock is right in the
middle.  So looking at assert was the right thing as you had been doing.

Since you are not using the gpsd KPPS code, and you did not supply any
changes you made to your KPPS code, unclear, so far, what it happening.

> =========================================================================
> Here's cgps:

That did not survive email well.  Also, your attempt to obfusacte your
lat/long failed: lat: 37.318070, Lon: -121.783261, AltHAE: 25.57

Looks like:  3222 Scotch Heather Ct, San Jose, CA 95148

All I needed was: 3D FIX.

> Here's ntpmon:
> 
>       remote           refid      st t when poll reach   delay
> offset jitter
>   SHM(0)          .GPS.            0 l   17   64  377      0ns
> 48.263ms 14.602ms
> *SHM(1)          .PPS.            0 l   15   64  377      0ns
> -26.60ms 16.084ms

Huh?  Sure looks like SHM(1) is being used.  Note the asterisk in column
one?  No problem here.  How long did you wait?  It can take hours for
ntpd to pull your system clock into sync.

> I should note that the numbers that NTPsec uses for offset and jitter 
> wander all over the map, from a low of ~2 ms to 50 or even > 100 ms.

NTPsec does not use offset or jitter, it calcualtes them.

You should expect that for up to several hours, even days.  Especially
if the drift has never been previously calibrated, or the server has been
moved.

> Where it's getting those numbers from is a mystery to me.

Easy, they are calculated from observations.  The RFCs show how they
are calcualted.

It takes a LONG time for ntpd to pick the best time source, and then
to steer the system clock to it.

So, it looks good now, the only issue is your lack of patience.  And
maybe you forgot -g on the ntpd command line.

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

pgpEz_e7awMi4.pgp
Description: OpenPGP digital signature