Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Jun 2001 00:23:34 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        Alfred Perlstein <bright@rush.net>
Cc:        Rajappa Iyer <rsi@panix.com>, hackers@FreeBSD.ORG
Subject:   Re: Sysadmin article
Message-ID:  <Pine.NEB.3.96L.1010615001753.39616A-100000@fledge.watson.org>
In-Reply-To: <20010615001318.F1832@superconductor.rush.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Jun 2001, Alfred Perlstein wrote:

> * Rajappa Iyer <rsi@panix.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010615001753.39616A-100000>