| [chrony-users] Re: Tracking behavior |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: "chrony-users@xxxxxxxxxxxxxxxxxxxx" <chrony-users@xxxxxxxxxxxxxxxxxxxx>
- Subject: [chrony-users] Re: Tracking behavior
- From: Dominik Auras <wohnung.elisabethstrasse@xxxxxxxxx>
- Date: Fri, 26 Sep 2014 18:04:04 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7VnobcXE/myQfrALTWue3bSJZGbW6xXSrUURWusvurs=; b=doE7VDfkm4DTd9IEEkAWzKHLUmB1sFrikwKmKhBdWuUX/r6td6ZfiVltiuVNlGCg3O RTzkOlUHKZ9imJCESQpqZDSbYYkdcTQF1mpyxv/tfSgw5/CKHle4ASFgCI29MIcjCHUn 52I+1Fj69jpUbqMNwpB7fI0Z2+zs3P9j+jktvKZ+5Aqgb5+/pznP/EUBb9lxuwTaS3au x7V9Y3NJEJjKS4gYB1HqWc5dHSVws+a1AtHR6wih+4xsygxebY86ZHwXH6HPporJdQDm L0wkmcwt3xn4/YyR+J6SfMoSCXPq6m9bayu8qEYQWUckThT4v99Ss0AdJjpQBCS5fAIm 3ghw==
Hi,
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.