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

Wed Apr 13 11:45:00 PDT 2005

On Wed, 2005-04-13 at 11:28, Mark Knecht wrote:
> On 13 Apr 2005 11:11:15 -0700, Fernando Lopez-Lezcano
> <nando at ccrma.stanford.edu> wrote:
> > > [root at Godzilla root]# /etc/init.d/rtirq status
> > >
> > >   PID CLS RTPRIO  NI PRI %CPU STAT COMMAND
> > >   242 FF      80  -5 120  0.0 SW<  IRQ 8
> > >    20 FF      60  -5 100  0.0 SW<  IRQ 9
> > >   407 FF      60  -5 100  0.0 SW<  IRQ 5
> > >   961 FF      59  -5  99  0.1 SW<  IRQ 11
> > >   344 FF      50  -5  90  0.0 SW<  IRQ 1
> > >   263 FF      49  -5  89  0.0 SW<  IRQ 12
> > >   303 FF      46  -5  86  0.0 SW<  IRQ 14
> > >   305 FF      45  -5  85  0.0 SW<  IRQ 15
> > >   411 FF      42  -5  82  0.0 SW<  IRQ 10
> > >   2152 FF      40  -5  80  0.0 SW<  IRQ 7
> > >   2179 FF      39  -5  79  0.0 SW<  IRQ 4
> > >   2180 FF      38  -5  78  0.0 SW<  IRQ 3
> > >   3266 FF      37  -5  77  0.0 SW<  IRQ 6
> > >
> > > [root at Godzilla root]#
> > >
> > > NOTE: I would think that I'd want IRQ11 to be the highest priority
> > > behind system functions, followed by IRQ's 5 & 10 to give me fast disk
> > > access. How can I accomplish this?
> > 
> > You can change the priorities yourself using the "chrt" command, for
> > example:
> >   chrt -f -p 43 411
> > (should change pid 411 to "f"ifo priority 43)
>
> Fernando,
>    Thanks for the hints. A few questions:
> 
> 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). 

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

100 is highest

> 4) What's the difference between RTPRIO and PRI?

I don't know. 

> After my reboot it seems that these status is almost nonsensical. Why
> is IRQ10 so high? (Assuming high numbers mean high priority.)
> 
>  [root at Godzilla root]# /etc/init.d/rtirq status
>  
>   PID CLS RTPRIO  NI PRI %CPU STAT COMMAND
>   242 FF      80  -5 120  0.0 SW<  IRQ 8
>   407 FF      60  -5 100  0.3 SW<  IRQ 10
>  1151 FF      60  -5 100  0.0 SW<  IRQ 5
>    20 FF      59  -5  99  0.5 SW<  IRQ 9
>   344 FF      50  -5  90  0.0 SW<  IRQ 1
>   263 FF      49  -5  89  0.0 SW<  IRQ 12
>   303 FF      46  -5  86  0.0 SW<  IRQ 14
>   305 FF      45  -5  85  0.0 SW<  IRQ 15
>   411 FF      42  -5  82  0.2 SW<  IRQ 11
>  2533 FF      40  -5  80  0.0 SW<  IRQ 7
>  2555 FF      39  -5  79  0.0 SW<  IRQ 4
>  2556 FF      38  -5  78  0.0 SW<  IRQ 3
>  4061 FF      37  -5  77  0.0 SW<  IRQ 6
>  
> [root at Godzilla root]# cat /proc/interrupts
>            CPU0
>   0:    2665407          XT-PIC  timer  0/65407
>   1:       3583          XT-PIC  i8042  0/3583
>   2:          0          XT-PIC  cascade  0/0
>   7:          1          XT-PIC  parport0  0/1
>   8:          1          XT-PIC  rtc  0/1
>   9:     398235          XT-PIC  acpi, hdsp  0/98235
>  10:     790661          XT-PIC  ohci1394, eth0  0/90661
>  11:     385876          XT-PIC  ohci1394  0/85876
>  12:      91249          XT-PIC  i8042  1/91249
>  14:      25616          XT-PIC  ide0  0/25615
>  15:         51          XT-PIC  ide1  1/50
> NMI:          0
> LOC:          0
> ERR:          0
> MIS:          0

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. 

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

-- Fernando