Date: Tue, 19 Aug 2008 08:57:50 +0100 From: Dieter <freebsd@sopwith.solgatos.com> 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: <200808191557.PAA05091@sopwith.solgatos.com> In-Reply-To: Your message of "Tue, 19 Aug 2008 12:50:19 %2B1000." <20080819025019.GA27997@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. This is very interesting. Rtprio does not work, but switching schedulers does. Is there something that the scheduler affects that rtprio doesn't? > 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. If you've only tried changing the priority and buffer sizes of the audio process, you could try nicing the network down, and changing the network's buffer sizes up/down. But I wouldn't count on that helping much, if any. I suspect that the answer, at least in your case, is use _4BSD. The goal of total system throughput, and the goal of real time are somewhat at odds. For example giving processes longer time slices would reduce the number of context switches and should increase total system throughput, but would hurt real time response. I've been battling similar real time problems. I'm already using _4BSD, so it doesn't solve everything. From what I can figure out, some device drivers simply hog the CPU for long periods of time. Hopefully that can be fixed. And the schedulers are concerned with allocating CPU, but ignore allocating I/O resources fairly. Nice/rtprio has very little affect on I/O if the process doesn't use much CPU. We really need a way to nice I/O up/down.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808191557.PAA05091>