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!news.ysu.edu!news.radio.cz!newsbastard.radio.cz!news.radio.cz!CESspool!hammer.uoregon.edu!news-xfer.netaxs.com!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!super.zippo.com!zdc!szdc!news From: "John S. Dyson" <dyson@indy.celebration.net> 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" Date: Mon, 31 Mar 1997 16:36:14 -0500 Organization: AT&T Lines: 39 Message-ID: <33402E4E.6937@indy.celebration.net> 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> Reply-To: dyson@indy.celebration.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (WinNT; I) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38190 comp.unix.bsd.bsdi.misc:6533 comp.sys.sgi.misc:29573 Larry McVoy wrote: > > Yup, they would. And if the hardware made any substantive difference, > you would be absolutely right. But in the lmbench paper, the P5 > that FreeBSD was on was actually slightly faster than the Linux P5. > It's hard to claim I was skewing the results against FreeBSD. And it > is also hard to claim that I was skewing the results against Linux. > I've measured lots of PCs and the difference between 120 & 133 is just > not enough to be an issue, it's in the noise. > > I'm happy to be proven wrong. I'm waiting.... > 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. In order to look at the lmbench benchmark results and make any kind of coherent interpretation, you have to know what the benchmark is measuring, and the limitations of the measurements. 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. Lmbench is the best publically available low level U**X benchmark that I have seen, but the results need to be interpreted carefully. 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. 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. It would be very appropriate for MS-DOS though :-). John