Date: Mon, 18 Aug 2008 22:00:12 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> Cc: freebsd-multimedia@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCHED_ULE problem: slow single processor, realtime prio vs network stack Message-ID: <20080818215813.H952@desktop> In-Reply-To: <20080819025019.GA27997@duncan.reilly.home> References: <20080819025019.GA27997@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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, > > Andrew > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080818215813.H952>