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

[Andrew Reilly]

Hi Jeff,

Sorry for the slow follow-up.  It's actually quite a pain to
tweak the kernel on that machine: it's often in use and it's
slow at compiling kernels.  Will see if I can get on to it soon.

On Wed, Aug 20, 2008 at 09:47:01PM -1000, Jeff Roberson wrote:
> On Tue, 19 Aug 2008, Andrew Reilly wrote:
> 
> >On Mon, Aug 18, 2008 at 10:00:12PM -1000, Jeff Roberson wrote:
> >>Can you tell me what % cpu the audio application uses while running?  Have
> >>you tried nice -20 instead of rtprio?
> >
> >It's currently using about 10%, maybe a bit more.  I expect
> >it to get heavier as I add more to it.  I have hopes of it
> >continuing to work even at 60 to 80% of CPU.
> >
> >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?

Yes, all of the premption and POSIX realtime options (that are
usually on, aren't they?) are on in each case.  Only difference
is selection of scheduler:

(This is the whole config file)
include		GENERIC
ident		GURNEY

nocpu		I486_CPU
nocpu		I586_CPU
nooptions	SCHED_ULE
options		SCHED_4BSD


Cheers,

Andrew