RTAI Timing Problem
 

I have an interesting problem about a program I'm writing for research at Michigan State University. Our goal is to create an RTAI linux computer which uses comedi drivers to take samples off a board from an experiment in the lab. The basic problem is that, once we exceed 4 or more inputs it essentually takes twice as long to take each sample than if I used 3 or less inputs into the board. I don't understand how this can be at all. Looking through data we collect, we can see that in nanoseconds the time it takes for each sample really is about twice as long as it should be, even though the program itself is counting how many samples we want and storing them correctly.

Does anybody know what could be the problem? The program itself is set up as follows: Using a user space QT based program we start the program and input on the graphical screen all of the information needed to run the program. Then, using a structure, this information is sent into the kernel space program to run the sampling for our experiment and relayed back into the user space program for storage using FIFO's. Please let me know what I can do - basically I think I'm asking for help in developing the most stable algorithm as possible for making sure each sample happens when I want it to during each run.

Ideally I'd like to be able to use all inputs / outputs on the computer so please let me know what I can do. Let me know if you want to see any code, although I can tell you right now the problem is only in the kernel space program (or maybe RTAI?), not in user space (and the kernel space program is very short, the bulk is the for loop that controls how many samples to take, what sub-device and channel to take the sample at, and then the fifo lines to send the data to the user space).

-Chris

Hi -

Strong suggestion:

a) Invest a couple of hours learning a code profiler (for example, gprof)
b) Recompile your application with profiling enabled
Rebuild the Comedi source (at least the user-space libraries, not the kernel portion) and make sure your Comedi calls are included in your profile
c) Try profiling your application
d) Determine if you're compute bound (e.g. excessive polling activity) or I/O bound (e.g. excessive latency waiting for I/O)
e) Determine if the problem is in your code, in Comedi, or "someplace else"

In general, you *definitely* want to acquire your data in such a way that you *BLOCK* on I/O (whenever, wherever possible), and that you poll for data ONLY as a last resort, if there's no other way around it.

You'll probably also want to post some queries to the Comedi mail group - they're both knowledgeable and responsive.

Good luck .. PSM

paul,

Thank you for the reply, however, I'm afraid I don't really understand anything you said. I'm actually an electrical engineer so I've learned everything I know pretty much by myself. Is there a source you would recommend to look at that I can read about your suggestion? Let me know if you get the chance.

-Chris

Hi -

Sorry about that. Here's what I was trying to suggest:

1. It sounds like the problem has to do with "performance".

Since you're an EE (hence comfortable with math), this book might be of interest to you:
The Practical Performance Analyst, Neil Gunther
http://www.amazon.com/gp/product/059...lance&n=283155

2. But before you do any analysis, you need to get some numbers.

That's where "gprof" comes in.

You can add special flags when you compile your program that that, as it runs, certain statistics will be accumulated. Then you can dump these statistics to try to figure out why your program isn't executing as quickly as you expected it to.

Here is a nice, short tutorial on gprof. You can easily google for many others:
http://badgertronics.com/writings/gprof.html

3. If things are "taking a long time", then you'll generally find it's for one of two reasons:

a) Either the application is "compute bound" (in which case you'll see high CPU usage,
and quite probably one particular subroutine called an excessive #/times)
... or ...
b) The application is "I/O bound" (in which case you'll see *LOW* CPU usage, and
quite probably one particular subroutine will show excessive wait times).

4. From there, you need to figure out *what* is wrong.

It's probably less a problem with comedi (although that's certainly possible), than a
problem with the way you're using comedi (for example, excessive polling: constantly
looping to check if some data is available).

5. Finally, I suggested you might want to join the comedi mailing list. You can do so from the comedi web page:
http://www.comedi.org

'Hope that helps .. PSM