I would not have expected this, and I haven’t dug into it, but looking at the 
time to generate timestamps for pcap, I am seeing times of more than a 
second(!). I am wondering what happens if we get to the point of sending the 
next request before we have received the transmit timestamp for the prior one. 
Given the speed of the units I’m testing with, it appears to be possible to 
have received the second response before the first transmit timestamp.

Have you tested against a fast server with "minpoll 0 max poll 0”? 

Just a thought.


> On Nov 18, 2016, at 06:37, Miroslav Lichvar <mlich...@redhat.com> wrote:
> On Thu, Nov 17, 2016 at 05:44:23PM -0800, Denny Page wrote:
>> Although reduced, I’m still seeing spikes with the patch below.
> I'm not sure what could be wrong at this point. Maybe it really is a
> kernel or HW issue. I'm wondering what would be the best way to
> confirm or reject that idea.

To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to