xtimer: xtimer_now() not ISR safe

[kaspar030]

On platforms where xtimer is using a <32bit counter, xtimer_now() might cause a wrong time to be returned when called from ISRs, as the _high_count and _long_count interrupts might be missed (delayed). This is also true for xtimer_now64() for all platforms, and also for all calls while IRQ's are disabled.

Unfortunately this also affects all xtimer_set*(), as they call xtimer_now[64}().

Can anyone think of an algorithm to prevent this?

(something like, a) set a flag after e.g., half the underlying timer's tick count, b) unset on overflow, and if in isr the tick count is < half and the flag is not set, add one to the long counter...)

[OlegHahm]

As I'm too lazy to look it up and cannot remember, can you quickly confirm that this bug would lead to a timer value that might be off by 2^32 ticks (if _high_cnt is wrong) in the worst case?

[jnohlgard]

@OlegHahm When this occurs the timer would be one lltimer period off if I understand the problem correctly. One lltimer period is the period of the underlying hardware timer.

[OlegHahm]

@gebart, thanks, yes I meant 2^TIMER_WIDTH instead of 2^32.

[jnohlgard]

How about this for a start:
if we mask the hardware counter to use all bits except the MSB then we can handle the situation through simple addition of the lltimer now value and the high cnt, and use the current high_cnt as an accumulator variable. It will take some effort to rework parts of xtimer though.

[kaspar030]

@gebart I don't quite understand. We're already adding lltimer_now to high_cnt. how does masking the MSB help?

[jnohlgard]

@kaspar030 I need to structure my ideas further, but I have some more urgent things that I need to finish first. Anyway, the general idea is set the _high_cnt tick timeout to half a period instead of a full period and let the lltimer msb and the _high_cnt lsb overlap in some way, to catch any IRQ delay which is less than a half lltimer period.

[malosek]

Hello,
IMHO: with current xtimer architecture there does not seem to be solution to cover all the use cases.
what about to decrease xtimer resolution to ms? and use hw timer "just" for increasing variable on overflow (this seems to be necessary anyway)?
with such setup low freq clock could be used while high speed clock is off.
if there is need, then introduce kind of high speed timer with sub ms resolution afterwards.
btw: good catch @kaspar030
wbr
malo

[OlegHahm]

If one configures the timer on iotlab-m3 to run slower (e.g. by setting XTIMER_SHIFT to 3) pinging between nodes with a bigger payload show some unexpected behavior. Usually pinging between two 6lo nodes and a payload of 1024 bytes, has a round-trip time of about 150ms. With the slower timer, the RTT increases for some pings (~25%) to ~650ms while the rest shows the usual 150ms.