[riot-notifications] [RIOT-OS/RIOT] doc/rdm: RFC - design goals (#10162)

Kaspar Schleiser notifications at github.com
Wed Jan 30 16:24:40 CET 2019

kaspar030 commented on this pull request.

> +Above the HAL, the only thing that modules should know about hardware is
+whether a required feature is there or not. If it isn't, the module should
+adapt accordingly, or not compile.
+## Real-time capabilities
+Different real-time guarantees are required for different use cases. Low
+frequency sensing needs only soft real-time support and can handle less timing
+accuracy so long as the timers support long timescales. High-frequency sensing
+and control applications need hard real-time guarantees and sub-millisecond
+timing accuracy.
+RIOT should deliver soft real-time performance by default, to cover the widest
+range of use cases. Programs with hard deadlines should be achievable with more
+expertise. It should provide timers which can competently handle the timescales
+of any application.

I find that a little sad. Sensing and control applications which *do* require hard real-time guarantees are definitely doable with RIOT.

> the system interface does not allow to specify a deadline of a thread ... as the scheduler is not deadline-aware. So I wonder how this could be done?

Specifying deadlines is not necessary to actually meet them.

Usually hard real-time means that a system *never* reacts to important events too late. For that it is necessary to be able to get guaranteed upper bounds for reaction time to these events.

In RIOT this is doable with some restrictions. The key is usually interrupt latency, because once an interrupt is running, the next steps can usually be done in constant time.
In RIOT, disabling interrupts is used to guard critical sections. In an application needing hard guarantees, all places where that is done need to be analyzed in the context of the actual application.

For example, mutex blocking might disable interrupts for one linked list traversal (a list of waiting threads). That time is bounded with O(N), N being the number of threads in the system. A hard real-time deployment will (for example) not exceed a low number of threads, so mutex blocking will have a bounded interupts-disable-time. In the general case, this is more difficult, because the number of threads is not bounded.

Doing this analysis for all "interrupt disables", taking nesting into account, will yield a maximum interrupt latency. Combined with a clear understanding of hardware interrupt latencies, it can be guaranteed that an event triggered through interrupts will not take more than X cycles.

Hard real-time applications where guranteed X cycles of interrupt latency are acceptable are thus doable with RIOT. But it is difficult to claim "RIOT provides hard real-time guarantees", as it very much depends on the actual application and used hardware.

Unfortunately the same is true for soft real-time "guarantees". Take any RIOT node, hammer it with network packets and see how the responsiveness of the shell goes down. With ethernet it is easily possible to completely starve it. You might say, "that's because the network stack has a higher priority than the shell", but that is exactly the kind of expertise necessary to build a soft *or* hard real-time application with RIOT.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190130/1ef474a8/attachment.html>

More information about the notifications mailing list