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

[Dieter]

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