ChibiOS Free Embedded RTOS

I took at a look at ChibiOS/os/various/evtimer.c, and it implements the last idea presented here using virtual timers:
http://www.chibios.org/dokuwiki/doku.ph ... :kb:timing

The issue is that the timing will always be off due to the execution time it takes to get to the place where the one shot timer is reprogrammed, and also if you get preempted with a higher priority interrupt before you can set the next one shot timer. Is there a way to essentially have the accuracy of a hardware periodic timer using the virtual timer subsystem?

For example, when a virtual timer interrupt fires perhaps the output compare value of the timer is provided as part of the context for the virtual timer callback. If that value could be used, then one could simply add the next interval to that value. Thereby, the timing accuracy of a periodic timer using the virtual timer would be as good as the hardware timer. The output compare value (for use in the context of next virtual timer event) could be stored when the timer is configured for the first time. Then, when starting the virtual timer again, the object would contain the last output compare value - to be optionally used as the starting time of the requested duration.

Hi,

This is a good point, VTs have been designed as one-shot timers only and, when using high resolution time, there could be an accumulating error.

Perhaps VTs should have a periodic mode built-in, without having to reload the timer from the callback. The drawback would be that the timer object would become larger.

I need to look into details, the implementation would not be straightforward in tick-less mode.

Giovanni

I find I've always got a spare timer to use as the base for things like this; adding a virtual timer to the list takes an indeterminate (and possibly significant, if you have lots of VTs) time to add to the list, so I prefer to avoid the overhead, especially for short times. (Plus doesn't rescheduling VTs require the system to be locked, increasing interrupt jitter?).
Depends a bit on the time period required.
I've also been conscious that a need for a regular 'tick' can rather negate the point of tickless mode.

Of course processing a virtual timer takes longer that just serving an HW timer.

About jitter, VTs use a delta list structure, only the first element on the list processed but the algorithm is not executed in constant time. If it happens that multiple timers elapse around the same tick ("around" because the delta parameter) then complexity is N, it is that loop where callbacks are called. It is not frequent but the jitter upper limit increases linearly with the number of active timers.

The problem is not much jitter but the accumulation of errors if you re-arm the timer from its own callback. This is only an issue when the system time frequency is very high, you could spend some ticks executing the callback and the error accumulates over time, and this is the issue Faisal was concerned about I think. This could be solved with a "periodic mode" where timers rearm automatically based on the latest deadline and not "current time".

Giovanni

Giovanni wrote:Hi,

This is a good point, VTs have been designed as one-shot timers only and, when using high resolution time, there could be an accumulating error.

Perhaps VTs should have a periodic mode built-in, without having to reload the timer from the callback. The drawback would be that the timer object would become larger.

I need to look into details, the implementation would not be straightforward in tick-less mode.

Giovanni

I agree, having a built in periodic mode for a virtual timer is good idea. Other RTOS's have this feature, and when the built in feature is not available, we typically have to roll-our-own implementation or use a dedicated hardware timer. It's not an uncommon pattern to have periodic timers which send events to various tasks in the system running at different rates. If the existing virtual timers can be used which guarantee the same accuracy as the system tick timer - that would be great.

It''s important that this feature work in tickless mode too.

Thanks for considering this and looking into it Giovanni!

Giovanni wrote:The drawback would be that the timer object would become larger.

This could be mitigated with a compile time kernel option to enable virtual timers to be optionally configured as periodic timers.

Giovanni wrote:About jitter, VTs use a delta list structure, only the first element on the list processed but the algorithm is not executed in constant time. If it happens that multiple timers elapse around the same tick ("around" because the delta parameter) then complexity is N, it is that loop where callbacks are called. It is not frequent but the jitter upper limit increases linearly with the number of active timers.

I was thinking more about the time involved in adding a VT to the list - especially if the delay of the VT is long compared to those already on the list, it can take a relatively long time to find the right place to insert the new timer.

Correct, that has complexity N as well.

Giovanni

Any update on this?

Hi Faisal,

It is in the TODO list for RT7, the implementation is not trivial in tickless mode if you don't want the error to accumulate.

I will give it a try after finishing the SMP-related work.

Giovanni