Losing interrupts

on a

I have

If you present your findings (losing interrupts), a competent manager should be willing to reconsider the needs and requirements. If not, goes to his boss and keeps going up.

the low

getting lost

If your interrupts are blocks, your drivers would not see anything. There are no magics in the rest of the kernal.

Not in real time, any monitoring process will alter the system anyway.

At the very minimium, you need to compile and patch a custom kernel.

That is not unusual. The interrupt latency in Linux is quite low (though not deterministic: no max can be given). But the Kernel does block applications for huge periods (several 100 msec if you are in bad luck) from time to time. Do you use Kernel 2.6 ? Same is said to offer a much better "soft realtime" behavior than previous versions.

Did you do your own interrupt device driver ?

As you do have the source code you can add some outputs to a port in the driver, even if it comes with the Kernel.

What do you think monitoring the interrupts will get you ? Do you need to know if the hardware works correctly ? You can't help the latency of the application. If you need an application to react within a defined period, pure Linux is not the way to go. Here you would need to add RTAI or something similar.

-Michael

BTW.: what are you trying to accomplish ?

-Michael

I am interfacing a set of continuous wave radars to an AD converter board and a PC104 (transmeta crusoe 600Mhz) system.

Does the AD converter board issue an interrupt with any value acquired and you need to read it before it gets overwritten by the next value ?

That technology is not suited too well to be used with Linux (or Windows). Here a hardware FIFO or a (bus master) DMA would be better.

If you don't want to use RTAI, your best bet is to write a device driver that reads the value in the interrupt service function and puts it in a FIFO. The user land software would use standard file read requests on the driver to read the FIFO. The driver would block if no value is available. Thus the user land program can either hang until one or more values are ready or use select() to bypass the read in order to prevent hanging.

So you'll only see the max interrupt latency, that is _much_ smaller than the max application latency.

-Michael

Approximately, what is the time between interrupts generated by your hardware?

What sort of latency time are you seeing at the moment? from your AD converter generating an interrupt, until when your software services your hardware?

board

acquired

A micro-controller front-end would be far better and cheaper.

driver

more

prevent

That's not going to work, if he is already losing interrupts.

The solution is to buffer your samples (micro-controller) and lower your kernel latency (near real time patches). The near real time patches reduced latency greatly, especially for the hard disk, where most of the long delays are generated.

Right. That is what I would do, too. But here you would not use an "AD controller board" but design a µC Board that is connected to the PC by USB or Ethernet.

His question was, how to find out if he is loosing interrupts. I doubt that he really is loosing interrupts.

Of course this will work.

I doubt that they will reduce the interrupt latency. The application latency is greatly reduced (though you still cant give any max) which might be important here, if the values are not only logged but some fast reaction of the system is desired.

-Michael