From owner-freebsd-current@FreeBSD.ORG Sat Mar 3 21:38:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 727AE16A401; Sat, 3 Mar 2007 21:38:25 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 36F8B13C481; Sat, 3 Mar 2007 21:38:25 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l23LcO1N009409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Mar 2007 16:38:24 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l23LcJ92052247; Sat, 3 Mar 2007 16:38:19 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17897.60107.576150.627357@grasshopper.cs.duke.edu> Date: Sat, 3 Mar 2007 16:38:19 -0500 (EST) To: Andre Oppermann 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> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Peter Jeremy , freebsd-current@freebsd.org Subject: Re: excessive TCP duplicate acks? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2007 21:38:25 -0000 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