Date: Sat, 3 Mar 2007 16:38:19 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Andre Oppermann <andre@freebsd.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-current@freebsd.org Subject: Re: excessive TCP duplicate acks? Message-ID: <17897.60107.576150.627357@grasshopper.cs.duke.edu> In-Reply-To: <45E99060.3030404@freebsd.org> References: <17850.13146.266196.499166@grasshopper.cs.duke.edu> <20070303000125.GA9918@turion.vk2pj.dyndns.org> <45E99060.3030404@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17897.60107.576150.627357>