From: Con Kolivas <kernel@kolivas.org>
To: Bill Davidsen <davidsen@tmr.com>
Cc: ck list <ck@vds.kolivas.org>,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark
Date: Thu, 14 Jul 2005 10:21:52 +1000 [thread overview]
Message-ID: <200507141021.55020.kernel@kolivas.org> (raw)
In-Reply-To: <42D55562.3060908@tmr.com>
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]
On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> Con Kolivas wrote:
> > On Tue, 12 Jul 2005 21:57, David Lang wrote:
> >>for audio and video this would seem to be a fairly simple scaleing factor
> >>(or just doing a fixed amount of work rather then a fixed percentage of
> >>the CPU worth of work), however for X it is probably much more
> >> complicated (is the X load really linearly random in how much work it
> >> does, or is it weighted towards small amounts with occasional large
> >> amounts hitting? I would guess that at least beyond a certin point the
> >> liklyhood of that much work being needed would be lower)
> >
> > Actually I don't disagree. What I mean by hardware changes is more along
> > the lines of changing the hard disk type in the same setup. That's what I
> > mean by careful with the benchmarking. Taking the results from an athlon
> > XP and comparing it to an altix is silly for example.
>
> I'm going to cautiously disagree. If the CPU needed was scaled so it
> represented a fixed number of cycles (operations, work units) then the
> effect of faster CPU would be shown. And the total power of all attached
> CPUs should be taken into account, using HT or SMP does have an effect
> of feel.
That is rather hard to do because each architecture's interpretation of fixed
number of cycles is different and this doesn't represent their speed in the
real world. The calculation when interbench is first run to see how many
"loops per ms" took quite a bit of effort to find just how many loops each
different cpu would do per ms and then find a way to make that not change
through compiler optimised code. The "loops per ms" parameter did not end up
being proportional to cpu Mhz except on the same cpu type.
> Disk tests should be at a fixed rate, not all you can do. That's NOT
> realistic.
Not true; what you suggest is another thing to check entirely, and that would
be a valid benchmark too. What I'm interested in is what happens if you read
or write a DVD ISO image for example to your hard disk and what this does to
interactivity. This sort of reading or writing is not throttled in real life.
Cheers,
Con
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-14 0:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-12 11:10 [ANNOUNCE] Interbench v0.20 - Interactivity benchmark Con Kolivas
2005-07-12 11:57 ` David Lang
2005-07-12 12:02 ` Con Kolivas
2005-07-12 12:17 ` David Lang
2005-07-12 12:23 ` Con Kolivas
2005-07-12 15:18 ` Lee Revell
2005-07-12 17:55 ` David Lang
2005-07-12 18:33 ` Lee Revell
2005-07-12 20:55 ` Al Boldi
2005-07-12 21:32 ` Con Kolivas
2005-07-13 17:54 ` Bill Davidsen
2005-07-14 0:21 ` Con Kolivas [this message]
2005-07-14 0:31 ` David Lang
2005-07-14 0:46 ` Con Kolivas
2005-07-14 1:00 ` Con Kolivas
2005-07-15 12:50 ` Bill Davidsen
2005-07-15 10:41 ` kernel
2005-07-18 14:51 ` Bill Davidsen
2005-07-13 11:27 ` szonyi calin
2005-07-13 17:34 ` Lee Revell
2005-07-13 23:57 ` Con Kolivas
2005-07-16 20:28 ` Lee Revell
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=200507141021.55020.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=ck@vds.kolivas.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