[ntp:questions] false ticker after GPS coldreset

Gary E. Miller gem at rellim.com
Fri Nov 3 19:08:13 UTC 2017


Yo Martin!

On Fri, 3 Nov 2017 14:27:52 +0100
Martin Burnicki <martin.burnicki at meinberg.de> wrote:

> >> Anyway, gpsd seems to accept the raw GPS time as UTC time, feeds
> >> it to ntpd, and ntpd sets the Linux system time off by a number of
> >> seconds.  
> > 
> > Which is why gpsd should rarely be the only input into your ntp
> > daemon.  
> 
> Hm. According to my own observations, if you get most accurate time
> from your GPS receiver operating normally, as single time source, and
> then add some upstream NTP sources beside the GPS refclock the
> resulting accuracy of the system time becomes worse.

That can happen, but there are mitigation strategies.  First I use
the prefer keyword on my PPS time.  I'm not seeing that here:

     remote           refid      st t when poll reach   delay   offset   jitter
*SHM(1)          .PPS.            0 l    1    2  377      0ns    722ns    968ns
+spidey.rellim.c .PPS.            1 u   25   32  377 254.35µs 57.594µs 63.995µs
-pi.rellim.com   .PPS.            1 u   22   32  377 416.27µs -654.8µs 154.28µs
 pi2.rellim.com  .PPS.            1 u   9d   32    0 581.89µs 28.000µs      0ns
 pi4.rellim.com  .STEP.          16 u    -   32    0      0ns      0ns    954ns
-catbert.rellim. .PPS.            1 u   30   32  377 376.48µs 455.34µs 49.887µs
-kong.rellim.com 204.17.205.8     2 u   59   32  266 347.37µs 196.00µs 30.736µs
-backup.rellim.c 204.17.205.8     2 u   22   32  377 412.37µs 158.38µs 48.486µs
+SHM(0)          .GPS.            0 l   13   16  377      0ns 507.16µs 672.13µs

 
Note the 722 ns offset and 960ns jitter on mmy PPS.

> So it's not generally better to use other time sources beside a GPS
> receiver.

Until your GPS goes wacky...

> You can simply try this if you look at the smoothness of the loopstats
> generated with a GPS receiver only vs. the loopstats generated with a
> GPS receiver plus some NTP servers on the network.

I've got a dozen chimers up now with PPS, not seeing it.

> ntpd doesn't anyway accept the time from a source that indicates that
> its time is not synchronized. So it wouldn't accept the time from the
> GPS receiver (directly or via gpsd/SHM) if a "not synchronized" status
> was available from the receiver and passed to ntpd.

Which is NOT what the OP was complaining about.  His GPS was saying synced,
but was off by the UTC/GPS offset which had not been downloaded yet.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntp.org/pipermail/questions/attachments/20171103/fe65c8f9/attachment.sig>


More information about the questions mailing list