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


Clients have a kernel v4.9.51 so yes it should work (and it works with
other sources)


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

Thanks ! back from holiday and tested that. Good news is that TX
timestamping is now always HW, however RX timestamp is Deamon most of the
time, sometimes Kernel. However, the general performance are worse now :
the peer delay is jittery and goes very high. Here's the debug log with my
two sources (slow :  10.214.11.23 , fast :  10.214.16.11 ) the best one
having the worst perfs : https://pastebin.com/yi0nYNCm


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

I could not reproduce that issue today but here's a debug log from 2 weeks
ago that I saved : https://pastebin.com/LUcYsTNz


2018-02-02 11:48 GMT+01:00 Miroslav Lichvar <mlich...@redhat.com>:

> 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