Date: Wed, 11 Jul 2001 19:37:41 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Leo Bicknell <bicknell@ufp.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Network performance tuning. Message-ID: <Pine.BSF.4.21.0107111904220.60496-100000@InterJet.elischer.org> In-Reply-To: <20010711195021.A89324@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Some good points. On Wed, 11 Jul 2001, Leo Bicknell wrote: > > > > * FreeBSD is at the middle-bottom of the pack when it comes to > defaults. http://www.psc.edu/networking/perf_tune.html AND we still don't have a working standard SACK implementation. > > There are a number of issues that come out of this: > > * MBUF's are currently allocated based on NMBCLUSTERS, which is > based on MAXUSERS (unless overridden). NMBCLUSTERS is found > using the formula 512 + MAXUSERS * 16. This forumla has been in use > for a long time, and it may be time to consider allocating a few > more clusters per user. MBUF's is 4 * NMBCLUSTERS, which is a fine > number, but testing shows gives you too many MBUF's in many cases. > (Or, put another way, most every system I've seen shows a trend > of running out of clusters way before MBUF's.) > This CAN be set separatly I think.. > * The socket layer needs to be more intelligent about its buffering. > Simply always allocating the largest buffer is easy to code, but > wastes considerable resources, particular on machines with lots > of connections. certainly it should be dynamic I'm certain we can work out the bandwidth product .. and thus the maximum window needed... > > So, I'd like to propose some fixes to get people thinking. I have > ordered them in the order I think they should be done: > > 1) The per-socket defaults should be raised to 32k in the next > release, giving 2x today's performance in general, and putting > FreeBSD on par at least with most Linux distro's. I think the > memory consequences here are quite minor, and provide a good > place to study the effects on real world people. I think that being able to dynamically work out the window would be the best idea.. The minimum RTT is discovered pretty quickly. Keeping the buffer size no more than twice the calculated bandwidth product presently being used would work fine. (or the max windowsize) would probably be a good move. Your suggestion below is certainly a good basis to start from. > > 2) The socket layer needs to be modified to not use the maximum > buffer as the default. Imagine if disk drivers allocated 4 Meg > for every process writing to disk, just because the disk has a > 4 Meg cache. The buffer clearly needs to hold all unacknowledged > data, and should therefor grow as the window size grows, plus > some overhead so that some unsent data can be buffered in the > kernel (to avoid context switches and the like). This way > connections to slow hosts (eg dial up users) would not buffer > much more than the window size, using only a small amount of > memory. This would allow admins to set the sizes much larger > without wasting memory on connections that will never use it. > > Note, from looking at soreserve and related code it appears it > just sets maximums, and that raising it midstream would have no > ill effects. (Reducing would.) So a good first stab might be > to have a new "initial socket buffer" size passed to soreserve > when a new socket is created, and if the TCP window could be > increased past that value at any point it could be recalled (or > a resize function created) that raised the limit to 2 * maxwin, > or 1.1 * maxwin, or maxwin + buffer or whatever is appropriate > up to the hard limit set by the system administrator. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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.0107111904220.60496-100000>