Skip site navigation (1)Skip section navigation (2)
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>