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

Jeff Roberson jroberson at
Tue Aug 19 08:28:08 UTC 2008

On Tue, 19 Aug 2008, Andrew Reilly wrote:

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

Can you tell me what % cpu the audio application uses while running?  Have 
you tried nice -20 instead of rtprio?


> 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
> _______________________________________________
> freebsd-arch at mailing list
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at"

More information about the freebsd-multimedia mailing list