> > 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 2017-08-29 19:09 GMT+02:00 Miroslav Lichvar <mlich...@redhat.com>: > On Tue, Aug 29, 2017 at 06:29:18PM +0200, Thibaut BEYLER wrote: > > My setup is pretty simple, linux boxes, one switch between everything. > For > > my tests I am also using a third-party software as monitoring, connected > > via PTP and PPS on my timeservers, which does ntp polling (with hw > > timestamping) every second on the different clients and graph the > offsets. > > 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? > > > Another behaviour i noticed on version 3+ with kernel timestamping is > that > > for some server i can have very long poll time (60 seconds) even if i > > configured minpoll and maxpoll to shorter interval (0 & 1) > > 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. > > > I tried version 2.4.1 and there are no such problem, so I assume it > starts > > with version 3.0. I just tested the chrony 3.2-pre2 and the problem is > > still there. > > > > Any idea where this could come from ? > > 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. > > In any case, if you can measure the asymmetry and it's stable, it can > be corrected with the offset option. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
