Problem with GPSD refclock

[Gary E. Miller]

Yo Rich!

On Sat, 28 Jan 2017 23:26:34 -0800
Rich Wales <richw at richw.org> wrote:

> Gary E. Miller wrote:
> 
> > Yes, probaably minor annoyances, but why not do it the best
> > possible? Just a config change.  
> 
> So, if I understand you right, then instead of using the GPSD driver
> in mode 1 (which gives me either PPS-synced time info or else
> nothing),  I would be better off using the SHM driver -- which will
> give me both PPS-synced time info (if my GPS has a good signal and is
> supplying PPS),

Yes.  The part you missed is that the algorithm in ntpd for when to
reject PPS is not as good as the one in gpsd.  So there are times
when the JSON driver will accept a bad PPS that the SHM driver will not.

> and also non-PPS-synced info (which I should fudge
> with an empirically chosen time1 calibration value in order to be
> reasonably close most of the time).  Right?

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

Also, there is added latency in the JSON driver, but that effect is small.

> And if I do this, should I set the non-PPS refclock (unit 0) to use a
> high stratum value, in order to discourage use of unit 0 if anything
> else (such as an external NTP server) is available?

Many ways to do that.  No consensus on the best way.  I just use a high
fudge.

But if what you have now is good enough for you, no reason to do 
excessive optimizaation.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20170129/23ab3987/attachment.bin>