Re: excessive TCP duplicate acks?

Andre Oppermann wrote:
> Andrew Gallatin wrote:
>> Andre Oppermann writes:
>>  > This thing is really strange and difficult to debug.  A look at the 
>> CVS history
>>  > of tcp_input/output doesn't show any smoking gun.  ACKs like these 
>> are totally
>>  > pointless.  There are three places able to cause ACKs: 1) tcp_input 
>> decides to
>>  > call tcp_output [not the case here as there are no corresponding 
>> input packets
>>  > to cause this]; 2) tcp_output has a unterminated loop somewhere 
>> causing it to
>>  > spew the ACKs in rapid succession [unlikely as it holds the tcpcb 
>> lock and that
>>  > would block inbound packets]; 3) tcp timers are misfiring or not 
>> properly dis-
>>  > armed [here the logic in tcp_output may/should just ignore it and 
>> return w/o
>>  > sending any packet].
>>
>> When I was taking traces a few weeks ago,  I remember having the
>> impression that the acks would start happening when the FreeBSD
>> sender didn't have enough space in the window to send any more
>> data, and would seemingly continue until the (Linux|Macosx)
>> receiver sent an ack which updated the window and allowed
>> the FreeBSD sender to send more data.  
> 
> Ok, that's an ambulance worth chasing.  Lets see if it leads us to an
> accident.

Nope.  A visual inspection of tcp_output(), TF_ACKNOW handling didn't
yield a trail to follow further.  The tcpdump by Peter also doesn't
support that theory as no windows get exhausted.  A casual inspection
of tcp timer handling also doesn't support the refiring timer thesis.

There is no other way than to instrument the code.  In your test bed
it is fairly easy to reproduce, is it?

-- 
Andre