Busy wait-free TSCH

[simonduq]

Currently TSCH has a number of busy waits, resulting in ISR that run up to a few milliseconds. This is obviously undesirable. Places that need fixing:

• CCA check: not enabled by default, but if enabled, the CCA check is done as a busy wait
• Tx and ACK Tx: until we have async RF operations (Asynchronous RF operations #220), transmit busy waits for the whole duration of the Tx
• Rx and ACK Rx: busy wait until packet detected, followed another one until end of reception

[atiselsts]

Some thoughts: this is not difficult to do, if the goal is to reduce the time spent in ISR. If the goal is to save energy - I think that could be difficult, at least on some platforms. I'll talk about CC2650, because I have used it.

1. Sleep is not very energy efficient compared to the active mode; deep sleep is, but only works for longer durations. Numbers: Rx + CPU active current on CC2650 is ~7.2 mA; Rx + sleep mode current is ~5.8 mA. Meaning that getting the system out of Rx mode just 1 tick faster saves as much energy as spending 5 ticks in sleep mode instead of active mode.
2. I think that removing some busywaits may mean having to spent more time in Rx mode. Take the packet reception example - AFAIK on CC2650 there is no interrupt that could signal that the radio has finished reception seen the SFD. So the alternative to constant polling is to sleep until the max packet length, which is actually much more costly for short packets.
3. Getting out of the ISR additional times increases the probability that some other interrupt (e.g. sensor reading) has to be serviced during the TSCH timeslot, which is not nice for the protocol and again can delay the time when Rx mode is turned off.
4. Scheduling the sleep itself requires some small CPU work, and the wakeup can only happen on rtimer tick boundary - so the system may lose some energy on both ends of the sleep.

[simonduq]

Yes the first goal here is to reduce time spend in ISR, to remove side effects on other system operations such as serial line or application stuff. Let's try to get this as energy-efficient as possible, and if needed, preserve the busy-wait option through a compile flag.

If you take a closer look, CCA check is straightforward (it's a fixed duration), Tx also comes with no energy trade-off. The discussion really is only about Rx.

In Rx, there are two busy waits: first for the guard time, second for the packet Rx. Does CC2650 have a way to signal finished reception? If so, it feels we can simply turn off as soon as needed, and not spend any unnecessary time with radio on. If not, I agree we have to waste energy on every packet reception (but save on every idle wake up, where we need the radio on for RxWait anyway, but without busy-wait at least the CPU sleeps). One mitigation strategy could be to, instead of sleeping until the max packet length, just sleep in short periods and wakeup periodically (e.g. 200 usec) to check the status.

[zipper555]

Is the same issue seen on contiki as well? I'm currently experiencing the UART issues on contiki-ng due to TSCH busy waits. Could this problem be solved if I shift my project to contiki?

[alexrayne]

Yes the first goal here is to reduce time spend in ISR, to remove side effects on other system operations such as serial line or application stuff. Let's try to get this as energy-efficient as possible, and if needed, preserve the busy-wait option through a compile flag.

Hallow Simon! here i provided first aproach to relax CPU from TSCH busy - it polls only receive now, since radio driver has according API. on cc1350 with polling period 100us it uses about 10% of CPU.

In near plan - provide radio-driver with callback requesting API, and this is totaly solve problem of busy-wait radio -requests.