[PlanetCCRMA] Configuring 2.6.11-0.3.rdt.rhfc2.ccrma for 0 xruns...

[Mark Knecht]

On 13 Apr 2005 11:44:53 -0700, Fernando Lopez-Lezcano
<nando@ccrma.stanford.edu> wrote:
> On Wed, 2005-04-13 at 11:28, Mark Knecht wrote:

> > 1) Is any of this chrt stuff sticky? Or is this something I'd have to
> > do every time I boot?
> 
> If you change stuff you have to do that every boot. "Rtirq" is already
> reordering stuff on its own so that the soundcards have higher priority
> than the rest.
> 
> > 2) What is 'fifo priority'?
> 
> That is technically SCHED_FIFO, the realtime priority scheduler classer
> (all "normal" processes are in the SCHED_OTHER class, SCHED_FIFO
> processes have priority over SCHED_OTHER tasks no matter what, and once
> they get the cpu they run until they voluntarily relinquish the cpu -
> that's how jack and its clients run).

OK. Now, what I'm seeing is that every IRQ process is SCHED_FIFO:

[root@Godzilla root]# chrt -p 1151
pid 1151's current scheduling policy: SCHED_FIFO
pid 1151's current scheduling priority: 60
[root@Godzilla root]# chrt -p 20
pid 20's current scheduling policy: SCHED_FIFO
pid 20's current scheduling priority: 59
[root@Godzilla root]# chrt -p 344
pid 344's current scheduling policy: SCHED_FIFO
pid 344's current scheduling priority: 50
[root@Godzilla root]# chrt -p 411
pid 411's current scheduling policy: SCHED_FIFO
pid 411's current scheduling priority: 42
[root@Godzilla root]#

Do we really want it that way?

> 
> > 3) Which way is 'higher priority'? 80 or 37.
> 
> 100 is highest
> 

[root@Godzilla root]# chrt -m
SCHED_FIFO min/max priority     : 1/99
SCHED_RR min/max priority       : 1/99
SCHED_OTHER min/max priority    : 0/0
[root@Godzilla root]#

> 
> Strange. It could be that rtirq is running before all the sound modules
> are loaded. What happens if you run "rtirq stop" and "rtirq start" after
> the boot is complete? Does that change the priorities?
> 
> > I've tried changing dirty_expire_centisecs to 1000 and started a new
> > copy. 2 minutes in and no xruns so far at 128/2, but I'll need to go
> > the full 20 minutes to have more confidence. After that I'll try 64/2.
> 
> So that is the reason for your xruns. "1000" was just a suggestion, not
> what you have to use, you can try using lower values.

No. You know how statistical stuff is, correct? As soon as you say one
thing then the other starts happening. With that test it went about
5-8 minutes with no xruns, but then from 8-22 minutes I got a large
number of xruns. It actually came out worse than the 3000 setting,
although I ran each copy only once so I'm not sure what it proves.

Now, I thought I'd saved the message from either Leee Ravell or Ingo
Molnar about this. I do this on the laptop that was working so well
but was not doing here on my Planet box with your kernel. I just tried
it. The whole 20 minute, 21GB copy ran perfectly with no xruns at
128/2. Set the HDSP interrupt to non-threaded operation:

[root@Godzilla root]# echo "0" > /proc/irq/9/hdsp/threaded

With this I'm getting good, no very good or great, results.

I pointed this out to Ryan Gallager some time back and he did it for
his USB devices and got good results. I had asked you about this (or I
think I did) as few days back but it seemed like you thought it wasn'
t appropriate for this kernel? Did I get that wrong? Is there any
reason you know of not to use this? As I say, I think it was Ingo who
told me to try it back when I was having trouble with ACPI and USB
mice in October, 04.

Anyway, perfect results at 128/2. I'll be trying 64/2 in a few minutes.

This can be set in rc.local, etc. and works every time I boot up on my
laptop.
> 
> > I do not understand these vm parameters....
> 
> Neither do I. I think they tune how the virtual memory subsystem works.
> The one you are changing tells the system how long to wait between scans
> of dirty pages (pages that are marked to be written to disk). If that is
> too long then when the system checks there are a lot of pages to write
> to disk and that presumably causes the xrun, if you lower that the
> system checks more often (causing more overhead?) and finds less pages
> to write to disk.
> 

thanks!

- Mark