SCHED_ULE problem: slow single processor,
realtime prio vs network stack
Andrew Reilly
andrew-freebsd at areilly.bpc-users.org
Wed Aug 27 23:39:12 UTC 2008
On Wed, Aug 20, 2008 at 09:47:01PM -1000, Jeff Roberson wrote:
> On Tue, 19 Aug 2008, Andrew Reilly wrote:
> >I haven't tried nice -20 because I don't want the priority to
> >drift or change, which is something that I thought the normal
> >levels did. I'll give it a go though, and report back.
>
> With such a low cpu utilization I wouldn't expect it's the scheduling
> algorithm. It may be a difference in preemption settings. Is preemption
> enabled in both kernels?
I've just done a set of tests with setprio(... -20) vs
rtprio(...10), and with SCHED_ULE vs SCHED_4BSD. The results
are essentially as I reported before except that regular prio
-20 seems to be just as reliable as rtprio 10 under 4BSD and
just as unhelpful under _ULE.
To summarise:
SCHED_ULE: rtprio 10: network activity causes audio underruns
SCHED_ULE: setprio -20: network activity causes audio underruns
SCHED_4BSD: rtprio 10: no audio underruns
SCHED_4BSD: setprio -20: no audio underruns
For what it's worth, my audio buffering setup has a fragment
size of 0.7ms, but several buffers. How is device driver
activity prioritized? Does the scheduler in use effect how
device interrupts are handled, as well as user-land tasks?
I have kernels built with both schedulers sitting arround on
this machine now, so it's easy to switch back and forth if there
are some specific tests that I could do or other information
that I could provide.
Cheers,
Andrew
More information about the freebsd-multimedia
mailing list