|Re: [chrony-users] Fallback clock on event "Can't synchronise: no reachable sources"|
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]
Thanks for the answer!
Based on that I will get the tracking statistics and go through the syslog again and write again to this list when I have that.
On 07.02.2014 15:37, Miroslav Lichvar wrote:
It was reported in /var/log/syslog. The effects of the dropout were indirectly noticeable, because I have some other software running that is monitoring timestamps of messages sent via a middleware. These timeout thresholds are configured to raise errors for timestamp deviations larger than 100ms.On Fri, Feb 07, 2014 at 02:10:32PM +0100, Ulrich Schwesinger wrote:I have a system with a write protected system partition and an NTP server running within a local network. Sporadically, chrony reports the above mentioned error. The error persists maybe within a time range of 20-30 seconds. Within that time interval, the system time seems to diverge/drift by a couple of 10 milliseconds, which seems unreasonable large for me.How did you measure the error in that period?
No, fallbackdrift is not configured. The configuration looks like this (ntp-server-lan is specified in /etc/hosts, two WAN servers exist but when the error happens, no WAN access exists):(a) What is chrony exactly doing upon the event "Can't synchronise: no reachable sources". It does not seem to keep the current system time. Is it falling back on hardware clock maybe?No, nothing with RTC. It should keep the system clock as it was set on the last update unless chronyd is configured with the fallbackdrift option.
server ntp.favey.ch minpoll 8
server swisstime.ethz.ch minpoll 8
server ntp-server-lan minpoll 5 maxpoll 7 iburst
log tracking measurements statistics
initstepslew 10 ntp.favey.ch vcharge-ntp-server-lan
makestep 100 10
Puh, unfortunately I don't have the log files here right now. But I don't believe it was the case.(b) Or might something be wrong with the drift estimate, causing this large divergence during the short time intervalDid it switch to another source before the "no reachable sources" message? If there are multiple sources and the worst source becomes unreachable as last, the clock will be set by the measurement from the worst source, possibly introducing a large time or frequency error.
As one can see from the chrony.conf, there are additionally two WAN sources (that are never reachable).
Interesting information though.
Great, I will collect these files the next time. The should be created.(c) Are there some files I could look at the trace back what's happening within these time intervals?The tracking log would be very helpful here. You can enable logging in chrony.conf like this: logdir /var/log/chrony log measurements statistics tracking
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|