Date: Tue, 19 Aug 2008 12:50:19 +1000 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: freebsd-arch@freebsd.org, freebsd-multimedia@freebsd.org Subject: SCHED_ULE problem: slow single processor, realtime prio vs network stack Message-ID: <20080819025019.GA27997@duncan.reilly.home>
next in thread | raw e-mail | index | archive | help
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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080819025019.GA27997>