Re: [chrony-users] HW Timestamping fails with specific source

When chronyd opens a socket with kernel RX timestamping and it's the
only socket on the system using timestamping, it takes some time
before the kernel actually starts timestamping received packets. If a
response is received before that, it will only have a daemon timestamp
and that one is bad due to waiting for the transmit timestamp.

Glad you found something, so the problem occurs when the ntp response packet is received before the kernel could initialize the RX timestamping ?

As a workaround, you can enable the NTP server socket, which will keep
the timestamping enabled, e.g. by adding "allow 127.0.0.1" to
chrony.conf.

Works great this way, thanks ! Hardware/Kernel all the time and low peer delay with this workaround.

2018-02-13 15:28 GMT+01:00 Miroslav Lichvar <mlichvar@xxxxxxxxxx>:

On Mon, Feb 12, 2018 at 06:16:02PM +0100, Thibaut BEYLER wrote:
> > Could you please build from git and see if it fixes the issue in your
> > environment?
>
> Thanks ! back from holiday and tested that. Good news is that TX
> timestamping is now always HW, however RX timestamp is Deamon most of the
> time, sometimes Kernel. However, the general performance are worse now :
> the peer delay is jittery and goes very high. Here's the debug log with my
> two sources (slow : 10.214.11.23 , fast : 10.214.16.11 ) the best one
> having the worst perfs : https://pastebin.com/yi0nYNCm

Thanks. I can reproduce the issue now. It's a race condition in the
kernel and it's not related to HW timestamping.

When chronyd opens a socket with kernel RX timestamping and it's the
only socket on the system using timestamping, it takes some time
before the kernel actually starts timestamping received packets. If a
response is received before that, it will only have a daemon timestamp
and that one is bad due to waiting for the transmit timestamp.

I'm not sure yet how to fix it. We could keep a dummy socket open to
permanently enable timestamping in the kernel, or maybe reuse the
cmdmon sockets for this purpose.

As a workaround, you can enable the NTP server socket, which will keep
the timestamping enabled, e.g. by adding "allow 127.0.0.1" to
chrony.conf.

> > Looking at the logs i can also spots some crazy vales getting 2 secondes
> > > peer delay (and thoses are Deamon/Kernel ) .. mixed timestamp ? Will
> > > investigate more tommorow, thanks
> >
> > Do you have a packet capture or chrony debug output showing this?
> >
>
> I could not reproduce that issue today but here's a debug log from 2 weeks
> ago that I saved : https://pastebin.com/LUcYsTNz

Interesting. I don't see anything wrong here. It looks more like an
issue with the network or server, and not the timestamping itself, as
there is a >2s gap between the log messages corresponding to the
transmission and reception.

--
Miroslav Lichvar

--
To unsubscribe email chrony-users-request@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-request@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxx.org.