On Wed, Feb 14, 2018 at 11:26:13AM +0100, Thibaut BEYLER wrote:
> > 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 ?
Yes. When chronyd is polling a server, it opens a socket, enables
timestamping and few other options on the socket, and sends a request.
The kernel has a global counter for sockets using timestamping, but it
is not updated synchronously with that setting on the socket (for
performance reasons I assume). If chronyd is the only application
using timestamping and it doesn't have the server socket open, its
client socket will be the one which turns the kernel timestamping on
> Works great this way, thanks ! Hardware/Kernel all the time and low peer
> delay with this workaround.
I'll probably push a fix which will keep one socket open all the time
just for the timestamping.
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.