Treating issue #62 as a documentation problrem.

[Eric S. Raymond]

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
reception.

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
problem narrative:

......................................................................
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
GPS signals.

......................................................................

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