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

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

I selected the last part of the refclocks.log.1 file.  The proceeding lines looked uninteresting (to me).

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.

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".

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.

Initially NTP servers were being used, but we found that chrony could stop tracking them (and never every try them again).  We figured moving to GPS would be more reliable (especially if our celluar internet connection was flaky or down temporarily).

Here is the `chrony.conf` file (with the comments removed)

makestep 1 -1

refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2

keyfile /etc/chrony/chrony.keys

commandkey 1

driftfile /var/lib/chrony/chrony.drift

log measurements statistics tracking rtc refclocks tempcomp

logdir /var/log/chrony

maxupdateskew 100.0

dumponexit

dumpdir /var/lib/chrony

local stratum 10

logchange 0.5

rtconutc

Thanks,
Brendan.

---

On 6/12/18 1:30 am, Bill Unruh wrote:

As Miroslav says, it would help to see the chrony.conf file as well. It is
bizarre that it sits there with a 1 second offset without trying to reduce it.
What is the 3 hr gap in the data? Did you select output or was this a
contiguous part of the data? offset sits there reliably at 1 second with no
hint that the system is trying to fix it.(mind you this is only a 10 sec piece
of data) Then there is suddenly a 10 year jump in the offset. It looks to me
like your GPS is unit is toasted since there is no indication in the actuall
system time that anything strange has happened. Ie, either gpsd or the gps
unit itself is misbehaving badly.


William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Tue, 4 Dec 2018, Bill Unruh wrote:

On Wed, 5 Dec 2018, Brendan Simon (eTRIX) wrote:

I'm running Debian Linux (Jessie based with a few backport packages) on some embedded systems that use a GPS
receiver to set the system clock.

The problem I have seen is that the chrony loses sync with the GPS reference after some time, and the system clock
starts to drift and never recovers.  This is disastrous as I need to have the clocks synchronised.

gpsd was restarted and then chrony started synchronising the system clock again.

gpsd is 3.16 (jessie-backports) and chrony is 1.30 (jessie)

I think more information is needed. Make sure that the "refclocks" logs are
enabled, and look at them when the clock loses sync to see what is happening.
Are you using PPS or just the UTC time stamos from theGPS?
.

Is there anything in chrony 1.30 that could be known to cause this loss of sync with no recovery ever?

Is there anything in gpsd 3.16 that could be known to cause this loss of sync with no recovery ever?

I'm looking at moving to Debian Buster (still in Testing but to be released early 2019).  It has gpsd 3.17 (but
hopefully might move to 3.18 before release) and chrony 3.4.

Does anyone know if this latter combination of gpsd/chrony is likely to solve the issues/symptoms described above?

gpsd changelog isn't too informative with fixes.  I see the following:

3.18: Fix several buffer issues.
      Too many other bug fixes and improvements to mention.

3.17: Fix a SiRF driver bug that occasionally confused NTP.

Thanks,
Brendan.