SCHED_ULE problem: slow single processor, realtime prio vs network stack

[Gary Jennejohn]

On Thu, 28 Aug 2008 09:38:31 +1000
Andrew Reilly <andrew-freebsd at areilly.bpc-users.org> wrote:

> 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.
> 

Ah yes, but do you have options PREEMPTION set, which was Jeff's question?

---
Gary Jennejohn