mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jack O'Quin" <joq@io.com>
To: hihone@bigpond.net.au
Cc: Con Kolivas <kernel@kolivas.org>,
	linux <linux-kernel@vger.kernel.org>,
	CK Kernel <ck@vds.kolivas.org>,
	rlrevell@joe-job.com, paul@linuxaudiosystems.com
Subject: Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt	scheduling
Date: Tue, 18 Jan 2005 10:17:50 -0600	[thread overview]
Message-ID: <87d5w2u2xd.fsf@sulphur.joq.us> (raw)
In-Reply-To: <41ED2F1F.1080905@bigpond.net.au> (Cal's message of "Wed, 19 Jan 2005 02:45:35 +1100")

Cal <hihone@bigpond.net.au> writes:

> There's a collection of test summaries from jack_test3.2 runs at
> <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
>
> Tests were run with iso_cpu at 70, 90, 99, 100, each test was run
> twice. The discrepancies between consecutive runs (with same
> parameters) is puzzling.  Also recorded were tests with SCHED_FIFO and
> SCHED_RR.

It's probably suffering from some of the same problems of thread
granularity we saw running nice --20.  It looks like you used
schedtool to start jackd.  IIUC, that will cause all jackd processes
to run in the specified scheduling class.  JACK is carefully written
not to do that.  Did you also use schedtool to start all the clients?

I think your puzzling discrepancies are probably due to interference
from non-realtime JACK threads running at elevated priority.

> Before drawing any hardball conclusions, verification of the results
> would be nice. At first glance, it does seem that we still have that
> fateful gap between "harm minimisation" (policy) and "zero tolerance"
> (audio reality requirement).

I still have not found time to run Con's latest version.  I've been
too busy trying to hack JACK into working with nice(-20), which has
turned out to be quite difficult.  The interfaces we need don't work,
and the ones that do are not what we need.  :-(

I believe Con's latest sched patch should work fine with the normal
jack_test3.2 using the -R option of jackd.  That should produce more
consistent results.
-- 
  joq

  parent reply	other threads:[~2005-01-18 16:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-18 13:01 Con Kolivas
2005-01-18 14:53 ` Con Kolivas
2005-01-18 15:45 ` [ck] " Cal
2005-01-18 15:53   ` Con Kolivas
2005-01-18 16:23     ` Jack O'Quin
2005-01-18 16:17   ` Jack O'Quin [this message]
2005-01-19  2:02     ` Lee Revell
2005-01-19  2:08       ` Con Kolivas
2005-01-19  5:26 ` utz
2005-01-19  5:31   ` Con Kolivas
2005-01-19 14:01   ` Con Kolivas
2005-01-19  6:54 ` Jack O'Quin
2005-01-19  7:56   ` Con Kolivas
2005-01-19 14:27     ` Jack O'Quin
2005-01-19  9:33   ` Con Kolivas
2005-01-19 17:12     ` Jack O'Quin
2005-01-20  0:07       ` Con Kolivas
2005-01-20  1:21         ` Jack O'Quin

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=87d5w2u2xd.fsf@sulphur.joq.us \
    --to=joq@io.com \
    --cc=ck@vds.kolivas.org \
    --cc=hihone@bigpond.net.au \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@linuxaudiosystems.com \
    --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

Powered by JetHome