[Xenomai-help] Non RT PCI device driver vs interrupts (go with rtdm...)

[Xenomai-help] Non RT PCI device driver vs interrupts (go with rtdm...)

[Hubert Talbot]

Finally, I got the precision I expected. The problem was on the way the results were reported.

However, more the frequency of the pulse generator is raised, less the results are good.

I think it is time to go with rtdm...

Thanks

Hubert

Re: [Xenomai-help] Non RT PCI device driver vs interrupts (go with rtdm...)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Hubert Talbot wrote:
> Finally, I got the precision I expected. The problem was on the way the results were reported.
> 
> However, more the frequency of the pulse generator is raised, less the results are good.
> 
> I think it is time to go with rtdm...

RTDM is no magic bullet /wrt latency or jitter. You should try to 
understand what you are measuring first before blindly replacing 
something. I'm surely not saying porting to RTDM is a bad idea, but I 
may not help you with what you are actually looking for.

What do you mean with "less good"? What frequencies are we talking 
about? What is the critical code path (already considered to use some 
tracing tool for analysis?)?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-help] Rép. : Re: Non RT PCI device driver vs interrupts (go with rtdm...)

[Hubert Talbot]

Hi Jan,

I am looking for realtime solution.

As I said before, I want to make a proof-of-concept with Xenomai.

Here is my use case:

A "Fluke 741B Documenting Process Calibrator"
(http://ca.fluke.com/caen/products/Fluke+741B.htm?catalog_name=FlukeCanada&Category=PCL(FlukeProducts)) 
sends pusle to I/O Sensoray 626 card. On pulse reception, card generates interrupt which is processed by an rt_task.

The program is simple. Mainly, it initialzes the board and creates two rt_task.
One for interrupt processing and the other for "sleeping" (2 secs).

The interrupt processing rt_task looks like:

while (!end)
{
   rt_intr_wait();
   S626_InterruptStatus();
   if (status)
   {
      ++count;
   }
   S626_DIOCapReset()
   S626_InterruptEnable()
}

The calls to S626_ functions ends up to ioctl calls.

I think that calling these functions leads to execution mode switches.

Running program for different frequencies gives after two seconds:

     pulse (KHz)           count          expected        lost (%)
      
          1                      2001            2000               ---
          2                      3996            4000               0.1
          3                      5989            6000               0.18
          4                      7975            8000               0.3125
          5                      9581            10000             4.19
          12                    10454          24000             56.44
          20                    12058          40000             69.86

Processing interrupts is the first step of the proof-of-concept.


Thanks

Hubert


>>> Jan Kiszka <jan.kiszka@domain.hid> 2008-02-25 03:14 >>>
Hubert Talbot wrote:
> Finally, I got the precision I expected. The problem was on the way the results were reported.
> 
> However, more the frequency of the pulse generator is raised, less the results are good.
> 
> I think it is time to go with rtdm...

RTDM is no magic bullet /wrt latency or jitter. You should try to 
understand what you are measuring first before blindly replacing 
something. I'm surely not saying porting to RTDM is a bad idea, but I 
may not help you with what you are actually looking for.

What do you mean with "less good"? What frequencies are we talking 
about? What is the critical code path (already considered to use some 
tracing tool for analysis?)?

Jan