[chrony-users] Re: Tracking behavior

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


 With the new configuration, minsamples = 64 and poll = 6, I observe NP = 64 and NR = 3 in the sourcestats output. Is that fine? Chrony reported at least once already "no reachable sources". But at that time, I had just changed the configuration. After restarting chrony, it now runs for around 24 hours like this (NR=3), sync'ed to the GPS.


Am Freitag, 26. September 2014 schrieb Dominik Auras :

Thanks for the answer. You are right, I guessed that it sometimes discards all samples and had set minsamples to 16. Before, chrony sometimes completely ignored the GPS, despite a GPS lock. Good that you confirm that!

I'll use your settings. Thanks. I also plan to use a new GPS with PPS in the future. It's good to rule out that it's not due to an incorrect configuration, though.

BR, Dominik 

Am Freitag, 26. September 2014 schrieb Miroslav Lichvar :
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.

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