Treating issue #62 as a documentation problrem.
Eric S. Raymond
esr at thyrsus.com
Wed Oct 12 04:37:40 UTC 2016
On IRC Gary and I concluded that there isn't much that can be actually
done about #62 (Refclock #20 behaves perversely on GPS signal loss) so
it's best documented as a known hazard of using GPSes with intermittent
I'm taking this one off the tracker and to email because email is IMO
a bettter channel for addressing documentation issues. Here is Gary's
Refclock #20 behaves perversely on GPS signal loss.
Using refclock #20 for NMEA and PPS can lead to more time instability
than it should when the GPS signal gets lost and re-acquired.
The test is simple, just setup a refclock #20, like this:
# #20 GPS direct
server 127.127.20.0 mode 16 minpoll 4 maxpoll 4
fudge 127.127.20.0 flag1 1 flag2 0 refid GPS
For fun, I setup another GPS on SHM (refclock 28) for comparison:
# SHM for gpsd
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.480 refid GPS
# SHM for PPS and gpsd
server 127.127.28.1 prefer minpoll 4 maxpoll 4
fudge 127.127.28.1 refid GPS1
Yes, there is no time2 to correct the NMEA fudge on #20, but that is a
common configuration since it is hard to see the fudge, so people do
not set it properly. It makes this problem easier to see, but setting
time2 does not fix the problem.
In normal usage, #20 takes the NMEA time to find the nearest second
for the PPS, then uses the PPS time going forward to compute the
offset and jitter. Now cover the GPS with Aluminium foil, until it
loses signal lock, ntpd will properly remove that refclock as bad,
after the expected delays. Now uncover the GPS, and watch the fun.
ntpd will first see the now good NMEA 480 millisSec off. Since it
still has a low jitter (from the PPS), ntpd will now jump the local
clock part way of the 480 milliSec NMEA offset. ntpd now marks #20 as
high jitter, and transfers to other good chimers.
This leaves the system clock somewhere between the NMEA and other good
chimers. So now all the refclocks get marked high jitter. Next ntpd
will see the PPS on the #28, 480 milliSec off the other way, and mark
#20 as high jitter.
Eventually, if the PPS stays stable, the computed jitter will
decrease, and ntpd will one again select the #20 PPS. Not good, and
hard to spot since the underlying NMEA and PPS data is mushed and
hidden from the user. This scenario is not a problem when using the
SHM (#28) refclock. Also not a problem when using NMEA on #20 and PPS
on #22, or #46 in undocumented mode.
Refclock #20 can likely be fixed the way refclock #46 was partially
fixed, by not mushing the NMEA and PPS times together into the jitter,
offset, etc. Until #20 is fixed, consider it unhealthy with marginal
I have some problems with this as-is:
1. What is magic about "480 millisSec"? Why that offset in particular?
2. This is too specific a set of circumstances to use as documentation
of a general problem.
3. I think I see why no analogue of this iccurs with the shm driver -
you either get good parallel samples on units 1 and 0 or neither. I
don't get why #20+#22 or #46 don't have this problem.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The saddest life is that of a political aspirant under democracy. His
failure is ignominious and his success is disgraceful.
-- H.L. Mencken
More information about the devel