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

Wed Apr 13 11:12:01 2005

On Wed, 2005-04-13 at 10:22, Mark Knecht wrote:
> Fernando & other Planet inhabitants,
>    I have turned off Pro Tools for a few days and am trying to better
> configure my Planet box for more serious recording. The current setup
> is:
> 
> 1) Athlon XP 1600+/Via MB
> 2) HDSP 9652 
> 3) 1394 OHCI #1 - drive 1 & drive 3
> 4) 1394 OHCI #2 - drive 2
> 
>    My intention is to use the built in 'RAID-like' features in Ardour
> to split audio across multiple hard drives. I'm still in the process
> of getting that set up and tested, but in the process I'm not happy
> with *SOME* of the xruns I'm getting from this machine and I want to
> make sure I'm doing everything possible to get the best performance.
> 
>    Under normal, no load operation the machine runs fine with a
> setting of 64/2. I can run Aqualung and I see an xrun every few hours
> which is no big deal. However if I do copies from one 1394 drive to
> another 1394 drive with Jack running I am getting an xrun every 30
> seconds like clockwork. I do not know what's causing this and want to
> get rid of it.

I would imagine that this is some operating system initiated flushing of
dirty buffers to disk. There used to be something like that in 2.4
called bdflush, apparently obsolete in 2.6 (replaced by pdflush -
controlled directly by the kernel). See what you have in:
  cat /proc/sys/vm/dirty_writeback_centisecs

in my fc3 laptop this is "500", which would be 5 seconds so it does not
match the period you are seeing. 

[see:
http://edseek.com/archives/2004/07/12/linux-26-vm-procsysvm-tunables/]

...

a few minutes later: BUT
  cat /proc/sys/vm/dirty_expire_centisecs
yields "3000" which is 30 seconds!
Try changing that to a lower value:
  echo "1000"> /proc/sys/vm/dirty_expire_centisec

>    One thing I did notice was that when doing copies from one drive to
> another the machine was bumping up against 100% CPU. It typically was
> running at 70% CPU with spikes going higher. Possibly this is normal
> CPU usage as I'm sure Linux wants to copy the files as fast as it can.
> This may not be an issue during recording as Ardour will limit how
> much disk usage it requires. None the less I don't want xruns.
> 
>    OK, looking through older posts here by Fernando and others I'll
> post the info I can think of to show the state of the box:
> 
> [root@Godzilla root]# cat /proc/interrupts
>            CPU0
>   0:    6374396          XT-PIC  timer  0/74396
>   1:      11410          XT-PIC  i8042  2/11410
>   2:          0          XT-PIC  cascade  0/0
>   5:       9121          XT-PIC  ohci1394, ehci_hcd, uhci_hcd,
> uhci_hcd, uhci_hcd, eth0  0/9121
>   7:          1          XT-PIC  parport0  0/1
>   8:          1          XT-PIC  rtc  0/1
>   9:          0          XT-PIC  acpi, ohci_hcd  0/0
>   10:        645          XT-PIC  ohci1394  0/645
>   11:     573308          XT-PIC  ohci_hcd, hdsp  0/73308
>   12:     135937          XT-PIC  i8042  0/35937
>   14:      61930          XT-PIC  ide0  0/61929
>   15:       1428          XT-PIC  ide1  0/1427
> NMI:          0
> LOC:          0
> ERR:          0
> MIS:          0
> [root@Godzilla root]#
> 
> NOTE: There are no USB devices on this machine. I may end up disabling
> USB totally.
> 
> [root@Godzilla root]# cat /proc/asound/cards
> 0 [default        ]: H-DSP - Hammerfall DSP
>                      RME Hammerfall HDSP 9652 at 0xf4800000, irq 11
> [root@Godzilla root]#
> 
> [root@Godzilla root]# cat /proc/asound/version
> Advanced Linux Sound Architecture Driver Version 1.0.9rc1.
> Compiled on Mar 22 2005 for kernel 2.6.11-0.3.rdt.rhfc2.ccrma.
> [root@Godzilla root]#
> 
> [root@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@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