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
and off.

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

Great.

I'll probably push a fix which will keep one socket open all the time
just for the timestamping.

-- 
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.

Reply via email to