It's not very clear to me how the setup looks like. The monitoring
software runs on the clients and it uses the same or different NTP
server, or it monitors the clients (operating also as servers) from a
different machine over NTP?
The monitoring software run on another server and monitor the chrony clients (which are operating as servers in that case) over NTP
You mean the update interval (as reported by chronyc tracking) is 60
seconds and the responses are not passing the test C (reported in
chronyc ntpdata)? That's normal if there is a lot of jitter for longer
periods of time. The difference between older versions and 3.0+ is
that the synchronization may be more stable due to SW timestamping or
the correction for asymmetric jitter (reported in chronyc ntpdata) and
it takes longer before chronyd is willing to accept a measurement with
larger delay. You can increase the maxdelaydevratio value if you would
prefer more frequent updates..
Yes indeed, test C is failing pretty quickly
The difference is most likely in SW timestamping which is supported
since 3.0. Before 3.0, chronyd used kernel RX timestamps and daemon TX
timestamps. If the client is using kernel/kernel timestamps with server
which uses kernel/daemon timestamps, or the server has kernel/kernel
timestamps, but the client is not using the interleaved mode, there
will likely be an asymmetry even if the client and server have
identical hardware..
Enabling HW timestamping only on one side will likely improve
stability, but may have a negative effect on accuracy as the
asymmetries are less likely to cancel out
An interesting test would be to enable TX-only HW timestamping with
"rxfilter none" and see how the asymmetry changes.
I did some tests today regarding the timestamp generation, i have a client running chrony 3 with a 3.16 so it is actually till using the good old deamon/kernel (DK) timestamp (at least that's what is printed in ntpdata).
In the end, the offset reported by my monitoring are almost the same wheter i'm using DK , KK , or HK. Only in full HH the reported offset change drasticly
I can notice however that when using DK, KK or HK the reported jitter asymmetry is almost always all the time to +0.50 , with HH it's always 0
Could the asymmetric jitter correction added in chrony 3 produce wrong time in my setup ? Is it possible to disable this in order to test ?
In any case, if you can measure the asymmetry and it's stable, it can
be corrected with the offset option.
Actually after longer period of monitoring i can see it's not stable (at least not with KK or HK), sometime the offset jump by 5, 10 or 20us , stay stable , and then jump again