Re: [chrony-users] makestep examples in docs

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


On 29/3/19 12:58 pm, Bill Unruh wrote:
On Fri, 29 Mar 2019, Brendan Simon (eTRIX) wrote:
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.
I figured the purpose of the `3` limit in makestep, would help to not make large jumps on gps errors (after the initial step period),
but I guess it wont help from slowly skewing.

I'm banking on GPS or gpsd recovering - that may or may not happen.

I guess what I really want is to only step (or make large adjustments) in the early gps updates,
then when chrony has enough data to ascertain an accurate time, stop making any large adjustments.
i.e. ignore GPS readings that are obviously wrong from recent readings.

Not sure what to do if the GPS data is consistently wrong for a large period of time.

Currently I am putting in some supervisory scripts to watch for when chronyc sources shows loss of GPS sync,
and reboot the system.

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.
Fair enough.

What do stratum 0 or 1 servers do?  Do they have multiple sources?

I have seen bugs in gpsd cause problems with chrony in the past.
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 assume bugs with buffers, formatting data, etc ??

Quectel L76

Brendan.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/