Re: [chrony-users] makestep examples in docs

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

I have a number of data loggers spread out geographically, and it's crucial that the data they log is time syncrhonised.

I have observed occasionally that some of the loggers system time will jump into the future, triggered by chrony.  This generally happens after they have been up for quite a while, so I was thinking that limiting maxstep to first 3 updates is enough to set the clock correctly at startup, and then only do skewing adjustments after that.

gpsd is feeding chrony, using SHM0.  I haven't been able to get SHM1 or SOCK interfaces to work, but SHM0 is good enough for what we need.

I'd prefer to use SOCK interface, so I might revisit that again in the near future.

I have all logging turned on - statistics, tracking, rtc, refclocks, tempcomp

I suspect either the GPS device or gpsd.  I'm trying to gather some raw NMEA data logging to see what is happening on the next occurrence of this problem.  Was thinking that a script running `gpscat` might be the way to go (unless `gpsd` has some kind of NMEA logging feature already?)

I have seen bugs in gpsd cause problems with chrony in the past.  In particular gpsd v3.11 (Debian jessie) was causing system time to jump backwards and forwards on startup until it eventually synchronised.  Installing gpsd v3.16 (Debian jessie-backports) solved that issue.

I have now moved to Debian buster which uses gpsd v3.17.  I also noticed that gpsd v3.18 has been released and mentions many bug fixes and improvements to regression tests.  I'd like to use that but there is only an package available in Debian experimental and I don't know if it will play nicely with other parts of the buster distro.

Thanks,
Brendan.

---

On 29/3/19 10:56 am, Bill Unruh wrote:

It depends on what you want, and on how reliable your GPS receiver really is.
It might be great, or it might have glitches.

The first thing to do is to understand what was happening with your glitches.
Is it the gps or something else (eg some program on yuour machine which is
resetting the system clock). Make sure you have your logs operating
(especially the refclock, and the tracking logs). When you get one of those glitches, look in the refclock log if it was the gps
or your computer (look at the dates on the log lines which are obtained from
the system clock, and the offsets on the gps receipts. If you find that your system clock suddenly say it is Oct 15 2023. Also look
at the tracking around the same time.

How are you getting the gps time to chrony? Using gpsd? Using shm with some
other gps reading software, etc. Clearly using makestep will make things worse
if it is the gps reading that is the problem. On the other hand, if some other
program is messing with your system clock, then using makestep might well be
the right thing to do  (assuming you cannot get that other program to behave
itself).

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273

On Fri, 29 Mar 2019, Brendan Simon (eTRIX) wrote:

I am using a GPS reference clock with chrony (on a Debian 8 Jessie system). 
Occasionally  the system time jumps way into the future and can screw up applications
that are sleeping or waiting based on wall system time.

I have been using `maxstep 1 -1`, assuming that the GPS time is always correct and steps
should always be made if out by more than 1 second.

That might be too extreme, so I want to only step in the first few updates, as suggested
by the docs.

The docs suggest `maxstep 0.1 3`, which would step if the error is greater than 100ms
for the first 3 (or updates).

That sounds ok, but every other example of `makestep` int the docs uses `maxstep 1.0 3`
(i.e. 1 second, not 100ms).  So is the 0.1 example a typo or is it intended.

In summary, would it be recommended to use `makestep 0.1 3` or `makestep 1.0 3` when
using chrony with GPS source (btw, it's the only source.  no ntp servers are used).

You could use either one. clearly the .1 will keep your system closer to the
GPS time. If the GPS time is wrong, then that is clearly not helpful.

Thanks, Brendan.

--

---

eTRIX Services
PO Box 497, Inverloch, VIC 3996, AUSTRALIA.
(m) 0417-380-984

---