Problem with GPSD refclock

[Rich Wales]

Gary E. Miller wrote:

> You are correct, I meant noselect on SHM(0).

OK, thanks.

Now, getting back to your original comment (duly corrected):

> No, setting a good fudge on the NMEA time is a bad thing.  You only
> want ntpd to use SHM(0) as a last resort.  If you know you have
> good network time as a backup then set SHM(0) to noselect.

Clearly, if I do have good network time from a working Internet
connection, I wouldn't want to use non-PPS-corrected time from SHM(0).

But I can still see a possible reason to use SHM(0) -- with a reasonable
fudge value to bring it into the ballpark, and a high stratum value to
discourage my local peers from using it except as a last resort -- in
the (hopefully rare and temporary) situation where my GPS signal was
degraded *and* my Internet connection was also degraded or lost entirely.

Or are you saying that SHM(0) is inherently so worthless (e.g., due to
jitter) that even in the above scenario, I would be better off just
letting my network run free for a while, until my Internet connection
and/or GPS signal were restored?

In that case, is there really any reason at all to include SHM(0) as a
refclock, even with "noselect" specified?  Can I simply omit SHM(0) in
my ntp.conf entirely, and include only SHM(1)?  Does the SHM refclock
driver require SHM(0) to be present in the configuration in order for
SHM(1) to work properly?

Rich Wales
richw at richw.org