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

[Andrew Reilly]

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