Date: Mon, 19 Jun 2000 00:28:04 -0400 (EDT) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: David Greenman <dg@root.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers Message-ID: <Pine.BSF.4.21.0006182204020.41098-100000@overlord.e-gerbil.net> In-Reply-To: <200006182040.NAA15590@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Jun 2000, David Greenman wrote: > >This could affect our transmitions, and thus the send buffer, but not the > >recv buffer. if you've received so much data that you've maxed your socket > >buffer and are sending a window of 0 on your ACKs, you're confident that > >its not a lack of bandwidth but rather a lack of buffer space -- This can > >all be determined locally. In reality the recv buffer is the one we're > >concerned with anyways, as it would have to be the other side adjusting > >its recv buffer for our uploads to show any performance increases. > > FreeBSD rarely sends a window of 0. It usually only happens when the > machine is so overloaded that it can't keep up with the input stream. I do > agree, however, that advertising a larger receive window is needed in order > for the transmitter to fill up a long pipe. The thing is that a dynamic > adjustment that is based on a filled-up receiver isn't going to work for > that. Of course it also 'takes two to tango', so not also increasing the > transmitter socket buffer would defeat a larger receive buffer even if > you could find a good algorithm for dynamically increasing the receive > side socket space. But you still know if you are receiving enough of an input stream to open up the window. Infact you know this part already, its simply a matter of extending it to opening up the socket buffer as well. As for the "two to tango", I'm trying to find the code related to this. It makes logical sense that you would need to have a socket buffer sufficient to store all the in-flight packets if you were called upon to do a retransmit, regardless of the window being advertised by the receiver, but the test numbers don't seem to match up with this (I get significantly reduced performance at 4k but equal performance with sendspace of 16k or 256k). At any rate, scaling the send buffer can only increase the potential for performance, not the congestion/buffering, as this is handled entirely by the TCP windows, which will shrink upon congestion. We're just talking about expanding the POTENTIAL for TCP windows to expand as needed by increasing socket buffers in a sensable fashion. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) 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?Pine.BSF.4.21.0006182204020.41098-100000>