I am programming an application which must execute its code periodically every 10 ms. It runs fine, but from time to time there is a latency in the period of between 20 ms and up to 90 ms. This means that I miss several periods. I've used 'strace' to check this issue, and the kernel system calls take as little time as expected, but sometimes there is the afore mentioned lag between two system calls.

The application intensively uses the CPU (it handles I/O via polling mode), which makes me suspect that a task switch might be happening. I would like some help on the following:

a) How could I get to know if other processes are assigned the CPU while my application is running? And which are these processes?

b) Could I alter the priority of my application/process so that it runs at higher priority than any other task in the system? One problem here is that I am communicating with an external board (using a device driver via PCI bus) and with external applications via sockets, and they seem to get stuck if I set the priority to highest possible value.

c) How could I control the instant my process is scheduled in multitasking Linux? I wouldn't like to execute the code as an interrupt because each period run may take long time (of course, below 10 ms) and I was expecting that Linux would handle this the multitask issue.

OS: RedHat 9 - Kernel: 2.4.20-189rxv

Any help would be much appreciated.

Best Regards,
Javier

You have to use a real-time OS for this. The standard Linux kernel is not one. I believe there is an RTLinux branch that may be more useful for this sort of thing. Or you could use QNX.

I am not sure of the system, whether RT or just RH. But from what you said "but from time to time there is a latency in the period of between 20 ms and up to 90 ms", it is not likely to be a problem of the system, for I remember the Maximum latency of Non Real Time Linux is about 20ms, and the latency is not only caused by the priority level.

You mentioned you are polling the I/O port. So it is possiblly where the problem resides. In which way you are dealing with the port? using the low level I/O function? POSIX? Are you sure the write() or read() function return in any case?

Hope those might help.

I am using high-level functions for the socket side, such as recv and send; for the board, the driver provides an API which in turn ends up calling low-level functions.

The I/O functions don't take so long to execute, some tenths of microseconds, although 'recv' sometimes generates a EAGAIN error.

I also understand that the Linux version I am using is not a real-time one, but could any tell me how to find out which other processes consume CPU time in a certain interval, maybe removing these processes my application runs well.

Also, I have noticed that the latencies are much lower if the socket client is running in the same machine. Could any tell me where I could find some info on how sockets work? Specifically, I would like to know if sockets delay I/O in any occasions and the reasons for such behaviour.

Thanks for all your help.

Socket? You mean the net card? I was thinking you are using serial, parallel, or some like these.

In this case, from my experience, using lower level function (protocol) could reduce the latency greatly. For instance, windows is NOT a real time system. I built two small program piece on socket commumication. (they do the same job) One in VB, one VC++. The latency caused by these two are obviously different. Though I have no equipment to test, the program by VC++ shows much less latency than the one from VB. I think it is better to ask the driver provider on this question.

Are you running your program in Gnome or KDE? There is a tool showing the processes running on your computer.

Actually, there is no guarantee that your process will ever get processor time, no matter what the priority is. Unless we're talking about a 2.5/2.6 kernel here, in which case I'm still pretty sure there's no measurable "max latency" time, but there may be things in place to assure that processes never starve for CPU time now.