vtimer implementation

Development archive
1

Hi *,

some of you may knows that there several problems in the vtimer at the moment. I would like to ask you to report issues you have spotted and also comment my suggested changes.

Issues I know: * long_term is everytime 4096 seconds, regardless if the hwtimer is able to measure this amount of time * seconds are only updated on long_term (each 4096 seconds) * vtimer is not tickless (through long_term) * When setting two timers very close to each other the second is sometimes never called * shortterm_queue_root.next is not set in every case update_shortterm is called * The maximum value of a timex_t can exceed the maximum measurement of the vtimer (now + MAX(timex_t) > MAX(timex_t) for each now > 0)

I would prefer to not use long_term updates at the behavior it is used now. I would suggest to only use a long_term update before the hwtimer overflows. I also would like to update seconds every time a set or now or callback function is called. When calling update_shorttime all timers should be triggered that are in the past + the amount needed to set the timer. If a timer is set with a value greater than the value the vtimer can handle vtimer_set should only return -1 and do nothing.

Please let me know what you think and what kind of issues you had with the vtimer.

Regards,    Milan

2

Hi,

* vtimer is not tickless (through long_term)

When I hacked vtimer together, I tried to make the code usable also on platforms with 16bit timers. With any decent resolution, I had to build everything around using at least two ints for holding the timer values.

I also thought that the virtual timer implementation should scale timers to longer periods (days, weeks?), maintaining a high resolution. Might be stupid.

I would prefer to not use long_term updates at the behavior it is used now. I would suggest to only use a long_term update before the hwtimer overflows.

You mean, tick on overflow? I remember trying that and running into problems.

I decided to use seconds + �s as timer variables (for the API) as all my use cases were like "wait n �s", never "wait n timer ticks at resolution A".

I chose to "tick" long_term updates in full seconds as I did not find a nice way to map the API to timer ticks back then.

I remember trying to avoid any kind of division or modulo (other than powers of two), as these operations are very expensive on most platforms. But that made some things really messy where you'd usually just do "ticks = microsecs / MICROSECONDS_PER_TICK"...

Cheers Kaspar

3

Hi Kaspar,

Hi,

* vtimer is not tickless (through long_term)

When I hacked vtimer together, I tried to make the code usable also on platforms with 16bit timers. With any decent resolution, I had to build everything around using at least two ints for holding the timer values.

But this is not working at the moment. When using a very common crystal for time measurements with 32kHz a 16bit timer can only count 2 seconds, far away from the 4096 seconds for a long_term that is needed now.

I also thought that the virtual timer implementation should scale timers to longer periods (days, weeks?), maintaining a high resolution. Might be stupid.

No, I think the same, but i do not know why they shouldn't be in the queue the same way a timer which is triggered in a half second.

I would prefer to not use long_term updates at the behavior it is used now. I would suggest to only use a long_term update before the hwtimer overflows.

You mean, tick on overflow? I remember trying that and running into problems.

Yes, at least in theory I do not know why a hwtimer_set_absolute(HWTIMER_MAXTICKS-1), should be run into more problems than hwtimer_set(4096 seconds in ticks).

I decided to use seconds + �s as timer variables (for the API) as all my use cases were like "wait n �s", never "wait n timer ticks at resolution A".

I do not want to change this in the API. But depending on how accurate the vtimer should be and to reduce computation when updating seconds, it is maybe worth to think if 2^20 is close enough to a million.

I chose to "tick" long_term updates in full seconds as I did not find a nice way to map the API to timer ticks back then.

I remember trying to avoid any kind of division or modulo (other than powers of two), as these operations are very expensive on most platforms. But that made some things really messy where you'd usually just do "ticks = microsecs / MICROSECONDS_PER_TICK"...

hwtimer.h has to macros HWTIMER_TICKS and HWTIMER_TICKS_TO_US which does the conversation in both directions. I do not see a chance to avoid using them, the most devices will not have a 1MHz crystal. When using 2^20 instead of one million it will be a diversion of two numbers that are the power of two, because most crystals use a power of two.

Regards,    Milan