Re: lmbench results for 2.4 and 2.5 -- updated results

["Martin J. Bligh" <mbligh@aracnet.com>]

> In general, LMbench optimizes for fast results over exactness.  You can
> definitely get more accurate results by doing longer runs.  My view
> at the time of writing it was that I was looking for the broad stroke
> results because I was trying to measure differences between various
> operating systems.  There was more than enough to show so the results
> didn't need to be precise, getting people to run the benchmark and
> report results was more important.
> 
> If people are doing release runs to see if there are regressions, I
> think that setting ENOUGH up to something longer is a good idea.
> If there is enough interest, I could spend some time on this and
> try and make a more accurate way to get results.  Let me know.

Well, I'd certainly be interested ... I think it's almost inevitable 
that there's a bit of variations in timing ... the way I normally deal 
with that is to do, say 30 runs, sort the results, throw away the top 
and bottom 10, and take the average of the middle 10. 

Now at the moment, I presume you're presenting back an average of all
the runs you did ... if so, that looses some of the data to calculate
that, so we have to do multiple runs, etc and it all gets a bit slower.
If you can do that kind of stats op inside the lmbench tools, it
might help. Of course, I can do that outside as a wrapper, but then
there's the fork/exec setup time of the program to consider, etc etc.

The other interesting question is *why* there's so much variability
in results in the first place. Indicative of some inner kernel problem?
People have talked about page colouring, etc before, but I've tried
before, and never mananged to generate any data showing a benefit for
std dev of runs or whatever. Incidentally, this means that giving std
dev (of the used subset, and all results) from lmbench would be fun ;-)

The other problem was the "make it long enough to profile" thing ...
I think the ENOUGH trick you showed us is perfectly sufficent to solve
that one ;-)

Thanks,

M.