atom feed11 messages in org.freebsd.freebsd-multimediaRe: SCHED_ULE problem: slow single pr...
FromSent OnAttachments
Andrew ReillyAug 18, 2008 7:49 pm 
DieterAug 19, 2008 12:57 am 
Jeff RobersonAug 19, 2008 12:59 am 
Andrew ReillyAug 19, 2008 6:39 am 
Jeff RobersonAug 21, 2008 12:46 am 
Andrew ReillyAug 25, 2008 4:59 pm 
Andrew ReillyAug 27, 2008 4:38 pm 
Andrew ReillyAug 27, 2008 9:03 pm 
Gary JennejohnAug 28, 2008 3:36 am 
Andrew ReillyAug 28, 2008 5:41 am 
Andrew ReillyAug 28, 2008 3:52 pm 
Subject:Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack
From:Jeff Roberson (jrob@jroberson.net)
Date:Aug 19, 2008 12:59:49 am
List:org.freebsd.freebsd-multimedia

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?

Thanks, Jeff

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,