Re: NI 6602 - comedi_data_read(..) takes 4ms (RTAI 3.3)

Hello Tobias,

I did notice that only one slot did not share IRQs, and moved my cards
around,
but this did not solve the problems.
   IRQ handling is not even supported with the ni_660x driver, so I have
also disabled
the IRQs completely, which does not make a difference either.
   What is interesting though is that the PCI-DDA08/16 seems to be
completely immune
to these latencies.
The differences between are:
* NI 6602 (digital I/O) has an "IRQ-line", but is not supported by Comedi.
I'm using comedi_data_read() only
* PCI-DDA08/16 (analog out) does not have an "IRQ-line". using
comeid_data_write() only

regards,
Camino

On 3/30/06, Bruckmann, Tobias <bruckmann_at_mechatronik.uni-duisburg.de> wrote:
>
>  Just an idea...: use another PCI slot to avoid IRQ sharing...? Maybe your
> motherboard manual will tell you which slot doesn't share - in my case, one
> slot has its own IRQ and doesn't share.
>
> Regars,
> Tobias
>
> -----Ursprüngliche Nachricht-----
> *Von:* rtai-admin_at_rtai.org [mailto:rtai-admin_at_rtai.org]*Im Auftrag von *
> janne
> *Gesendet:* Donnerstag, 30. März 2006 14:04
> *An:* rtai_at_rtai.org
> *Betreff:* NI 6602 - comedi_data_read(..) takes 4ms (RTAI 3.3)
>
>  (This was originally posted to the Comedi mailing list. Obviously this
> has to do more with hardware configuration etc. rather than Comedi).
>
>  The network card I am using is Intel Pro/100 VM, which appearently gives
> latencies
> around 250us every 2 seconds. Something else seems to give me those nasty
> 4ms
> problems, any suggestions on how to pin-point this device?
>
> Also, I have graphs about the execution times if someone wants to see
> them, I will e-mail them to you.
>
> If you don't want to look at the Comedi mailinglist (it has the same title
> as this thread), the most important
> posts have been included below.
>
> Original post:
> ------------------
> Hello people,
>
> I am using:
> * RTAI 3.3
> * NI 6602  (For encoders only)
> * PCI-DDA08/16  (for Analog output)
>
> I'm running a single task (about 4KHz) that reads encoder values and
> ouputs an analog signal.
> When running for 20 seconds, there are usually a few instances ( 1 - 3)
> where reading values
>  from the encoder takes about 3800 - 4000 us. Which is, of course awful.
> Without these, the
> maximum is about 60us.
>    I have disabled as much hardware as possible from the computer, but
> still the problem remains.
>
> Does anyone have any clue on what I should look at?
> Hopefully this is a common issue with a common solution...
> ------------------
>
> There was a question how the measurement of the execution times were made:
>
> -----------------
> The procedure is to simply call rt_get_cpu_time_ns(); in the beginning of
> the task,
> immediately before and after reading encoder values, and subracting the
> difference.
> Same thing with Analog out,  and finally at the end of the task for total
> Task execution-time.
>
> Another interesting issue was found. Reading the encoder also has ~~200us
> execution time
> every two seconds if the ethernet cable is connected during boot time. The
> analog out or the
> rest of the task's execution times are not affected.
>    It really seems like there's a conflict of some sort. Whether this has
> to do with the comedi-driver
> or the hardware, I do not know.
>    I will e-mail you a graph shortly showing the behavior of the task. (If
> someone else is interested to
> see it, notify me).
>
> Worth mentioning is that unlike the regular 2 second ~~200us execution
> times, the really nasty 4ms
> delays are not regular at all.  But usually comes 1-3 times within 20
> seconds without much pattern.
> -----------------
>
> To which Derek Foreman replied with the following:
> -----------------
> This might not be at all helpful, but I've seen fairly large latencies
> created by lots of hardware...
> (I use different cards, and one of my acquisition cards isn't driven by
> comedi at all)
>
> Specifically:
> an on board (but still on the same bus as the pci slots, disgusting) sata
> chip (on chipset IDE controller has no such issue).
>
> an intel pci gigabit ethernet card on the same bus as the acquisition
> cards (removed, on chipset 100mbit NIC is tolerable.)  I suspect a lot of
> on-board chips are on the pci bus with the slots and can cause latency.
>
> an agp geforce 4 card.  I had to disable all textual output as well as the
> console blanker to fix this.
>
> To me, untolerable latency is > 50uS in servicing the NMI.
>
> The graphics card was creating several hundred, maybe several thousand uS
> delays.
> ------------------
>
>
>
> regards,
> Camino
>
>
>