[SunRescue] BSD faster than Solaris??

Greg A. Woods rescue at sunhelp.org
Thu May 17 23:17:16 CDT 2001


[ On Thursday, May 17, 2001 at 21:47:28 (-0400), Gil Young wrote: ]
> Subject: Re: [SunRescue] BSD faster than Solaris??
>
> I dont doubt anything you observed.  In my "touchy-feely" experience, BSD
> running Linux packages in emulation mode run them overall faster than Linux
> does :).  BSD is very well optimized.

NetBSD, prior to 1.6 (not yet released!), is not well optimized.  I
can's say for 100% sure, but I'd guess given OpenBSD's heritage that
it's not much better off.

*BSD *is* well tuned out-of-the-box to workstation use, though I
wouldn't exactly describe it as "very well optimized".

NetBSD in particular, prior to 1.6, is absolutely terrible at making
good use of its buffer cache (because it can't).  Compared to even
ancient AT&T SysVr3.2 it sucks completely at some kinds of tasks (even
those so simple as running repeated find/ls/etc. over a directory tree).

As of 1.6 (and in -current now) there will finally be a unified buffer
cache (UBC) (to go along with the entirely new, from the ground up,
virtual memory implementation (UVM).  In -current now the UBC thing is a
bit agressive at stealing "unused" memory for the buffer cache, and it
does this by paging out "stale" processes.  Unfortunately if they turn
out to not be quite so stale it'll cause a bit of thrashing.  You don't
notice it too much on machines with more than ample memory, but
supposedly on smaller machines, and particularly if you mix
workstation-like activies (such as X11, audio, etc.) with server-like
activities (such as compiling, databases, etc.) then you'll supposedly
not be so happy.  These issues should be resolved by the time 1.6 is
released.

FreeBSD has a different new VM as of a long time ago, and IIRC had a
unified buffer cache long ago too.

Note that a unified buffer cache can be extremely necessary for some
applications too -- it's been a long wait for NetBSD to get it!  I
didn't switch from SunOS-4 on some machines for a long time because of
this.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>



More information about the rescue mailing list