RFC: Expand Alarm Range

[Samir-Rashid]

RFC: Expand Alarm Range

[alevy]

For completeness, I think questioning whether the system call interface should support this is reasonable, in general. There are multiple competing tradeoffs to consider:

1. It is possible on some hardware to do this in the kernel in a more power efficient manner. Basically if you can setup a counter to increment when the timer wraps around, and set an interrupt to fire when the counter reaches a certain value, you can do this without waking the CPU up until very close to the deadline. I believe this is possible on the NRF

2. However, that would add a fair bit of code size and complexity regardless of whether apps actually used that system call ever

3. And is probably not supportable on all platforms, so would introduce even more code size and complexity in chips that didn't support it to simulate it.

4. On the other other hand, doing this purely in userspace, in practice, adds some code size complexity for each application that uses the timer (since it'll be in the library code that implements the timer) regardless of whether it's useful to that app.

It's not immediately obvious how these tradeoffs play-out generally but I think an intuition is that such a long timer is probably rare enough that it's OK to force that application to figure out how to handle this on its own or the added code to support this in the libtock-c timer library is minimal enough to just do it there.

[lschuermann]

Given the large range of underlying frequencies we support for these timers (especially the nRF example above is useful), I think that we should then fix timer_in to repeatedly wait for the max ticks that the alarm syscall driver supports, if the wait time were to overflow.

I agree with most comments above in that I don't believe the syscall driver needs to be adjusted, because we do clearly communicate those limits (through the number of bits available to the ticks argument).

[alevy]

so, we already have delay_ms in userspace. In principle, something like this should work:

delay_ms(1000 * 3600 * 24 * 25);
delay_ms(1000 * 3600 * 24 * 25);

(50 days in milliseconds is actually slightly more than 2^32 milliseconds)

Unfortunately, I suspect this would result in an overflow of the interval variable computed in timer_in. But this can be detected and fixed, and simply set several consecutive timers internally.

In other words, I don't think you need any additional kernel or low-level userlevel functionality unless you really want to avoid waking up the CPU less than every 2 days or whatever.

Incidentally, I'm really curious to know the part of the OpenThread spec that requires a 50 day timer. That's a long time to do nothing...

[tyler-potyondy]

timer_in works in the sense of providing the time in milliseconds, but is flawed in that it is just a wrapper around alarm_at which can only accept a max value of $2^{32}$ ticks

[tyler-potyondy]

This is somewhat trivial to implement in userspace as you suggested @alevy and will not in any way impede the openthread port. Perhaps the broader question is if Tock should support providing an 8byte tick expiration instead of a 4byte tick value (i.e. the set alarm syscall uses two arguments to provide high / low bits). From this, the alarm capsule would then internally handle the overflow. The drawback to this is added complexity within the capsule. However, this would simplify the logic libtock implements and also avoid needing to reimplement this in each libtock variant (c / rs / future).

The answer to all of this may perhaps be that "wrapping alarms" are something userspace should handle. If so the userspace implementation can easily be completed for libtock-c. This is a broader design philosophy of where the implementation complexity should reside.

For sake of discussion and context: for the default nrf52840 tock configuration at 32KHz, the greatest possible value for the syscall alarm is 37 hours.

[tyler-potyondy]

Incidentally, I'm really curious to know the part of the OpenThread spec that requires a 50 day timer. That's a long time to do nothing...

I have not specifically come across where in the spec this is needed. This is an assumption OpenThread states / requires of the alarm provided through the PAL having this potential range.

The exact value is not 50 days but in fact $2^{32}$ microseconds (~47.5 days). In debugging, I have seen some very large alarm values set, but nothing to the extent of this. Nonetheless, we need to provide a timer capable of this range to be in compliance with OpenThread's defined behavior.

[bradjc]

timer_in(ms) doesn't work?

/** \brief Create a new alarm to fire in `ms` milliseconds.
 *
 * \param ms the number of milliseconds to fire the alarm after.
 * \param callback a callback to be invoked when the alarm expires.
 * \param userdata passed to the callback.
 * \param A handle to the alarm that was created.
 * \return An error code. Either RETURNCODE_SUCCESS or RETURNCODE_FAIL.
 */
int timer_in(uint32_t ms, subscribe_upcall, void*, tock_timer_t* timer);

[alevy]

I think this is a very valuable thing to have raised and it's good to have it for posterity. @Samir-Rashid can you close the issue if you think the responses resolve this uncontroversially for you? (DO NOT CLOSE IT IF YOU ARE NOT CONVINCED)