\chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
\label{chp:green_computing_mtask}
\begin{chapterabstract}
- \noindent This chapter demonstrate the energy saving features of \gls{MTASK} by
+ This chapter demonstrate the energy-saving features of \gls{MTASK} by:
\begin{itemize}
\item giving an overview of general green computing measures for edge devices;
- \item explaining \gls{MTASK}'s task scheduling, and it is shown how to customise it so suit the applications and energy needs;
+ \item explaining task scheduling in \gls{MTASK}, and how to tweak it so suit the applications and energy needs;
\item showing how to use interrupts in \gls{MTASK} to reduce the need for polling.
\end{itemize}
\end{chapterabstract}
-The edge layer of the \gls{IOT} contains small devices that sense and interact with the world and it is crucial to lower their energy consumption.
+The edge layer of the \gls{IOT} contains small devices that sense and interact with the world.
While individual devices consume little energy, the sheer number of devices in total amounts to a lot.
Furthermore, many \gls{IOT} devices operate on batteries and higher energy consumption increases the amount of e-waste as \gls{IOT} edge devices are often hard to reach and consequently hard to replace \citep{nizetic_internet_2020}.
-
-To reduce the power consumption of an \gls{IOT} device, the specialized low-power sleep modes of the microprocessors can be leveraged.
-Different sleep modes achieve different power reductions because of their different run time characteristics.
-These specifics range from disabling or suspending WiFi; stopping powering (parts) of the \gls{RAM}; disabling peripherals; or even turning off the processor completely, requiring an external signal to wake up again.
-Determining when exactly and for how long it is possible to sleep is expensive in the general case and often requires annotations in the source code, a real-time operating system or a handcrafted scheduler.
+It is therefore crucial to lower their energy consumption.
+
+To reduce the power consumption of an \gls{IOT} edge device, the specialized low-power sleep modes of the microprocessors can be leveraged.
+Various sleep mode achieve different power reductions because of their run time characteristics.
+These specifics range from disabling or suspending \gls{WIFI}; stop powering (parts) of the \gls{RAM}; disabling peripherals; or even turning off the processor completely, requiring an external signal to wake up again.
+Determining exactly when, and for how long it is possible to sleep is expensive in the general case.
+In practise it means that either annotations in the source code, a \gls{RTOS}, or a handcrafted or general-purpose scheduler is required.
+
+\Cref{tbl:top_sleep} shows the properties and current consumption of two commonly used microcontrollers in their various sleep modes.
+It uncovers that switching the \gls{WIFI} radio off yields the biggest energy savings.
+In most \gls{IOT} applications, we need \gls{WIFI} for communications.
+It is fine to switch it off, but after switching it on, the \gls{WIFI} protocol needs to transmit a number of messages to re-establish the connection.
+This implies that it is only worthwhile to switch the radio off when this can be done for some time.
+The details vary per system and situation.
+As a rule of thumb, derived from experimentation, it is only worthwhile to switch the \gls{WIFI} off when it is not needed for at least some tens of seconds.
\begin{table}
\centering
- \caption{Current use in \unit{\milli\ampere} of two microprocessor boards in various sleep modes.}%
+ \caption{Current use (\unit{\milli\ampere}) of two microprocessor boards in various sleep modes.}%
\label{tbl:top_sleep}
\small
+ \begingroup
+ % default is 6pt but this gives an overflow of 4.25816pt
+ \setlength\tabcolsep{5.5pt}
\begin{tabular}{ccccccccc}
\toprule
- & \multicolumn{4}{c}{Wemos D1 mini} & \multicolumn{4}{c}{Adafruit Feather M0 Wifi} \\
+ & \multicolumn{4}{c}{\Gls{WEMOS} D1 mini}
+ & \multicolumn{4}{c}{Adafruit Feather M0 Wifi} \\
\midrule
- & active & modem & light & deep & active & modem & light & deep \\
- & & sleep & sleep & sleep & & sleep & sleep & sleep \\
+ & active & modem & light & deep & active & modem & light & deep\\
+ & & sleep & sleep & sleep & & sleep & sleep & sleep\\
\midrule
- WiFi & on & off & off & off & on & off & off & off \\
- CPU & on & on & pending & off & on & on & idle & idle \\
- \gls{RAM} & on & on & on & off & on & on & on & on\\%low power \\
+ \gls{WIFI}& on & off & off & off & on & off & off & off\\
+ CPU & on & on & pend. & off & on & on & idle & idle\\
+ \gls{RAM} & on & on & on & off & on & on & on & on\\
\midrule
- current & 100--240 & 15 & 0.5 & 0.002 & 90--300 & 5 & 2 & 0.005\\
+ current & \numrange{100}{240} & \num{15} & \num{0.5} & \num{0.002} & \numrange{90}{300} & \num{5} & \num{2} & \num{0.005}\\
\bottomrule
\end{tabular}
+ \endgroup
\end{table}
-\Cref{tbl:top_sleep} shows the properties and current consumption of two commonly used microcontrollers.
-It shows that switching the WiFi radio off yields the biggest energy savings.
-In most \gls{IOT} applications, we need WiFi for communications.
-It is fine to switch it off, but after switching it on, the WiFi protocol needs to transmit a number of messages to re-establish the connection.
-This implies that it is only worthwhile to switch the radio off when this can be done for some time.
-The details vary per system and situation.
-As a rule of thumb, it is only worthwhile to switch the WiFi off when it is not needed for at least some tens of seconds.
-
\section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing}
The data in \cref{tbl:top_sleep} shows that it is worthwhile to put the system in some sleep mode when there is temporarily no work to be done.
A deeper sleep mode saves more energy, but also requires more work to restore the software to its working state.
-A processor like the ESP8266 driving the Wemos D1 mini loses the content of its \gls{RAM} in deep sleep mode.
+A processor like the ESP8266 driving the \gls{WEMOS} D1 mini loses the content of its \gls{RAM} in deep sleep mode.
As a result, after waking up, the program itself is preserved, since it is stored in flash memory, but the program state is lost.
When there is a program state to be preserved, we must either store it elsewhere, limit us to light sleep, or use a microcontroller that keeps the \gls{RAM} intact during deep sleep.
Such protocols control the communication with sensors and actuators.
Without the help of an \gls{OS}, the programmer is forced to combine all subtasks into one big system that decides if it is safe to sleep for all subtasks.
-\Gls{MTASK} offers abstractions for edge layer-specific details such as the heterogeneity of architectures, platforms and frameworks; peripheral access; and multitasking but also for energy consumption and scheduling.
+The \gls{MTASK} language offers abstractions for edge layer-specific details such as the heterogeneity of architectures, platforms and frameworks; peripheral access; and multitasking but also for energy consumption and scheduling.
In \gls{MTASK}, tasks are implemented as a rewrite system, where the work is automatically segmented in small atomic bits and stored as a task tree.
Each cycle, a single rewrite step is performed on all task trees, during rewriting, tasks do a bit of their work and progress steadily, allowing interleaved and seemingly parallel operation.
After a loop, the \gls{RTS} knows which task is waiting on which triggers and is thus able to determine the next execution time for each task automatically.
Utilising this information, the \gls{RTS} can determine when it is possible and safe to sleep and choose the optimal sleep mode according to the sleeping time.
For example, the \gls{RTS} never attempts to sleep during an \gls{I2C} communication because \gls{IO} is always contained \emph{within} a rewrite step.
-
-An \gls{MTASK} program is dynamically transformed to byte code.
-This byte code and the initial \gls{MTASK} expression are shipped to \gls{MTASK} \gls{IOT} node.
-The \gls{MTASK} rewrite engine rewrites the current expression just a single rewrite step at a time.
-When subtasks are composed in parallel, all subtasks are rewritten unless the result of the first rewrite step makes the result of the other tasks superfluous.
-The task design ensures such that all time critical communication with peripherals is within a single rewrite step.
This is very convenient, since the system can inspect the current state of all \gls{MTASK} expressions after a rewrite and decide if sleeping and how long is possible.
%As a consequence, we cannot have fair multitasking.
%When a single rewrite step would take forever due to an infinite sequence of function calls, this would block the entire IoT node.
-Even infinite sequences rewrite steps, as in the \cleaninline{blink} example, are perfectly fine.
+Even infinite sequences rewrite steps are perfectly fine.
The \gls{MTASK} system does proper tail-call optimizations to facilitate this.
\section{Rewrite interval}
A typical example is the program that reads the temperature for a sensor and sets the system \gls{LED} if the reading is below some given \cleaninline{goal}.
\begin{lstClean}[caption={A basic thermostat task.},label={lst:thermostat}]
-thermostat :: Main (MTask v Bool) | mtask v
-thermostat = DHT I2Caddr \dht->
- {main = rpeat (temperature dht >>~. \temp.
- writeD builtInLED (goal <. temp))}
+thermostat :: Main (MTask v Bool) | mtask, dht v
+thermostat = declarePin D8 PMOutput \ledPin->
+ DHT I2Caddr \dht->
+ {main = rpeat (temperature dht >>~. \temp->
+ writeD ledPin (goal <. temp))}
\end{lstClean}
This program repeatedly reads the \gls{DHT} sensor and sets the on-board \gls{LED} based on the comparison with the \cleaninline{goal} as fast as possible on the \gls{MTASK} node.
-This is a perfect solution as long as we ignore the power consumption.
The \gls{MTASK} machinery ensures that if there are other tasks running on the node, they will make progress.
However, this solution is far from perfect when we take power consumption into account.
-In most applications, it is very unlikely that the temperature will change significantly within one minute, let alone within some milliseconds.
+In most applications, it is very unlikely that the temperature changes significantly within one minute, let alone within some milliseconds.
Hence, it is sufficient to repeat the measurement with an appropriate interval.
There are various ways to improve this program.
\subsubsection{Parallel combinators}
For parallel combinators, the \emph{or}-combinator (\cleaninline{.\|\|.}) in \cref{R:or} and the \emph{and}-combinator (\cleaninline{.&&.}) in \cref{R:and}, the safe intersection (see \cref{equ:safe_intersect}) of the rewrite rates is taken to determine the rewrite rate of the complete task.
The conventional intersection does not suffice here because it yields an empty intersection when the intervals do not overlap.
-In that case, the safe intersection behaves will return the range with the lowest numbers.
+In that case, the safe intersection returns the range with the lowest numbers.
The rationale is that subtasks should not be delayed longer than their rewrite range.
Evaluating a task earlier should not change its result but just consumes more energy.
Only after stepping, the combinator rewrites to the right-hand side.
\subsubsection{Repeating combinators}
-The repeat combinators repeats their argument indefinitely.
+The repeat combinators repeats its argument indefinitely.
As the \cleaninline{rpeat} task tree node already includes a rewrite rate (set to $\rewriterate{0}{0}$ for a default \cleaninline{rpeat}), both \cleaninline{rpeat} and \cleaninline{rpeatEvery} use the same task tree node and thus only one entry is required here.
The derived refresh rate of the repeat combinator is the refresh rate of the child if it is unstable.
Otherwise, the refresh rate is the embedded rate time minus the start time.
\section{Task scheduling in the \texorpdfstring{\gls{MTASK}}{mTask} engine}\label{sec:scheduling}
The rewrite rates from the previous section only tell us how much the next evaluation of the task can be delayed.
-An \gls{IOT} edge devices executes multiple tasks may run interleaved.
+In the \gls{MTASK} system, an \gls{IOT} edge devices can run multiple tasks.
In addition, it has to communicate with a server to collect new tasks and updates of \glspl{SDS}.
Hence, the rewrite intervals cannot be used directly to let the microcontroller sleep.
Our scheduler has the following objectives.
For instance, a task like \cleaninline{rpeatEvery (ExactMs 1) t} should repeat \cleaninline{t} every millisecond.
The programmer might expect that \cleaninline{t} will be executed for the ${(N+1)}^{th}$ time after $N$ milliseconds.
Uncompensated time drift might make this considerably later.
-\Gls{MTASK} does not pretend to be a hard real-time \gls{OS}, and cannot give firm guarantees with respect to evaluation time.
+The \gls{MTASK} \gls{RTS} does not pretend to be a hard real-time \gls{OS}, and cannot give firm guarantees with respect to evaluation time.
Nevertheless, we try to make time handling as reliable as possible.
This is achieved by adding the start time of this round of task evaluations rather than the current time to compute absolute execution intervals.
Next, the microcontroller goes to light sleep for the minimum of a predefined interval and the task delay.
In general, the microcontroller node executes multiple \gls{MTASK} tasks at the same time.
-\Gls{MTASK} nodes repeatedly check for inputs from servers and execute all tasks that cannot be delayed to the next evaluation round one step.
+The \gls{MTASK} node repeatedly check for inputs from servers and execute all tasks that cannot be delayed to the next evaluation round one step.
The tasks are stored in a priority queue to check efficiently which of them need to be stepped.
The \gls{MTASK} tasks are ordered at their absolute latest start time in this queue; the earliest deadline first.
We use the earliest deadline to order tasks with equal latest deadline.
The \cleaninline{sleep} function determines the maximum sleep time based on the top of the queue.
The computed sleep time and the characteristics of the microprocessor determine the length and depth of the sleep.
-For very short sleep times it might not be worthwhile to sleep.
+For very short sleep times it is not be worthwhile to put the processor in sleep mode.
In the current \gls{MTASK} \gls{RTS}, the thresholds are determined by experimentation but can be tuned by the programmer.
On systems that lose the content of their \gls{RAM} it is not possible to go to deep sleep mode.
While the \glspl{ISR} look like regular functions, they do come with some limitations.
For example, they must be very short, in order not to miss future interrupts; can only do very limited \gls{IO}; cannot reliably check the clock; and they operate in their own stack, and thus communication must happen via global variables.
After the execution of the \gls{ISR}, the normal program flow is resumed.
-Interrupts are heavily used internally in the \gls{RTS} of the microcontrollers to perform timing critical operations such as WiFi, \gls{I2C}, or \gls{SPI} communication; completed \gls{ADC} conversions, software timers; exception handling; \etc.
+Interrupts are heavily used internally in the \gls{RTS} of the microcontrollers to perform timing critical operations such as \gls{WIFI}, \gls{I2C}, or \gls{SPI} communication; completed \gls{ADC} conversions; software timers; exception handling; \etc.
-Interrupts offer two substantial benefits: fewer missed events and better energy usage.
+Using interrupts in \gls{MTASK} task offer two substantial benefits: fewer missed events and better energy usage.
Sometimes an external event such as a button press only occurs for a very small duration, making it possible to miss it due to it happening right between two polls.
Using interrupts is not a fool-proof way of never missing an event.
Events may still be missed if they occur during the execution of an \gls{ISR} or while the microcontroller is still in the process of waking up from a triggered interrupt.
}[+\label{lst:arduino_interrupt:isr_to}+]
\end{lstArduino}
-\subsection{\texorpdfstring{\Gls{MTASK}}{MTask} language}
+\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} language}
\Cref{lst:mtask_interrupts} shows the interrupt interface in \gls{MTASK}.
The \cleaninline{interrupt} class contains a single function that, given an interrupt mode and a \gls{GPIO} pin, produces a task that represents this interrupt.
Lowercase variants of the various interrupt modes such as \cleaninline{change :== lit Change} are available as convenience macros (see \cref{sec:expressions}).
>>|. writeD ledpin true) }
\end{lstClean}
-\subsection{\texorpdfstring{\Gls{MTASK}}{MTask} engine}
+\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} engine}
While interrupt tasks have their own node type in the task tree, they differ slightly from other node types because they require a more elaborate setup and teardown.
Enabling and disabling interrupts is done in a general way in which tasks register themselves after creation and deregister after deletion.
repositories / phd-thesis.git / blobdiff