|Andrew Reilly||Aug 18, 2008 7:49 pm|
|Dieter||Aug 19, 2008 12:57 am|
|Jeff Roberson||Aug 19, 2008 12:59 am|
|Andrew Reilly||Aug 19, 2008 6:39 am|
|Jeff Roberson||Aug 21, 2008 12:46 am|
|Andrew Reilly||Aug 25, 2008 4:59 pm|
|Andrew Reilly||Aug 27, 2008 4:38 pm|
|Andrew Reilly||Aug 27, 2008 9:03 pm|
|Gary Jennejohn||Aug 28, 2008 3:36 am|
|Andrew Reilly||Aug 28, 2008 5:41 am|
|Andrew Reilly||Aug 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|
On Tue, 19 Aug 2008, Andrew Reilly wrote:
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?
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "free...@freebsd.org"
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia To unsubscribe, send any mail to "free...@freebsd.org"