RPI + Adafruit GPS sanity check
Gary E. Miller
gem at rellim.com
Fri May 17 04:33:26 UTC 2019
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
> > > 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?
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
> 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:
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?
> These are all machines that I admin.
Which matters why?
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
Size: 851 bytes
Desc: OpenPGP digital signature
More information about the users