| Re: [chrony-users] makestep examples in docs |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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 Fri, 29 Mar 2019, Brendan Simon (eTRIX) wrote:
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?)
If the problem is with the gps or gpsd, then having the system clock closely
track then is disasterous. Chrony is only as good as the time it gets, but
using makestep to force the system clock to closely track a refclock which
jumps around will ensure that your system clock is at least as bad, if not
worse than the refclock. If you put in a flywheel ( forcing the system clock
to slew away errors) will at least mean tha the system clock will diverge from
UTC much more slowly that if you force it to jump to keep up.
It is for this reason that ntp always advocates at least three time sources.
two of them do not have to be highly accurate but they at least keep the
system sane if one of them goes batty.
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.
Sorry, I cannot make any comments on gpsd. I have no idea why it would jump
around. It should not care what the system time is and the gps time signal from the
sattelites should not jump around. What are you using for the gps receiver?
I have had very good service from the Sure test gps receiver but have no idea
if it is still being sold by them.
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
_______________________________________________________________________________________________________________________________