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

Andrew Reilly andrew-freebsd at
Tue Aug 19 08:54:23 UTC 2008

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

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



More information about the freebsd-multimedia mailing list