(see also should you be using monotonic timers?)
Have you ever wondered what is the best way to implement periodic tasks in Linux applications — something better than usleep()? This article covers a number of issues related to this subject including real-time tasks, the different timers available, timer resolution, and how to implement periodic tasks accurately so that error is not accumulated. The recent inclusion of the high-resolution timers in the mainstream kernel makes this a very interesting subject.
High Resolution Timers
Historically Linux has done all timing off the OS timer tick which is usually between 1ms and 10ms. While this is adequate for many tasks, it is really nice to have a high resolution timer for timing tasks. With the integration of the high resolution timers into the mainstream Linux source tree, this is now possible. From a user space perspective, there are no API changes. The only difference you will notice is that now you can sleep for less than OS timer tick period. clock_getres() can be used to check the timer resolution and will tell you instantly if you have high resolution timer support. If the clock resolution is 1ns, you have high res timer support. Realistically, you can’t delay for 1ns in a Linux application, but delays in the range of 100us should be possible, and depending on the configuration, much better performance is possible. The kernel config entry for high resolution timers is CONFIG_HIGH_RES_TIMERS.
The difference between CLOCK_REALTIME and CLOCK_MONOTONIC
Some of the Linux timer functions take a clockid_t argument that can be specified as CLOCK_REALTIME, or CLOCK_MONOTONIC. The big difference between these two is that changing the system time will have an affect on CLOCK_REALTIME, thus affecting your timers. Changing the system time will have no affect on CLOCK_MONOTONIC — it will always count upward. For periodic tasks, CLOCK_MONOTONIC may be more applicable. The best way to get burned using CLOCK_REALTIME is when your application takes a timestamp, does something, takes another time stamp and then compares them. If you are using CLOCK_REALTIME, and the system time gets changed between the two timestamps, your comparison will not be valid. For most timeouts and relative timekeeping in Linux, use CLOCK_MONOTONIC. This issue becomes more important as many systems now have a process that periodically sets the time automatically from network time servers, and you have no idea when this might happen.
Preemption
Kernel preemption (http://bec-systems.com/web/content/view/69/9/ ) makes a huge difference in the performance of real time applications by allowing the kernel to be preempted by higher priority application processes. Historically, any kernel code that was runnable ran before the kernel returned control to applications. This all changes with kernel preemption. Kernel preemption has been available in mainline kernels for some time now (I think since 2.6.16). The worst offender I’ve found for locking the kernel for long periods of time have been flash drivers — especially proprietary ones. But, even jffs2 can cause problems in realtime applications without kernel preemption.
The PREEMPT_RT patch
Much of the realtime work being done for Linux is maintained in the PREEMPT_RT patch. Bits of this patch have already been merged into the mainline kernel, but there is still a lot of very useful functionality in the patch and it should be considered if you are doing any type of realtime work. More details will be presented in a future article.
Absolute vs Relative timekeeping
When implementing a periodic task, you really want to base your timekeeping off an absolute time, versus relative delays such as usleep(). It is not possible to achieve precise periodic activation with a relative sleep such as usleep(). The reason for this is you must first get the current time, make a calculation to determine how long to sleep, and then call the relative sleep function. If your process gets preempted between the time you acquire the timestamp, and the sleep, your relative sleep time will probably be wrong. This problem is solved by using the clock_nanosleep() function. clock_nanosleep() can be called with the TIMER_ABSTIME value in the flags argument. If the TIMER_ABSTIME flag is set, then clock_nanosleep() will sleep until the absolute timer value is reached. It does not matter if you get preempted between the time you take a timestamp, and the sleep function.
Summary
In summary, if you want to implement accurate, realtime, periodic tasks in a Linux application, consider the following:
- Use high resolution timers. Although Linux is still limited in its response time, at least the scheduling resolution is now quite high.
- Enable kernel preemption. This makes sure long kernel processes don’t get in the way of your real-time application process.
- Use the CLOCK_MONOTONIC for relative timekeeping. You don’t want your application to lock up due to the system time changing.
- use the clock_nanosleep() function instead of relative delays like usleep(). This is the only way to accurately schedule periodic tasks.
- if needed, apply the PREEMPT_RT patch.
The clock_nanosleep man page also includes a lot of useful information about timer functions.