On Mon, Nov 14, 2016 at 08:59:17PM -0800, Denny Page wrote:
> I tested with a usleep(100) following the sendmsg() call. This didn’t appear
> to have any impact. Was the usleep() intended to influence the order of
> timestamp vs. server response messages?
Yes, that was the idea. Could you try inc
This is an automated email from git. It was generated because a ref
change was pushed to the "chrony/chrony.git" repository.
The branch, master has been updated
via 875b0e262c6b472766081b1ab9cc0ecabd460305 (commit)
via 8823e2b064c2e71a3b93f1086dc39c6a50b44a29 (commit)
via 5
On Mon, Nov 14, 2016 at 03:40:32PM +0100, Miroslav Lichvar wrote:
> On Sat, Nov 12, 2016 at 10:36:55AM -0800, Denny Page wrote:
> > Here is a reasonable visual representation of what I am seeing. The section
> > on the left (before 8:00) is with hardware timestamping, while the section
> > on the
The chip is actually a I354, which is slightly different than the I350, but I
don’t think it matters much. I also have interfaces with I211 chips, and the
ordering issue appears to happen there as well. I don’t think the sleep after
the send is going to affect the order of the timestamp and resp
With the latest drop in the repo, I’m still seeing the wild spikes in the
standard deviation with hardware time stamping against the fast responding
hardare units. I'm also still seeing a better base deviation using software
timestamps against them as well.
I do see better results with hardware
Miroslav,
There is an additional issue, which is perhaps unrelated to the other issues
discussed.
Background: Each target IP is a hardware based NTP server. IPs 240 and 244 are
across the switch. Chrony is synchronizing with these two IPs. Incremental
latency from the switch is approximately ~
