From owner-freebsd-net Tue Oct 15 20:31:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF3DA37B401 for ; Tue, 15 Oct 2002 20:31:47 -0700 (PDT) Received: from out5.mx.nwbl.wi.voyager.net (out5.mx.nwbl.wi.voyager.net [169.207.3.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4370043E91 for ; Tue, 15 Oct 2002 20:31:47 -0700 (PDT) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d163.as28.nwbl0.wi.voyager.net [169.207.71.229]) by out5.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id E596DC6D1A; Tue, 15 Oct 2002 22:31:44 -0500 (CDT) Date: Tue, 15 Oct 2002 22:36:32 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: Paul Herman , Lars Eggert , Steve Francis , Kirill Ponomarew , Subject: Re: delayed ACK In-Reply-To: <20021015185338.A29388@carp.icir.org> Message-ID: <20021015222156.F21041-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 15 Oct 2002, Luigi Rizzo wrote: > On Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote: > ... > > NetBSD introduced a "fix" for this recently, it seems sorta hackish, but > > maybe we need to do something similar. > > this helps you if the other side has delayed acks, but halves the > throughput if you are being window limited and the other side does not > use delayed acks (can you force immediate acks by setting the PUSH flag > in the tcp header ?) > > cheers > luigi I think the comment is slightly misleading, and that it won't actually cause any performance problems as you suggest. From what I recall, immediate acking of PUSH packets varies... Linux appears to have changed back and forth on whether it does so or not. I also seem to recall Windows making a change too. Either way, we probably shouldn't rely on that behavior alone. > > Never send more than half a socket buffer of data. This insures that > > we can always keep 2 packets on the wire, no matter what SO_SNDBUF is, > > and therefore ACKs will never be delayed unless we run out of data to > > transmit. The problem is quite easy to tickle when the MTU of the > > outgoing interface is larger than the socket buffer size (e.g. loopback). If I'm reading the implementation correctly, what this means is that if you have a single packet > .5*socketbuffer, you reduce the maximum *segment* size, causing two smaller packets to be sent instead of one large packet. (Smaller still being 8K in size.) While such a change might help with localhost, I have this sneaky suspicion that it falls apart when applied to jumbo frames and 32K send buffers. Someone well motivated should be able to come up with a more general heuristic. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message