From owner-freebsd-hackers Fri Jun 15 9:33:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.kyx.net (s216-232-31-82.bc.hsia.telus.net [216.232.31.82]) by hub.freebsd.org (Postfix) with ESMTP id 56CDF37B408; Fri, 15 Jun 2001 09:32:49 -0700 (PDT) (envelope-from dr@kyx.net) Received: from zyx (unknown [216.232.31.79]) by mail.kyx.net (Postfix) with SMTP id ADC161DC03; Fri, 15 Jun 2001 09:38:08 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" From: Dragos Ruiu Organization: dragostech.com inc. To: Robert Watson , Alfred Perlstein Subject: Re: Sysadmin article Date: Fri, 15 Jun 2001 09:34:14 +0000 X-Mailer: KYX-CP/M [core01-v01-02a] Cc: Rajappa Iyer , hackers@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01061509341402.30671@zyx> Content-Transfer-Encoding: 8bit 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 I would heartily endorse having the out of the box FreeBSD install be tuned better... Sysadmin can't be knocked for not doing the tuning as running an out of the box config is what a vast majority of users do, imho, so their performance tests and the poor results from FreeBSD are perfectly valid indication of what can be expected without tuning. Softupdates on by default sounds great to me, as I can't think of any common situations that would be hurt by it. But I'm sure someone will correct me if I'm wrong on this. Now if we could only speed up SMP too... cheers, --dr On Friday 15 June 2001 04:23, Robert Watson wrote: > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message