excessive TCP duplicate acks?
Andre Oppermann
andre at freebsd.org
Sat Mar 3 22:51:05 UTC 2007
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.
> 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?
I'll try reproduce the bug against OSX.
--
Andre
More information about the freebsd-current
mailing list