hadn't got there yet
likely using NTPsec, as the codebase is available if a driver or generic
driver won't work
https://docs.ntpsec.org/latest/driver_howto.html

On 01/11/2017 12:38 PM, Chris Caudle wrote:

On Wed, November 1, 2017 3:17 pm, MLewis wrote:

Your RTC is not likely to be tightly synchronized to NTP time, so there is
a high probability that trying to use RTC as a secondary time source will
actually make the system worse than just riding through using the NTP
estimate of the current system clock frequency.  If ntpd will even use it
as a secondary clock, and not reject it because it is too far off from the
preferred GPS source.

Is this system not connected to other NTP servers over the network?
NTPsec does not work very well in the case of only one GPS device
available to set time, that is documented as one of the use cases which
NTPsec does not currently handle well.  If there are no other servers
available for comparison you will probably want to use chrony.  If there
are other servers available then trying to switch over to the RTC will
definitely make your ntp server perform worse than just leaving well
enough alone.

--
Chris C

This GPS/Pi server, with possibly a second copy, are intended to be the
sole NTP sources for a local network. No going out to the internet.

My intent was to discipline the RTC, so it's current when needed. If I
had to do a cold boot without GPS available, I'd want the RTC to be current.

I hadn't considered  'just riding through using the NTP estimate of the
current system clock frequency', having assumed that a disciplined RTC
would be a better source.

Hadn't heard about that issue with NTPsec.

I haven't looked at chrony. Something else to read tonight.

Thanks,

Michael

On 01/11/2017 4:57 PM, Chris Caudle wrote: