[clug] Any Timers Faster than 10ms?

[Darren Freeman]

On Wed, 2003-11-26 at 09:55, Carter, Michael wrote:
> Hi all,
> I'm trying to write some software for Linux that has some pretty accurate timing requirements. I know that in userspace you can get timers to wake up processes, but this seems to only be with a granularity of about 10ms, which is apparently how often there is a timer interrupt on IRQ0. However, what I'd really like is to be able to perform a task, sleep for a few hundred microseconds, and then perform another task. Are there any more accurate timers available in the kernel? Perhaps a timer exisits in an ordinary i386 architecture that can offer interrupts at a faster rate? Can I use gettimeofday() in anything other than a busy wait?

"pretty accurate timing requirements" => "use a real-time OS"

the best I know of in userspace on Linux is a while loop that waits for
events, running with maximum priority. At which point you might as well
kiss your system goodbye if you were using it as a desktop machine. Plus
you will get interrupts causing random latencies in your userspace code
anyway.

Your only hope IMHO is to write a kernel module that has an interrupt
handler, as you say, and find a good source of interrupts. I think 100
Hz is a pretty standard frequency on PCs although you might find
something faster in the hardware. Kernel timers give you the accuracy of
whatever the underlying hardware is, which from memory is 100Hz, but
don't guarantee that you get executed as the first tasklet in the timer
queue. If you can handle a few jobs sometimes running before you then
this would be OK, but still the resolution is 10 ms.

But you could try a timer card, or even use the parallel port to
generate interrupts with an external pulse source. The priority is
likely to be pretty low but as long as the system is sitting around
doing nothing there shouldn't be too many important interrupts coming
in. Be careful generating lots of interrupts though, if you want to wait
say 1234 us by counting each us you can end up hammering the system. If
you have some kind of programmable timer then you could just say "count
1234 and then interrupt". If you were using a timer/counter card for
your application anyway then maybe a timer output could go to your
parallel port for interrupts.

An interrupt will still trump a high priority task in userspace, but
there's not much you can do from within an interrupt handler. I presume
you are toggling outputs? You may end up simply waking up a task in
userspace from within the kernel. You would have high precision but then
lose it if this isn't the highest task trying to run.

Don't forget things like the low latency patch and pre-emptive kernel
patch. They bring you a lot closer to having an RTOS.

Also read the free book, "Linux Device Drivers" second edition, O'Reilly
website.

> Thanks,
> mick

Have fun,
Darren