Problem with GPSD refclock

[Rich Wales]

Gary E. Miller wrote:

> Agreed, the trick is how to keep SHM(0) from being selected, except as a
> last resort.  As I already said the best way to do that is in dispute.
> So please experiment and report back.

Thanks.  I did some experimenting just now, and my conclusion is that
I'm best off using *only* the PPS-synced SHM(1) and not including SHM(0)
in my configuration at all.

Details:

I tried removing SHM(1) and keeping SHM(0) on my home network's primary
server.  I had SHM(0) fudged with time1 = 0.460, which (based on earlier
experience) kept its offset to within roughly +/- 40 msec.

My primary server promptly latched on to SHM(0), even though it was at
stratum 6, and ignored two external servers at strata 1 and 2.  The
other two Linux boxes on my home network (configured to "prefer" the
primary server) remained synced to the primary server and went to
stratum 7 -- each one ignoring its own two external stratum-1/2 servers.

After several minutes, though, my primary server lost interest in SHM(0)
and started syncing with one of its external servers.  I assume it might
eventually have settled back on reasonably correct time (along with the
rest of my home network), but I decided to stop the experiment at this
point.

I am now running with SHM(1), marked as preferred, and I commented
SHM(0) out of the configuration entirely.  After several minutes in this
new configuration, everyone is pretty well settled on good time.

My conclusions:

Non-PPS-corrected SHM(0) is really bad news, even when fudged to make it
"fairly close" to the correct time -- mostly, I think, because of its
high jitter.

Even with a high stratum (6), ntpsec still liked SHM(0) better than
outside stratum-1 or -2 servers.  I did *not* mark SHM(0) as preferred
in ntp.conf, but ntpsec seemed to prefer it anyway (possibly because it
gives great weight to local refclocks regardless of stratum or jitter?).

Other servers peering to an SHM(0)-synced server, marked in their
configurations as preferred, hung on to it even though it was at a high
stratum and ignored multiple external stratum-1 / stratum-2 servers.

If I were to lose my good GPS signal, my home network would probably
sync to SHM(0) even if it had a high stratum, and even in the presence
of multiple good external time sources.  So I'm probably best off not
using SHM(0) at all -- either marking it as "noselect", or simply not
having it in the configuration at all.

If I were to lose my good GPS signal *and* lose Internet connectivity at
the same time, I would probably be better off just letting my home net
run free for a while, until either GPS or Internet service was restored,
rather than use SHM(0) even as a last resort.

SHM(1) works just fine, even without SHM(0) in the configuration at all.

Rich Wales
richw at richw.org