RPI + Adafruit GPS sanity check

[Gary E. Miller]

Yo Patrick!

On Fri, 17 May 2019 10:21:24 +0800
Patrick <201905-ntpsec at jslf.app> wrote:

> On 2019-05-16 11:42, Gary E. Miller wrote:
> > No matter how good your skyview, the NMEA based time will be
> > aweful.  
> 
> This is because although the GPS chip knows where and when it is,
> there is much jitter in conveying that time info to any userland
> process -- i.e. encoding into NMEA + transmission over 9600 baud
> serial line + kernel to user land + decoding.

Yes, whuch is unrelated to skyview.

> The instability in the offset is due to what? It's not the
> online-average of the lag since NTP started.

The GPS uses an interative algorithm to compute the PVT solution,
which takes a variable time to compute.  Then the NMEA binary sentences
are variable length, which take another variable amount of time to
compute.

> > > Since the PPS is /dev/pps0, gpsd can be dropped.  
> >
> > Not really.  PPS just tells you the top of the second, but not which
> > second.  
> 
> Won't refclock 20/nmea provide resolution at the second?

Depends on how you NMEA is setup, also with a lot of jitter.

> It can be set
> with a large offset to de-preference it.

Yes, a common tactic.

> Alternatively, set the 20/nmea refclock to be stratum 10?

Which does little good.  Stratum is to prevent loops, not to
be used for chimer selection.

> > > Is there anything that should be done to prevent mishaps like the
> > > USNO has had over time?  
> > Care to be more specific?  
> 
> https://groups.google.com/forum/#!topic/comp.protocols.time.ntp/FSDd-nmjzZs
> 
> https://isc.sans.edu/diary/Behind+the+Random+NTP+Bizarreness+of+Incorrect+Year+Being+Set/14548

GPS Week Rollover issues.  Shit happens.

> It seems that one fix is to have an iptables rule that drops NTP
> clients' packets unless some notion of goodness is obtained -- say 5
> peers with reachability of 377 and all in agreement?

Not gonna do that in iptables.  Plus, iptables is obsolete, use
nft.

> Or is there a way to have NTP stop serving time when the GPS and other
> peers aren't in agreement at the resolution of 1 second?

NTP does its best to pick the right time, just give it enough good
chimers to be able to make a good decision.

> > > ####### /etc/ntp.conf #######
> > >
> > > refclock pps         refid PPS ppspath /dev/pps0 minpoll 4
> > > maxpoll 4  
> >
> > Play with other poll times.  
> 
> How to tell whether there is an improvement?

Look at the jitter.  Use ntpviz.

> > > prefer refclock nmea        refid GPS path /dev/ttyAMA0 baud
> > > 9600  
> >
> > absolutely NOT.  
> 
> Because of the 'prefer'? That looks like a line-wrap issue:
>   https://lists.ntpsec.org/pipermail/users/2019-May/000190.html

Ah, that is better.  Best to trim lines to less than 80 chars to
prevent email munging.

> > > # local servers
> > > server 10.8.0.10     iburst minpoll 4 maxpoll 4
> > > server 10.8.1.7      iburst minpoll 4 maxpoll 4  
> >
> > Maybe too short a poll interval on the net.  
> 
> Because of the load on the remote server?

No.

> These are all machines that I admin.

Which matters why?

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: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20190516/6ce49497/attachment.bin>