SCHED_ULE problem: slow single processor, realtime prio vs network stack

[Andrew Reilly]

Hi all,

Let me tell you a story, and perhaps someone can suggest a
different course of action than the one that I've taken, which
has been to switch back to SCHED_4BSD:

I've got an old P3-500 machine that I use for audio processing
experiments and also music playback.  It's got an M-Audio
Delta1010 card in it, which (in its most native mode) has
ten channels in and twelve out, all 24/32-bit.  I use the
4front-tech driver, because the native one doesn't do
multi-channel (yet).  I recently "upgraded" the OS on that box
from 6-stable to 7-stable, since I've had such good experiences
with 7 (and SCHED_ULE) on my desktop and server systems (and
4front now supports 7).  Unfortunatly, for this application,
this was a seriously retrograde step, at first: no matter how
I fiddled the blocking factors and IO sizes, I couldn't stop
the system from glitching (audio buffer underruns).  It seemed
that any (unrelated) network activity would take priority over
the audio, even though I had the audio task set to rtprio=10.
Loging in to the box with ssh was a guaranteed sound glitcher.

It probably doesn't help that that box has a dagy old 100baseTX
RealTek ethernet card, that I have to use with -r=1024 on my NFS
mounts to avoid fragmentation problems.

I'm pleased to report that switching back to SCHED_4BSD has
retrieved the situation, and my audio task is now rock solid and
stable again.

I've been thinking about writing up a PR about the issue, but I
haven't figured out how to generate a minimally failing example
that anyone else would be able to verify.  Maybe I'll just
go ahead and post this message, to see if anyone has any
suggestions.

Given the emphasis of _ULE on multi-processor scalability and
total system throughput (at which it seems to rock), I suspect
that the answer may well be: "use a more suitable operating
system".  I hope not.  I would expect that the same mechanisms
that enable good multi-processor scalability would also have
good real-time characteristics: the same asynchronous events and
preemption are at work in both cases.

So, here's the question: can I do something to my code, or the
way I set its priority, to get something equivalent to the
reliable real-time scheduling that I can get in _4BSD under
_ULE?

Cheers,

Andrew