From owner-freebsd-hackers Thu Jun 14 21:24:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E0D9837B407 for ; Thu, 14 Jun 2001 21:24:02 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f5F4NYf39746; Fri, 15 Jun 2001 00:23:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 15 Jun 2001 00:23:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein Cc: Rajappa Iyer , hackers@FreeBSD.ORG Subject: Re: Sysadmin article In-Reply-To: <20010615001318.F1832@superconductor.rush.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 15 Jun 2001, Alfred Perlstein wrote: > * Rajappa Iyer [010614 22:23] wrote: > > http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm > > > > Any obvious reasons why FreeBSD performed so poorly for these people? > > Because they did benchmarks on systems without tuning. > > A simple email to the lists asking for help would have probably done a > world of difference. There was some discussion of this on freebsd-advocacy yesterday and today, and it sounded like it came down to poor tuning (not enabling soft updates, et al) in combination with a heavy reliance on threading, where we currently don't do so well. A question I posed on -advocacy was when, if ever, we should consider simply enabling soft updates by default on non-root file systems. We claim that soft updates improves both performance and reliability (at the cost of increased kernel complexity), making it a prime candidate for the limelight. Would people be opposed to a change to sysinstall so that (once we're clear that soft updates has stabilized in -CURRENT) such that selecting the default partitioning enables soft updates on any file system not mounted as "/" unless specifically toggled off? How about other tuning: we've previously discussed increasing the default max socket buffer sizes, for example, to allow better tuning for faster network segments. The point has been made that on FreeBSD, we select somewhat conservative (safe) settings by default, and give admins the option to trade off safety and performance as they see fit. On the other hand, there may be further changes we can make that stay well within the realm of safe, yet improve default performance helping us out on Joe Blow's Untuned Performance Test (as you know, many performance tests in popular media don't involve consulting the authors of the code first for tuning help). Likewise, we've gradually been shifting in stance from a "we want to run well on tiny systems" to "we recognize that memory is cheap, and performance is important, let the little guys do more tuning than the medium guys". Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message