> > 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 <mlich...@redhat.com>: > 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-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. > >
