Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Mar 1999 15:58:51 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Panic in FFS/4.0 as of yesterday - update
Message-ID:  <Pine.LNX.4.04.9903021556450.20721-100000@feral-gw>
In-Reply-To: <99Mar3.083923est.40347@border.alcanet.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Mar 1999, Peter Jeremy wrote:

> Matthew Jacob <mjacob@feral.com> wrote:
> >Would the problem manifest itself under increasing load? One thing I'm
> >mulling doing is to try and move forward musbus or it's equivalent
> 
> MUSBUS is now quite old - I believe it was developed around 1981.  I
> have a paper Ken McDonell presented at AUUG'91 when he discussed some
> of its shortcomings at that time [and there are probably more now].
> 
> I've also heard him state (possibly during that presentation) that
> MUSBUS was designed to benchmark systems around 1 MIPS (ie a VAX
> 11/780), and results obtained on a `current' (ie 5-10 years old now)
> system probably reflect bottlenecks in MUSBUS, rather than the system
> under test.
> 
> [Note that a later developent of MUSBUS - KENBUS - formed part of the
> SPEC's SDM (System Developent Multitasking) 1.x benchmark suite].

Yes. I actually played around with KENBUS for NetBSD but couldn't get it
compiled since it seemed to depend on some libc calls not in NetBSD.

There was a version of MUSBUS in use at Sun - and yes,
MUSBUS is indeed quite old- but it's useful in that you get load stages
for both context switching, IPC, and, to a lesser extend, disk I/O.
There may or may not be bottlenecks intrinsic to MUSBUS, but I can assure
you that it's a start.




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.LNX.4.04.9903021556450.20721-100000>