| Re: [chrony-users] Tracking behavior |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Thu, Sep 25, 2014 at 06:56:04PM +0200, Dominik Auras wrote:
> Freq. and skew are constant, the offset varies. At 13:55:07, the offset is
> larger then 0.5s. Chrony announces this to rsyslog and starts correcting it.
>
> Sep 24 15:55:07 raspberrypi chronyd[19616]: System clock wrong by -0.530372
> seconds, adjustment started
>
> How can I interpret this? Did the GPS loose the signal, maybe? Why are
> freq. and skew constant, while the offset varies?
The lines where the frequency and skew didn't change were updates with
skew that was larger than maxupdateskew (1000 ppm by default). The
tracking frequency and skew were not updated and chronyd was waiting for
a better update.
This can happen when the jitter is extremely large and the offset is
not distributed randomly, so chronyd is trying to follow the
short-term changes assuming the local clock is unstable, it drop too
many samples and the frequency estimate has a large error. This is a
common problem with NMEA sources.
It seems you suspected this was happening as your config sets the
minsamples option. My suggestion would be to increase the value of the
option even more (perhaps to the maximum - 64) and also increase poll
for the refclock to 6 or more. This should force chronyd to always use
a long interval (64 * 64 seconds) and the frequency should be much
more stable.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.