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 [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
