From: "Ray Lee" <ray-lk@madrabbit.org>
To: "Bill Davidsen" <davidsen@tmr.com>
Cc: "Linux Kernel M/L" <linux-kernel@vger.kernel.org>
Subject: Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Date: Sat, 19 May 2007 23:55:37 -0700 [thread overview]
Message-ID: <2c0942db0705192355r2e53ccd7s6ff5cdca7b32812b@mail.gmail.com> (raw)
In-Reply-To: <464F99EC.3080006@tmr.com>
On 5/19/07, Bill Davidsen <davidsen@tmr.com> wrote:
> Ray Lee wrote:
> > Is the S.D. columns (immediately after the average) standard
> > deviation? If so, you may want to rename those 'stdev', as it's a
> > little confusing to have S.D. stand for that and Staircase Deadline.
> > Further, which standard deviation is it? (The standard deviation of
> > the values (stdev), or the standard deviation of the mean (sdom)?)
> >
> What's intended is the stddev from the average, and perl bit me on that
> one. If you spell a variable wrong the same way more than once it
> doesn't flag it as a possible spelling error.
>
> Note on the math, even when coded as intended, the divide of the squares
> of the errors is by N-1 not N. I found it both ways in online doc, but I
> learned it decades ago as "N-1" so I used that.
<nod> sqrt(N-1) is almost always the correct form, and gives the
"sample standard deviation". sqrt(N) (or the "population standard
deviation") should only be used when you can prove that you're not
doing any sub-sampling of the population at all, which is pretty much
never the case.
In practice, for any decent values of N, the difference between the
two is usually insignificant compared to everything else going on.
> Okay, here's a bonus, http://www.tmr.com/~davidsen/sched_smooth_02.html
> not only has the right values, the labels are changed, and I included
> more data points from the fc6 recent kernel and the 2.6.21.1 kernel with
> the mainline scheduler.
You rock.
> The nice thing about this test and the IPC test I posted recently is
> that they are reasonable stable on the same hardware, so even if someone
> argues about what they show, they show the same thing each time and can
> therefore be used to compare changes.
Yup, these look good to me.
> As I told a manger at the old Prodigy after coding up some log analysis
> with pretty graphs, "getting the data was the easy part, the hard part
> is figuring out what it means." If this data is useful in suggesting
> changes, then it has value. Otherwise it was a fun way to spend some time.
Right. At minimum, the average +- standard deviations of the glxgears
case tells a pretty consistent story, especially if one looks at the
deviation as a percentage of the average. (Mainline is far more
erratic than either SD or CFS, and CFS seems to be able to maintain
high throughput and low jitter.)
I'm not quite sure what to read into the fairness test, other than
mainline is obviously different for the other two in terms of
throughput. Deviations are across the board, but perhaps that's more a
reflection of how much (little) data was collected for this one?
Dunno.
Anyway, as you point out, the usefulness of the tests chosen could
still be up for debate, but I think you've shown that the results are
pretty stable, and at least can serve as a good measure between
versions of schedulers.
next prev parent reply other threads:[~2007-05-20 6:55 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 20:02 Bill Davidsen
2007-05-19 20:22 ` Ray Lee
2007-05-20 0:44 ` Bill Davidsen
2007-05-20 6:12 ` Michael Gerdau
2007-05-20 6:30 ` Ray Lee
2007-05-20 6:59 ` Michael Gerdau
2007-05-20 7:20 ` Ray Lee
2007-05-20 6:55 ` Ray Lee [this message]
2007-05-21 18:27 ` Matt Keenan
2007-05-19 20:36 ` Diego Calleja
2007-05-19 20:55 ` Ray Lee
2007-05-19 23:21 ` Mike Galbraith
2007-05-20 16:29 ` Miguel Figueiredo
2007-05-20 16:44 ` Ray Lee
2007-05-20 16:58 ` Miguel Figueiredo
2007-05-20 17:19 ` Ray Lee
2007-05-22 17:55 ` Bill Davidsen
2007-05-22 20:01 ` Miguel Figueiredo
2007-05-23 0:28 ` Bill Davidsen
2007-05-23 13:10 ` Bill Davidsen
2007-05-23 18:29 ` Miguel Figueiredo
2007-05-23 20:45 ` Bill Davidsen
2007-05-23 21:03 ` Miguel Figueiredo
2007-05-24 0:36 ` Con Kolivas
2007-05-23 4:06 ` William Lee Irwin III
2007-05-23 5:23 ` Michael Gerdau
2007-05-23 7:58 ` Xavier Bestel
2007-05-23 8:21 ` Bill Huey
2007-05-23 18:22 ` Ian Romanick
2007-05-23 18:43 ` Xavier Bestel
2007-05-23 17:22 ` Bill Davidsen
2007-05-23 16:59 ` Bill Davidsen
2007-05-22 17:22 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c0942db0705192355r2e53ccd7s6ff5cdca7b32812b@mail.gmail.com \
--to=ray-lk@madrabbit.org \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome