Re: [chrony-users] HW Timestamping fails with specific source

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 <mlichvar@xxxxxxxxxx>:

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-request@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-request@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxx.org.