Date: Tue, 10 Jul 2001 19:00:04 -0700 (PDT) From: Leo Bicknell <bicknell@ufp.org> To: freebsd-bugs@FreeBSD.org Subject: Re: conf/28882: Network defaults are absurdly low. Message-ID: <200107110200.f6B204x72602@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: Leo Bicknell <bicknell@ufp.org> To: "Richard A. Steenbergen" <ras@e-gerbil.net> Cc: Leo Bicknell <bicknell@ufp.org>, FreeBSD-gnats-submit@freebsd.org, billf@elvis.mu.org Subject: Re: conf/28882: Network defaults are absurdly low. Date: Tue, 10 Jul 2001 21:57:45 -0400 On Tue, Jul 10, 2001 at 09:21:05PM -0400, Richard A. Steenbergen wrote: > 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. This doesn't hold true, at least by vmstat's output. I created a 30 meg file. And had 25 clients try to connect from a dial-up host with the modifications as well. With a 4 Meg max limit, one would expect 100 Meg of additional kernel memory usage. However, vmstat reported only minor kernel increases, and no signficant change in available memory. The system was fine, and a 26th client could connect from acrouss country and get 8 MBytes/sec on a single transfer. MBuff usage, per netstat -M went up by about 150 (for the 25 clients), which seems reasonable. Without spending hours looking at the source I can't say my explantion is correct, but the result you suggest doesn't happen either. I have infact used my (admittedly large) values on some busy web servers and noticed no significant memory usage increases, or other performance degredataion. There is no reason for the kernel to unblock a process until it's ready to send data. The kernel does not buffer data from a process to the kernel, it simply must save the outgoing cwin until there is an ack. I can see no way the kernel would let a process send data with a full cwin, or when there are no available network resources. > 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. Ick, it can't be per client. Users will never remember "hey, that's a good host, up the value", it will make it into an alias for users who care (with the maximum setting) instantly. > 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. Again, I'm not seeing this on moderately loaded web servers (5-10 connections/sec peak usage), in fact I'm seeing no major changes, and can now (where network and remote host allow) get much faster transfers. Note that according to http://www.psc.edu/networking/perf_tune.html FreeBSD has smaller defaults than Digital Unix, HP-UX, Linux, MacOS, Netware, and IRIX. At least moving to values at the high end of the current set of defaults would be a huge improvement. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org 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?200107110200.f6B204x72602>