From owner-freebsd-questions@FreeBSD.ORG Sat Mar 25 21:25:15 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3702116A401 for ; Sat, 25 Mar 2006 21:25:15 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC6243D45 for ; Sat, 25 Mar 2006 21:25:14 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from localhost (monrovll-cuda1-24-53-250-148.pittpa.adelphia.net [24.53.250.148]) (AUTH: LOGIN wmoran, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Sat, 25 Mar 2006 16:25:13 -0500 id 00056407.4425B539.00001023 Date: Sat, 25 Mar 2006 16:25:12 -0500 From: Bill Moran To: RW Message-Id: <20060325162512.3ae2a4c5.wmoran@collaborativefusion.com> In-Reply-To: <200603250237.31122.list-freebsd-2004@morbius.sent.com> References: <200603250209.10994.list-freebsd-2004@morbius.sent.com> <200603250237.31122.list-freebsd-2004@morbius.sent.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: TCP delayed acks not being delayed? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2006 21:25:15 -0000 RW wrote: > On Saturday 25 March 2006 02:09, RW wrote: > > I have a 1MB/0.25Mb ADSL connection and have an IPFW rule to prioritize > > outgoing empty acks. If I download a single file with kget at 100 kbytes/s, > > I see that the rule gets hit at a rate of 50/s: ie a little under 1 > > empty-ack per incoming packet. > > > > I have: > > > > net.inet.tcp.delacktime: 100 > > net.inet.tcp.delayed_ack: 1 > > > > which I thought should limit each TCP connection to <=10 empty acks per > > second Are you sure you're not exceeding the capability of the system to delay acks? If the receive window drops to 0, the receiving machine _has_ to send an ack, or the data transfer will stall and your performance will suck. It's not terribly difficult to imagine receive buffer vs. transmissions speed combinations that would force it to send empty acks. You might want to use ethereal or tcpdump to analyze the window sizes on your data transmission. I'm guessing that zero sized windows are forcing the acks to be sent. Besides, when you're transferring data in one direction only, it doesn't make sense to delay empty acks. only on a full-duplex transmissions do you get a benefit by taking measures to ensure that all packets have data. When you're downloading, _all_ your acks are empty, so who cares? Additionally, if the client application turns nagle off, this will disable the use of delayed acks. For things like file transfer, it's pretty much typical practice to disable nagle, as it generally doesn't help performance, and occasionally hurts it. -- Bill Moran Potential Technologies http://www.potentialtech.com