[LAU] optimal disk performance, ubuntu

[Mike Mazarick]

I was reading over this thread while researching a fix for my problem.   I
thought I would share what I happening on my machine, and hopefully it will
provide you with some insight into your situation.   I don't have the answer
yet, but maybe I can provide a different view of what the problem is.

 

I am currently trying to get 4 PCI cards with 8 channels to work with a new
motherboard (MSI Neo 3FR).   I also have an nvidia GeForce 9600 NGO video
card, an Intel Core2 Extreme Quad processor, 4 GB of memory, and 4 Sata II
disks installed.   I am currently running Fedora Core 8, with CCRMA
modifications for sound.   The audio card is an old Gadget Labs card, and
there is a linux driver, but it isn't part of the Alsa tree yet.   I have to
compile and install a module to make the Gadget Labs cards work.

 

I can easily get 3 cards working (24 channels), but I am needing to do some
'black magic' to get 4 cards working.   I am not getting any sound out of
the fourth soundcard.  So far, it sounds familiar, doesn't it? (not enough
channels coming out).      One of the benefits of having the new linux
driver is that there is already some basic diagnostics built into the
driver, and you can see reports in /var/log/messages of how long it takes to
open or close the card to it's memory buffer.   This was originally used
because the interface chip was so old that it didn't have DMA, and a
'software DMA' had to be written, and this was the mechanism to test the
card/driver and figure out its performance.

 

For my particular system, because I can run a test and see the driver
performance in /var/log/messages (I'm using Jack/Ardour for 'high level
stuff,  aplay, arecord, etc for low level stuff), I have seen that the video
card driver is sending a bunch of interrupts down the PCI bus (even though
it is on PCI Express).   The particular driver that is sending the
interrupts down the PCI bus is called NV, and is an open source
implementation of NVidia drivers.  I get rid of all graphics by issuing
'init 3' instead of being at the normal runlevel 5 (graphics).

 

As an example for playback only, here are some statistics for one card in
the graphics mode:

[root at localhost tmp]# cat /var/log/messages |grep ISR

...

Dec 13 12:18:23 localhost kernel: api_gl824_stop ISR took between 47 and 137
samples

Dec 13 12:18:23 localhost kernel: api_gl824_stop Buffer transfers TO CARD
within ISR took between 11 and 100 samples

Dec 13 12:18:23 localhost kernel: api_gl824_stop Buffer transfers FROM CARD
within ISR took between 35 and 125 samples

(There is a  128  sample-memory on the card.  It is easier to deal with
samples than time, so the 44100khz or 48000khz can be scaled more easily.
What you are seeing is that I am about to run out of time on the PCI bus if
I only have 128 samples to play with)

 

When I go to a non-graphics mode with init 3, I get the following results:

[root at localhost tmp]# cat /var/log/messages

...

Dec 13 22:03:22 localhost kernel: pcm_gl824_output_trigger 0

Dec 13 22:03:22 localhost kernel: api_gl824_stop Master card's clock
position stopped at 1540

Dec 13 22:03:22 localhost kernel: api_gl824_stop ISR took between 2 and 4
samples

Dec 13 22:03:22 localhost kernel: api_gl824_stop Buffer transfers TO CARD
within ISR took between 2 and 4 samples

Dec 13 22:03:22 localhost kernel: api_gl824_stop Buffer transfers FROM CARD
within ISR took between 0 and 1 samples

.

Dec 13 22:07:48 localhost kernel: pcm_gl824_output_trigger 0

Dec 13 22:07:48 localhost kernel: api_gl824_stop Master card's clock
position stopped at 1932

Dec 13 22:07:48 localhost kernel: api_gl824_stop ISR took between 10 and 12
samples

Dec 13 22:07:48 localhost kernel: api_gl824_stop Buffer transfers TO CARD
within ISR took between 10 and 11 samples

Dec 13 22:07:48 localhost kernel: api_gl824_stop Buffer transfers FROM CARD
within ISR took between 0 and 1 samples

Dec 13 22:07:48 localhost kernel: pcm_gl824_output_hw_free

Dec 13 22:07:48 localhost kernel: pcm_gl824_output_close

 

What this means is that some interrupt in the graphics mode was taking up
all the PCI bus.

 

Now, further testing in nongraphic mode revealed that there is still an
issue with hard disk interrupts taking up a lot of PCI bus time.

I'm running arecord and aplay for about 30 seconds to see what the
performance is.   I'm recording and playing back 8 channels at once in the
32 bit noninterleaved mode.  After I record 8 channels for about 30 seconds
with arecord (creating one honkin' big file) and playing it back with aplay,
I get the following stats when looking at the output of the card:

 

Dec 14 09:39:15 localhost kernel: pcm_gl824_output_trigger 0

Dec 14 09:39:15 localhost kernel: api_gl824_stop Master card's clock
position stopped at 397

Dec 14 09:39:15 localhost kernel: api_gl824_stop ISR took between 11 and
1498 samples

Dec 14 09:39:15 localhost kernel: api_gl824_stop Buffer transfers TO CARD
within ISR took between 0 and 98 samples

Dec 14 09:39:15 localhost kernel: api_gl824_stop Buffer transfers FROM CARD
within ISR took between 0 and 39 samples

Dec 14 09:39:15 localhost kernel: pcm_gl824_output_hw_free

 

This means that there are still interrupts happening on the PCI bus while
the card is trying to play.   I'm reading the following link to determine
what is the best next thing to do, but I'm also looking at a modern
equivalent to 'hdparm' (and maybe hdparm if I can get it to work with my
Sata disks).

 

Here's a link that gives an approach to solving the problem:

http://www.gentoo.org/doc/en/articles/hardware-stability-p2.xml

 

In my opinion, the problem I'm having is because the hard disks are 'too
fast' with 'too much priority' and are taking up too much bandwidth on the
PCI bus.   You may be having the same thing happen.   It may be that instead
of your problem being that your disks are too slow, the real problem is that
your disk may be too fast.   I remember having very severe problems with
disk interrupts when I first started using this software and scsi disks on a
Sun V20z (which are much faster than IDE or SATA).   Once I switched to a
normal PC (with slower IDE disks), the underruns just disappeared.
Fortunately with that setup, you could actually hear the disks move and see
the underruns happen at the same time.

 

If anyone else has been down this road and knows of how to solve the
underlying issues (sata hard disk interrupts taking up too much PCI
bandwidth), I am still searching for an answer and I'm VERY interested in
hearing something from you.

 

Thanks in advance,

 

Mike Mazarick

 

 

If someone else has been down this road

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20081214/85655001/attachment.htm