Somewhat OT: Efficient timing under Linux

Usually signal handling is fast, context switching and event delivery time is in the microsecond range depending on your system clock, but I don't know how good the itimer concept works.

I've done a similar loop once in an user mode app with the help of my own Linux driver: I'm calling an ioctl in the driver, which in turn sleeps and the process wakes up, triggered by an interrupt, each 16 ms for VSync. This worked even with multiple threads in the user mode app, if you change the thread priority of the loop-thread to a high value. Jitter is most of the time below 1 ms (this depends on the other drivers in your system).

But of course, Linux doesn't guarantee it, so it might wait longer sometimes. If you can live with a delay of some more milliseconds sometimes, it is possible. Don't do it, if you want to control a motor or something like this.

itimers devolve to spinlock() calls. I would consider them to be pretty low overhead. frankly, I find select()/pselect() with the timer arguments filled in good enough, but I'm not in a position where jitter matters much nor where CPU utilization is much at issue.

You can always write a device driver than owns the hardware timer and hits callbacks. I would be more concerned about the nonblocking nature of the above loop... I figure on one nonblocking timer poll loop per CPU at most.

As a gross generalization, those quickly turn to pthreads() discussions.

At the "low tens of milliseconds" level, the context-switching overhead shouldn't be significant. Typical time slices are between 10ms (for servers and systems with relatively expensive context switches) and 1ms (for low-latency desktop systems).

I worked on a project that seemed to be doing well doing significant data- mangling in multiple processes in a 5 millisecond loop. Differed from yours in that the 5 milliseconds was based on hardware interrupts from the device that generated the data. I haven't seen it scaled up to full workload, but the simulations we had running at the time suggested that things were good. Ran stock Debian 5 on an 800 MHz i86. Extra-low niceness was granted to the processes that had to be fast.

Mel.

Right, and 10 ms is common for some embedded systems. And if there is no process with 100% load, processes which waits for IO or events are activated much faster than the time slice time, when data arrives or an event is generated.