Date: Sun, 18 Jun 2000 13:40:36 -0700 From: David Greenman <dg@root.com> To: "Richard A. Steenbergen" <ras@e-gerbil.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers Message-ID: <200006182040.NAA15590@implode.root.com> In-Reply-To: Your message of "Sun, 18 Jun 2000 16:13:06 EDT." <Pine.BSF.4.21.0006181540070.95120-100000@pkitty.e-gerbil.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Sun, 18 Jun 2000, David Greenman wrote: > >> >IDEA: >> > >> >Which leads to my idea. Automatically scale the socket buffer when the TCP >> >window is exausted and the reason it cannot be extended is the sockbuf. >> >This would allow the default recvspace/sendspace to be set to something >> >like 4k, but still allow performance sockets to quickly scale upwards to a >> >set limit, to achieve maximium thruput. >> >> This idea sounds familiar and I think it has been suggested before. It >> does seem like a good idea. One concern that I have is the case of a saturated >> local (ethernet) circuit, causing the delay to increase due to buffering >> in the network device driver and perhaps in the nearby upstream switches. >> Since the problem is lack of bandwidth that is causing the delay to increase, >> it seems that the new algorithm would behave badly - increasing the socket >> buffer space on all connections needlessly. In other words, it might be a bad >> assumption that delay is caused by speed of light lag when it might instead be >> caused by network congestion which isn't helped by increasing the amount of >> buffering. > >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. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. 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?200006182040.NAA15590>