*BSD News Article 92711


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!news.mathworks.com!enews.sgi.com!fido.asd.sgi.com!neteng!lm
From: lm@neteng.engr.sgi.com (Larry McVoy)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc
Subject: Re: no such thing as a "general user community"
Followup-To: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc
Date: 2 Apr 1997 21:08:37 GMT
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 71
Message-ID: <5huhsl$8ru@fido.asd.sgi.com>
References: <331BB7DD.28EC@net5.net> <333EA3EF.41C67EA6@consys.com> <333EE416.ABD322C@FreeBSD.org> <5hn00k$dio@fido.asd.sgi.com> <5hnam9$393@hoopoe.psc.edu> <5hp7p3$1qb@fido.asd.sgi.com> <33402E4E.6937@indy.celebration.net>
Reply-To: lm@slovax.engr.sgi.com
NNTP-Posting-Host: neteng.engr.sgi.com
X-Newsreader: TIN [version 1.2 PL2]
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38386 comp.unix.bsd.bsdi.misc:6575 comp.sys.sgi.misc:29661

John S. Dyson (dyson@indy.celebration.net) wrote:
: The lmbench suite doesn't always measure what it claims, and there
: are often defects in the accuracy when it comes close.  Please refer
: to the "null" syscall benchmark (look for a "null" syscall in that
: benchmark.)  A read/write system call is not null unless it is
: special cased.

The next version of lmbench addresses both of these points:

Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host                 OS  Mhz null null      open sele sig  sig  fork exec sh  
                             call  I/O stat clos   ct inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
o200      IRIX64 6.4-AL  180    2   11   55   74 0.55K   6   21 1.4K   5K   7K

Null call is getppid(), Null I/O is the average of a 1 byte read from
/dev/zero and a 1 byte write to /dev/null, stat is the hot cache stat
time for /usr/include/sys/types.h, open/close is open/close of the same
.h file.

All timings now run in an automatically sized loop like so:

        LOOP_FIRST(N, i, ENOUGH);
        if (read(fd, &c, 1) != 1) {
                perror("/dev/zero");
                exit(1);
        }
        LOOP_LAST(N, i, ENOUGH);
        micro("Simple read", N);

The macros redo the test until it has run for at least ENOUGH usecs.
For most tests, ENOUGH == 1 second.

: Lmbench is
: most valuable when you have a printout of its source code sitting
: next to you.  You can then rewrite the benchmark to measure what things
: that you want to measure, instead of the things that lmbench measures.

That, by the way, is just fine with me.  In many respects, one of
the useful aspects of lmbench is that it provides a framework for
benchmarking.  I'm very pleased to see you wacking on it to make it suit
your needs, I think that is great.

Perhaps a better way for me to have presented this stuff would have been
"this is a set of benchmarks that I think are useful and here are some
results - if you don't think they are the right things to measure, please
go modify lmbench to suit your taste".

: I think
: that making either overstated claims based upon the benchmark results,
: or simply showing them does a disservice to the people who do not go
: out of their way to understand what the suite measures.

I tend to agree.  Lmbench tries to give a kernel developer enough info
to help focus tuning efforts, and a user enough info to predict certain
application performance characteristics.  But if you don't think, you
don't get very much benefit.   I'm hardly willing to be held accountable
for people [dis]enaging their brains...

: BTW, when lmbench is running, isn't there mostly only one or two
: processes
: eligible to run?  I really don't think that running code with a single
: runnable execution context is a very thorough test of a multitasking OS
: that one could make many generalizations from. 

Yup, in it's current form, with the exception of the context switching
stuff, it's a single user, single CPU benchmark.  I'm working on that.
--
---
Larry McVoy     lm@sgi.com     http://reality.sgi.com/lm     (415) 933-1804