On Mon, Jan 29, 2018 at 07:21:30PM +0100, Thibaut BEYLER wrote:
> However, in my case 98% of he requests are Deamon/Deamon, so most of them
> pasts all the tests (generally those below 60us) which is bad for time
Hm, with recent kernels and drivers that support SW timestamping the
timestamps should always be at least kernel/kernel. What kernel
version do the clients have?
I've tried a few different approaches to wait for the late HW
timestamp and pushed one that I'm quite happy with. It is specific to
the Linux timestamping code and should have a minimal impact in the
usual case when the timestamps are not late (mostly limited to a
configuration with one interface that has HW timestamping, but another
Could you please build from git and see if it fixes the issue in your
> 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?
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.