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

["Jack O'Quin" <joq@io.com>]

Con Kolivas <kernel@kolivas.org> writes:

> Jack O'Quin wrote:
>> Neither run exhibits reliable audio performance.  There is some low
>> latency performance problem with your system.  Maybe ReiserFS is
>> causing trouble even with logging turned off.  Perhaps the problem is
>> somewhere else.  Maybe some device is misbehaving.
>>
>> Until you solve this problem, beware of drawing conclusions.

> Sigh.. I guess you want me to do all the benchmarking. 

Not at all.  I am willing to continue running audio benchmarks for you
and Ingo both.  I have been spending significant amounts of time doing
that.  I can't work on it full-time, but will continue doing tests as
requested.  I just assumed you wanted to be able to produce similar
results on your own system.  I would, if I were in your place.

I think you misunderstood my comment.  I was pointing out that your
system currently has too low a signal/noise ratio to draw conclusions
about scheduling and latency.  How can we tell whether the scheduler
is working or not when there are extremely long XRUNS (~20msec) even
running SCHED_FIFO?  Clearly, something is broken.  We need to figure
out what the latency problem is with your system before putting too
much faith in those results.

> Well it's easy enough to get good results. I'll simply turn off all
> services and not run a desktop. This is all on ext3 on a fully laden
> desktop by the way, but if you want to get the results you're
> looking for I can easily drop down to a console and get perfect
> results.

That would prove absolutely nothing.  The whole purpose in requesting
SCHED_FIFO (or an approximation, like SCHED_ISO) is for audio to work
reliably in a loaded system.  You were running your tests in the right
environment.  Your results showed it wasn't working, but did not
necessarily indicate a scheduler problem.

My tests were all done with GNOME, metacity, xemacs, and galeon
running.  I still use ext2 because back when I tuned my system for
audio, ext3 had very poor low latency behavior.  Maybe that has
changed.  Or, maybe it hasn't and that is the cause of the latency
spikes you're seeing.  I can't figure that out remotely, but I can
suggest some things to try.  First, make sure the JACK tmp directory
is mounted on a tmpfs[1].  Then, try the test with ext2, instead of
ext3.

  [1] http://www.affenbande.org/~tapas/wiki/index.php?Jackd%20and%20tmpfs%20%28or%20shmfs%29

Tuning Linux PC's for low-latency audio is currently an art, not a
science.  But, a considerable body of experience has grown up over the
past few years[2].  It can be done.  (If nothing else, you may develop
more sympathy for all the crap Linux audio developers have been
putting up with for so long.)

  [2] http://affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio%20work%20on%20linux%202.6.x

I recommend testing these schedulers on the best available low latency
kernel for the clearest signal/noise ratio before drawing any final
conclusions.  Right now, that seems to be Ingo's RP version.

The original request that started this whole exercise was for 2.6.10
numbers, which morphed into 2.6.11-rc1.  Working on the mainline of
development makes sense.  And, the mainline is getting a lot better.
But, 2.6.10 is still far from clean as a vehicle for soft-RT.  Your
tests prove that.
-- 
  joq