Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Lee Revell wrote:
On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
Cal <[EMAIL PROTECTED]> writes:

There's a collection of test summaries from jack_test3.2 runs at

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.

Isn't this going to be a showstopper?  If I understand the scheduler
correctly, a nice -20 task is not guaranteed to preempt a nice -19 task,
if the scheduler decides that one is more CPU bound than the other and
lowers its dynamic priority.  The design of JACK, however, requires the
higher priority threads to *always* preempt the lower ones.
The point was the application was started in a manner which would not 
make best use of this policy. The way it was started put everything 
under the same policy, and had equal performance with doing the same 
thing as SCHED_FIFO. So if it's a showstopper for SCHED_ISO then it is a 
showstopper for SCHED_FIFO. Which is, of course, not the case. The test 
needs to be performed again with the rt threads running SCHED_ISO, which 
 Jack has pointed out is trivial. Nice -n -20 on the other hand will 
suffer from this problem even if only the real time thread was run at -20.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Lee Revell]

On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
> Cal <[EMAIL PROTECTED]> writes:
> 
> > There's a collection of test summaries from jack_test3.2 runs at
> > 
> >
> > 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.

Isn't this going to be a showstopper?  If I understand the scheduler
correctly, a nice -20 task is not guaranteed to preempt a nice -19 task,
if the scheduler decides that one is more CPU bound than the other and
lowers its dynamic priority.  The design of JACK, however, requires the
higher priority threads to *always* preempt the lower ones.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Jack O'Quin]

Con Kolivas <[EMAIL PROTECTED]> writes:

> Cal wrote:
>
> SCHED_ISO
> /proc/sys/kernel/iso_cpu . . .: 70
> /proc/sys/kernel/iso_period . : 5
> XRUN Count  . . . . . . . . . :   110
>
> vs
>
> SCHED_FIFO
> XRUN Count  . . . . . . . . . :   114
> XRUN Count  . . . . . . . . . :   187
>
> vs
>
> SCHED_RR
> XRUN Count  . . . . . . . . . : 0
> XRUN Count  . . . . . . . . . : 0
>
> Something funny going on here... You had more xruns with SCHED_FIFO
> than the default SCHED_ISO settings, and had none with SCHED_RR. Even
> in the absence of the SCHED_ISO results, the other results dont make a
> lot of sense.

Actually it makes perfect sense.  Running non-realtime JACK threads
SCHED_FIFO will do the most harm.  The others less.

I predict that using normal jackd -R (without schedtool) will produce
the same results running SCHED_FIFO and SCHED_ISO (within the normal
variance).

I think schedtool is too blunt and instrument for making these
measurements.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Jack O'Quin]

Cal <[EMAIL PROTECTED]> writes:

> There's a collection of test summaries from jack_test3.2 runs at
> 
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Cal]

Con Kolivas wrote:
Comments and testing welcome.
There's a collection of test summaries from jack_test3.2 runs at

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.

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).

cheers, Cal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Cal wrote:
Con Kolivas wrote:
Comments and testing welcome.

There's a collection of test summaries from jack_test3.2 runs at

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.

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).
Thanks.
SCHED_ISO
/proc/sys/kernel/iso_cpu . . .: 70
/proc/sys/kernel/iso_period . : 5
XRUN Count  . . . . . . . . . :   110
vs
SCHED_FIFO
XRUN Count  . . . . . . . . . :   114
XRUN Count  . . . . . . . . . :   187
vs
SCHED_RR
XRUN Count  . . . . . . . . . : 0
XRUN Count  . . . . . . . . . : 0
Something funny going on here... You had more xruns with SCHED_FIFO than 
the default SCHED_ISO settings, and had none with SCHED_RR. Even in the 
absence of the SCHED_ISO results, the other results dont make a lot of 
sense.

Con
P.S. If you're running on SMP it may be worth booting on UP or using cpu 
affinity (schedtool -a 0x1 will bind you to 1st cpu only) and see what 
effect that is having. There are some interesting things that can 
adversely affect latency on SMP.


signature.asc
Description: OpenPGP digital signature