1
votes

I have a task which is basically a TIMER; so it goes to sleep and is supposed to wake up periodically.. So the timer task sleeps for say 10ms. But what is happening is that it is inconsistent in waking up and cannot be relied upon to awaken in time correctly.

In fact, in my runs, there is a big difference in sleep times. Sometimes it can vary by 1-2 ms in awakening and very few times does not come back to at all. This is because the kernel scheduler puts all the sleeping and waiting tasks in a queue and then when it polls to see who is to be awakened, I think it is round robin. So sometimes the task would have expired by the time the scheduler polls again. Sometimes, when there are interrupts, the ISR gets control and delays the timer from waking up.

What is the best solution to handle this kind of problem?

(Additional details: The task is a MAC timer for a wireless network; RTOS is a u-velOSity microkernel)

3
Where does the RTOS come into this question? You mention u-velOSity at the end, but it seems entirely irrelevant to the question asked where it is not mentioned at all. - Clifford

3 Answers

2
votes

You should be using the timer API provided by the OS instead on relying on the scheduler. Here's an introduction to the timer API for Linux drivers.

1
votes

If you need hardcore timing, the OS scheduler is not likely to be good enough (as you've found).

If you can, use a separate timer peripheral, and use it's ISR to do as little as you can get away with (timestamping some critical data, set some flags for example) and then let your higher-jitter routine make use of that data with its less guaranteed timing.

0
votes

Linux is not an RTOS, and that is probably the root of your problem.

You can render Linux more suited to real-time use in various ways and to various extent. See A comparison of real-time Linux approaches for some methods and an assessment of the level of real-time performance you can expect.