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

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
does not).

Could you please build from git and see if it fixes the issue in your
environment?

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

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