Re: [chrony-users] chrony losing sync with GPS reference

["Brendan Simon (eTRIX)" <brendan.simon@xxxxxxxxxxxx>]

On 6/12/18 1:08 pm, Bill Unruh wrote:

The 3 hour gap is either loss of GPS signal, or GPS data (e.g. gpsd).  I did see chrony come good when gpsd was
restarted, but I can't recall if it was for this unit/logfile.

Very strange chrony will give up if the offset is too large ( and 10 years is definitely
too large) I cannot remember what the value is.

It is really had to figure out whyin the world you would suddenly have a 10
year offset. Something seriously wrong either with the gps or with gpsd.

I have no idea either.  What would happen if there was some big delay in the Linux system before chrony had a chance to process the NMEA data?  Would offsets get screwed up?

The 1 second offset could be due to the the "offset 0.9999" in the conf file (see below).  I'm not sure why it is
set to this.  Probably from defaults or taken from other sources on the internet.  From memory I've also seen config
settings of "offset of 0.5".

That should be adjusted to the time that it takes the gps unit to send out the
signal. It is certainly less than 1 sec-- and is probably more like .3 sec or
so. You need something else (like a remote ntp server) to tell you what a
reasonable value for the offset is.

Is the offset setting meant to be tuned for each deployed location, or for each device type (using a Quectel L76)? 
All our systems will have the "0.9999" setting.

Usually devices will have some average time delay, but it also depends
crucially on how many NMEA sentences the GPS is asked to send out.The fewer
the better.

Ok.  Assuming I tune the offset (with or without changing NMEA sentences), would that affect the time between to units (with 1 second resolution) if one unit was tuned (e.g. say 0.3 or 0.5)? and the other left at 0.9999 ?

It's important that two units sample at the same time (triggered by PPS signal), and log the same timestamp (with 1 second resolution).  i.e. if the logs are out by 1 (or 2 seconds) on different units, then meaningful system wide calculations are not possible.

      maxupdateskew 100.0

Now that could be problematic. An NMEA source could really be worse than that.
The default is 1000 and I would advise that for an NMEA source.

The default configuration file generated for Debian has this value set to 100, so we just kept it.  Will change it to 1000.

      local stratum 10

You have this there why?

No reason.  Just an oversight.  Will remove it or set to off.

Thanks,
Brendan.