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 [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
