public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Lee Revell <rlrevell@joe-job.com>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	ck list <ck@vds.kolivas.org>
Subject: Re: [ANNOUNCE] Interbench v0.21
Date: Mon, 18 Jul 2005 06:18:27 +1000	[thread overview]
Message-ID: <200507180618.27121.kernel@kolivas.org> (raw)
In-Reply-To: <1121503267.5070.21.camel@mindpipe>

On Sat, 16 Jul 2005 06:41 pm, Lee Revell wrote:
> On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> > Interbech is a an application is designed to benchmark interactivity in
> > Linux.
> >
> > Version 0.21 update
> >
> > http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
>
> I would suggest using microseconds for both the RT and non RT tests.  It
> would allow easier comparison of results.  I have a pretty slow machine
> and the max result would only be ~44000 usecs.

I think the significance of usec values from the non-rt tests makes this an 
inappropriate thing to do. The variation in results will be greater than usec 
resolution.

> Also, if it's run with -r and sched_setscheduler fails, rather than
> saying "you must be root for SCHED_FIFO" the error message should
> encourage the user to try a 2.6.12+ kernel and add themselves to the
> "audio" or "realtime" group, and to file a feature request if their
> distro does not support the new realtime rlimit feature.
>
> We should encourage more applications to take advantage of, and distros
> to support, the non-root RT scheduling available in 2.6.12+.  I really
> think the kernel is good enough at this point that we could achieve
> OSX-like multimedia performance on the desktop if more apps like xmms,
> xine, and mplayer were to adopt a multithreaded model with the
> time-critical rendering threads running RT.  XMMS recently adopted such
> a model, but I don't think the audio thread runs SCHED_FIFO yet.  These
> benchmarks imply that it would be a massive improvement.

While I agree with you in principal on getting the rlimit feature working and 
supported, this benchmark is meant to be run in single user mode for most 
reproducible and valid results. However, clearly there will be people using 
it cautiously as a normal user first. I originally did not include the 
information that you need to be root in v.20 and said in the documentation 
"need rt privileges" but within about 5 minutes of posting it I had someone 
not understanding what "unable to get SCHED_FIFO" meant. I guess a more 
verbose message will be required explaining non-root RT as well.

Cheers,
Con

      reply	other threads:[~2005-07-17 20:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-15  4:01 [ANNOUNCE] Interbench v0.21 Con Kolivas
2005-07-15 15:05 ` Al Boldi
2005-07-16  7:53 ` Lee Revell
2005-07-16  8:41 ` Lee Revell
2005-07-17 20:18   ` Con Kolivas [this message]

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=200507180618.27121.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=ck@vds.kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    /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