Re: [chrony-users] Trying to understand what "testC" does

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

(replying from an archive)

On Thu, 27 Feb 2020, Abhijith Sethuraj wrote:
> We seem to notice in our chrony-based time infrastructure that
> whenever we fail over to a backup network link (having higher
> latency), over time chronyd stops accepting return packets from the
> preferred time server. `chronyc ntpdata` says that we're failing
> testC for the preferred source. We started noticing this as the
> LastRx field in `chronyc sources` was in the order of ~100 minutes.
> I have enabled debugging by starting chronyd with `-dd` and I do see
> debug messages from inside the check_delay_dev_ratio() function, but
> it's sort of difficult to understand what those metrics mean and to
> interpret the debug messages.

It's expected that the test C will fail when the network delay
suddenly increases (e.g. due to a different network path). chronyd
doesn't know the real reason and assumes the link is congested. It
waits for the delay to become small again to avoid using inaccurate
measurements and gives up only when the estimated drift of the clock
is comparable to the expected error in the measurement.

You can set maxdelaydevratio for the source to a very large value
(e.g. 1e9) to effectively disable the test C. You can also increase
the maxclockerror to make the test C succeed sooner after the network
switch. Another possibility, if you can detect when the network link
was switched, is to restart chronyd to forget the shorter delay.

-- 
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.