[LAU] rtirq usage

[Patrick Shirkey]

On 09/05/2009 11:03 AM, James Cameron wrote:
> On Sat, Sep 05, 2009 at 10:05:04AM +1000, Patrick Shirkey wrote:
>    
>> Thanks for taking some time to consider this.
>>      
> Heh.  It's been my speciality for ten years on enterprise systems, where
> the configuration of everything is carefully controlled.
>
>    
>> The wifi device is connecting via pcie.
>>
>> It turns out that to get the xruns to a minimum it's necessary to
>> run jack at rtprio 89.
>>      
> It would be normal to assume that increasing jack's real-time priority
> may cause jack to respond to events sooner.
>
> On the other hand, what this might be doing is changing the timing of
> events associated with the wifi device.  You may have found a sweet
> spot.
>
> It can be a very complex cause chain, and it is very difficult to
> figure out what is actually causing it.  While using jack, a sound
> device, a wireless device, and a graphics driver, the events come thick
> and fast, and the order in which they occur could easily change the
> symptom.
>
> Is there network activity on the wifi device at the time?  Activity such
> as transmitting packets can cause interrupts to be delivered.  Activity
> such as receipt of beacons from another radio can cause interrupts as
> well.  Both these interrupt sources will be counted in /proc/interrupts.
>
> Is the wifi device acting as an access point, or a client?  As an access
> point the activity level is quite different ... it has to provide the
> beacons, which might not require an interrupt, but if it hears back from
> another radio it may have been configured by the driver to interrupt.
>
> Is the driver for the wifi device well known and considered stable?
>
> Is the graphics device on PCIe as well, or on a higher priority bus?  A
> graphics device can preempt the CPU for access to memory during either
> video output (shared model) or during DMA.
>
> My gut feel is that there is a pathological interaction between the
> drivers and the devices.  But this might only occur in your particular
> system.  Best thing at this stage is to prod at it and see what happens,
> gathering behavioural problem data, and checking for known bugs in each
> driver.  Or excluding the devices or drivers that are triggering the
> symptom.
>
> jack xruns are basically that the system could not keep up with the data
> flow demand ... but this says nothing about what the system is capable
> of if configured correctly by the drivers.
>
>    


These are very useful suggestions.

The video device is onboard and it does share the same physical irq as 
the audio device. However there is a boot time switch to move the audio 
device to a different irq in software at least. Setting that helped a 
lot but it was only changing the RTPRIO of jack that got rid of xruns. 
JACK definitely doesn't like the wifi card to be enabled as there are 
still occasional xruns. I think it's acceptable performance for the time 
being.


Cheers.

Patrick Shirkey
Boost Hardware Ltd