Re: excessive TCP duplicate acks?

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.  

Are you using a FreeBSD receiver?  Both Linux and MacOSX ack far, far
less often than we do.  Maybe a FreeBSD receiver acks too quickly
for you to see the bug?

Drew