Date: Tue, 15 Oct 2002 22:36:32 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Luigi Rizzo <rizzo@icir.org> Cc: Paul Herman <pherman@frenchfries.net>, Lars Eggert <larse@ISI.EDU>, Steve Francis <steve@expertcity.com>, Kirill Ponomarew <ponomarew@oberon.net>, <freebsd-net@FreeBSD.ORG> Subject: Re: delayed ACK Message-ID: <20021015222156.F21041-100000@patrocles.silby.com> In-Reply-To: <20021015185338.A29388@carp.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021015222156.F21041-100000>