✘Refclock #20 flakey with marginal GPS signal.

[Gary E. Miller]

Yo All!

I can confirm that 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 milliSac NMEA offset. ntpd now marks #20 as high jitter,
and transfers to other good chimers.

This leaves the clock somewhere between the NMEA and other good chimers.

Next ntpd will see the PPS on the #28, 480 milliSec off the other way, and
makr #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 not a problem when using the SHM (#28) refclock.  Also
not a problem when using NMEA on #20 and PPS on #22.

Refclock #20 can likely be fixed the way refclock #48 was partially
fixed, by not muching the NMEA and PPS times together into the jitter,
offset, etc.

Until #20 is fixed, consider it unhealthy with marginal GPS signals.

https://gitlab.com/NTPsec/ntpsec/issues/62

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160511/66d2893a/attachment.bin>