Re: Interesting scheduling times - NOT

Richard Gooch (rgooch@atnf.csiro.au)
Thu, 24 Sep 1998 22:32:51 +1000


Rogier Wolff writes:
> Richard Gooch wrote:
> > Larry McVoy writes:
> > > : As I've already said, you're probably not seeing the variance because
> > > : you don't run with RT priority.
> > >
> > > Been there, tried it, the results have very low variance:
> > >
> > > RT: 5.42 (5.52 5.47 5.43 5.42 5.42 5.42 5.42 5.41 5.40 5.40 5.39)
> > > !RT: 4.65 (4.86 4.85 4.84 4.83 4.66 4.65 4.61 4.55 4.55 4.54 4.54)
> > >
> > > With 10 background processes:
> > >
> > > RT: 11.04 (11.13 11.11 11.11 11.07 11.07 11.04 11.04 11.00 11.00 10.98 10.98)
> > > !RT: 6.76 (6.99 6.80 6.79 6.79 6.76 6.76 6.75 6.51 6.49 6.48 6.47)
> >
> > Interesting.
> >
> > > : I'm left with variance (up to 50%) in the long run queue case. I can
> > > : sometimes see this variance even with SCHED_OTHER. So there is still
> > > : some other effect going on. Again, I don't see a variance this large
> > > : with your test, so again there is something that my test is sensitive
> > > : too.
> > > : Using pipes and token passing doesn't change the variance, BTW.
> > >
> > > It does if you design the benchmark right. Look, you keep setting
> > > yourself up to take a fall. You may be right about everything else,
> > > but you're just dead wrong about the variance. There is no reason
> > > for it to be there. It's not just my benchmark that doesn't see it,
> > > every other variation of this benchmark is stable in the small
> > > process case (where they are basically simulating or calling
> > > sched_yield()).
> >
> > There is a *reason* the variance is there. The question is what is
> > causing it. Glib replies like "your test is broken" don't answer the
> > question. There is something different about my test that leaves it
>
> Richard,
>
> Could you please stop asking for other people to do a thorough analysis
> of your results?

I don't know why this is so hard to comprehend. I've said again and
again that I don't demend that others analyse my results. I've posted
them for the interest of people on the list. Take it or leave it.
If someone wants to analyse them, that's fine.

Just don't get abusive or aggressive. And don't claim that my test is
broken just because it disagrees with your favourite benchmark.

> Your tests show significantly different results from the "industry
> standard" lmbench benchmark. So, it is up to you to explain the
> difference, if you want the linux kernel to be redesigned on the
> basis of those results. You can post a message to the list, and ask
> if anybody knows of any obvious explanations. The answer is 'No'.

Read my later message where I quote 30% variance in the lmbench
numbers. So much for this perfect "industry standard".

> You can hire me to do the analysis for $750 (US dollars).

No thanks.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/