From owner-freebsd-arch Wed Jul 18 20: 4:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id C459C37B401 for ; Wed, 18 Jul 2001 20:04:47 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 6821 invoked by uid 1000); 19 Jul 2001 03:04:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jul 2001 03:04:45 -0000 Date: Wed, 18 Jul 2001 22:04:45 -0500 (CDT) From: Mike Silbersack To: Cc: Bosko Milekic , Matt Dillon , David O'Brien Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c In-Reply-To: <20010718121851.B26558@dragon.nuxi.com> Message-ID: <20010718214902.H6519-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 18 Jul 2001, David O'Brien wrote: > > In any case, both NMBUFS and NMBCLUSTERS can be easily overriden with > > the respective boot-time tunable parameters. And remember, these values are > > merely used to reserve KVA space. > > BUT they should be pretty reasonable numbers to start with. People > continue to "benchmark" FreeBSD out of the box. We need to start paying > more attention to the out-of-the-box settings. > > -- > -- David (obrien@FreeBSD.org) With tcp templates out of the way, it looks like mbufs aren't such a big deal anymore; they'll certainly decrease performance, but will no longer set a definite ceiling on the max number of sockets useable simultaneously. I think you're right in increasing the number of mbufs, but changing the scaling factor is probably the wrong way to do it; it will cause people with custom kernels to have many thousands more mbufs than they expect. In 4.x, the setting is currently at: (512 + MAXUSERS * 16) current was (1024 + MAXUSERS * 16) before your scaling change (to * 64). How about we instead change the constant amount, to perhaps: (2048 + MAXUSERS * 16) This should be pretty safe for -stable, and will help for people running benchmarks out of the box. (I'd like to do the scaling based on RAM size, but I don't have time at the moment.) Note that if we're increasing this, we should probably increase maxfiles/sockets - that's probably more important now. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message