Date: Tue, 10 Jul 2001 18:30:01 -0700 (PDT) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: freebsd-bugs@FreeBSD.org Subject: Re: conf/28882: Network defaults are absurdly low. Message-ID: <200107110130.f6B1U1r69943@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR conf/28882; it has been noted by GNATS. From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: Leo Bicknell <bicknell@ufp.org> Cc: FreeBSD-gnats-submit@freebsd.org, billf@elvis.mu.org Subject: Re: conf/28882: Network defaults are absurdly low. Date: Tue, 10 Jul 2001 21:21:05 -0400 (EDT) On Tue, 10 Jul 2001, Leo Bicknell wrote: > > Even non-malicious uses can result in very bad behavior, for example any > > one using those defaults on a system which opens any number of sockets > > (for example a http server which could dump large files into the send > > buffer unnecessarily, or an irc server with many thousands of ports) > > could quickly find their machine crashing due to mbuf exaustion. > > This is incorrect. The system will only buffer the current window > size in memory. No, the send buffer will fill to its maximium size if the user process continues to write to it (which it will because write events will be generated). This makes it very dangerous to blindly increase the socket buffers to the numbers necessary to get optimium performance. If your socket buffer is based on the TCP congestion window (the 2x is covered below), this problem would be solved. On the receive side, the amount of memory advertised is also based on the TCP congestion window. This is used to obtain a reading of how much this particular sessions "wants", and is compared against a fixed memory limit (which can be raised on high-memory systems to intelligently improve performance without crashing systems) to determine how much the socket "gets". > I suggest that hard coding large defaults into software, where the > admins don't see them, and can't change them easily is a much worse > problem. 256k is far from practial as well. It's easy to show cross > country paths where a user ftp'ing from a cable modem is rate limited > on say, ftp downlaods. That said, today no application uses 256k > because they don't, in general, code larger sizes with setsockopt, so > they are in fact rate limited to the 16k default, a pathetic number. I wouldn't suggest that either, it's a bad idea to hardcode anything like that into the application. Maybe it would make sense for the ftp client to be easily configurable to increase it's window size, but at any rate that is still a hack. When you change the settings globally there is no distinction between an ftp client and a web server. What will make your ftp client faster for your 5 ftp sessions on a fast 100Mbit link will make other people's web servers with hundreds of clients on dialups keel over at significantly lower loads. This is why the defaults are shipped the way they are. The best solution is to design intelligence into the system, so you are not taking guesses on your client type in order to best optimize performance. > Note, under "real world" conditions you need 2 * bandwidth * delay to > get full bandwidth, which has been well documented by many research > groups. Using that metrics, 16k doesn't even let you get full speed > off a T1, or T1 speed DSL when going to a host across country. I > wonder how many users out there think 80k/sec is a great transfer rate > from a web server just because neither system is tuned to let them get > the 170k/sec they should be able to get. Correct, this is to accommodate maintaining optimum window size through the process of loss recovery (which happens in real world systems). Under conditions with any amount of loss, and depending upon the type of TCP stack you are running, you will probably be better off using multiple TCP sessions to gain higher thruput, even with infinite window sizes. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras 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-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107110130.f6B1U1r69943>