Re: [chrony-users] Tracking lost but server selected

[Ariel Garcia <a.garcia@xxxxxxxxxx>]

> Default maxdistance is 3 seconds and from the logs it doesn't look
> to me like it could be reached in just few hours.

you mean the measurements are too bad to enable selecting a reference
source faster than in several hours?
("maxdistance 3s" roughly means that measurements with RTT > 3s are discarded 
right?)

> Which chrony version are you running?

3.2 downloaded from Github 
(taken from https://github.com/mlichvar/chrony/archive/3.2.tar.gz and then 
compiled in a TPXdist/ARM crosscompiling environment)

> You could increase maxdelaydevratio to make the test C less sensitive.
> A very large value like 1e6 will effectively disable it.
>
> But that will most likely only make the clock less stable. If most of
> the measurements have delay in tenths of a second, it's probably
> better to stick to the rare measurements that have a delay below 0.1s.

ok. Well, i do not necessarily target a very precise clock: 100ms (in)accuracy 
would still be fine.
However, i would like to make sure chrony always considers itself 
"synchronized" unless the sources are unreachable for several days. The device 
will be connecting for short periods every 12h, and if 
	chrony waitsync 1 1 500
fails (= not sync'ed) i'll force a longer connection until synchronization 
happens...

> It's not very clear to me what is going on here. If the issue was with
> sources being "too distant", skew in sourcestats would be the most
> important value. A source which has a large skew will fail the
> maxdistance check faster when its measurements are not accumulated
> (e.g. failing the test C).
> 
> The source 129.69.1.153 was ok at 03:56:36, but at 06:13:08 it
> couldn't remain selected? That's weird.
> 
> Could you please post your config file?

sure, attached.

Thanks!

# ----------------------------------------------------------------------
# chrony configuration
# ----------------------------------------------------------------------

server ntp0.rrze.uni-erlangen.de           offline minpoll 3
server rustime01.rus.uni-stuttgart.de      offline minpoll 3
server ptbtime1.ptb.de                     offline minpoll 3
server time-c-g.nist.gov                   offline minpoll 3

server 99.EE.EEE.EEE          auto_offline offline minpoll 4

# Azure
server 13.AA.AA.AAA                        offline minpoll 2
server 40.BB.BBB.BBB                       offline minpoll 2
server 52.CCC.CCC.CCC                      offline minpoll 2
server 52.DDD.DD.DD                        offline minpoll 2


# Allow the system clock to be stepped in the first two updates if its
# offset is larger than 1 hour.
makestep 3600 2

# Connections are normally made every 12h, start applying drift corrections earlier.
fallbackdrift 13 19

# Do not let the kernel step the clock on leap seconds, slew it.
leapsecmode slew

# RTC: since the board's RTC chip does not have the interrupt line
# wired, the kernel would need to emulate that by polling. Therefore
# monitoring the RTC's drift has a higher overhead with very limited
# gains, since the power off periods are expected to be just reboots.
# Instead, let the kernel sync from the system clock every 11m.
rtcdevice /dev/rtc
rtconutc
rtcsync

# Driftfile for the system clock.
driftfile /var/lib/chrony/sysclock.drift

# Chrony daemon pidfile.
pidfile /run/chrony/chronyd.pid

# Save the servers' measurement history on exit.
dumpdir /var/lib/chrony/history
dumponexit

log measurements statistics tracking rtc
logdir /var/log/chrony

# Log a message to syslog when chronyd has to correct an error above
# the given number of seconds.
logchange 0.1

# Drop privileges after start.
user chrony

# Allow command access only from localhost.
cmdallow 127.0.0.1
bindcmdaddress /run/chrony/chronyd.sock