Re: [chrony-users] Time offset on versions 3+ without hw timestamping

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

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-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.