| Re: [chrony-users] makestep examples in docs |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Fri, 29 Mar 2019, Brendan Simon (eTRIX) wrote:
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.
Yes, that is correct. The slewing isn't all that slow (something like 1
sec/100sec)
I'm banking on GPS or gpsd recovering - that may or may not happen.
That is why it is important to figure out what is going wrong. It should not
have such large deviations.
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?
Usually yes (well stratum zero is the source itself-- like a GPS transmitter)
But most stratum x have other say stratum 1 receivers as backup. It is better
to allow the accuracy to become slightly worse than to have such a huge jump.
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.