\chapter{Green computing with mTask}%
\label{chp:green_computing_mtask}
\begin{chapterabstract}
- This chapter demonstrate the energy-saving features of \gls{MTASK} by:
+ This chapter demonstrates the energy-saving features of \gls{MTASK} by:
\begin{itemize}
\item giving an overview of general green computing measures for edge devices;
\item explaining task scheduling in \gls{MTASK}, and how to tweak it so suit the applications and energy needs;
Different sleep mode achieve different power reductions because of their run time characteristics.
These specifics range from disabling or suspending the \gls{WIFI} radio; 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 safe to sleep is expensive in the general case.
-In practise it means that either annotations in the source code, a \gls{RTOS}, or a scheduler is required.
+In practise, it means that either annotations in the source code, a \gls{RTOS}, or a 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 saving.
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.
After each loop, the \gls{RTS} knows which task is waiting on which triggers and is thus determines when it is possible and safe to sleep and choose the optimal sleep mode according to the sleeping time.
%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.
+%When a single rewrite step would take forever due to an infinite sequence of function calls, this would block the entire \gls{IOT} node.
%Even infinite sequences rewrite steps are perfectly fine.
-%The \gls{MTASK} system does proper tail-call optimizations to facilitate this.
+%The \gls{MTASK} system does proper tail-call optimisations to facilitate this.
\section{Rewrite interval}
Some \gls{MTASK} programs contain one or more explicit \cleaninline{delay} primitives, offering a natural place a pause.
\end{equ}
\subsubsection{Sequential combinators}
-For the step combinator (\cref{R:step})---and all other derived sequential combinators\nobreak---\nobreak\hskip0ptthe refresh rate of the left-hand side task is taken since that is the only task that is rewritten during evaluaton.
+For the step combinator (\cref{R:step})---and all other derived sequential combinators\nobreak---\nobreak\hskip0ptthe refresh rate of the left-hand side task is taken since that is the only task that is rewritten during evaluation.
Only after stepping, the combinator rewrites to the result of evaluating the right-hand side expression.
\subsubsection{Repeating combinators}
\subsection{Tweaking rewrite rates}
A tailor-made \gls{ADT} (see \cref{lst:interval}) is used to tweak the timing intervals.
-The value is determined at runtime but the constructor is known at compile time.
+The value is determined at runtime, but the constructor is known at compile time.
During compilation, the constructor of the \gls{ADT} is checked and code is generated accordingly.
If it is \cleaninline{Default}, no extra code is generated.
In the other cases, code is generated to wrap the task tree node in a \emph{tune rate} node.
The rewrite rates from the previous section only tell us how much the next evaluation of the task can be delayed.
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 so a scheduler is involved.
+Hence, the rewrite intervals cannot be used directly to let the microcontroller sleep, so a scheduler is involved.
Our scheduler has the following objectives.
\begin{itemize}
The \gls{MTASK} tasks are ordered at their absolute latest start time in this queue; earliest deadline first.
We use the earliest deadline to order tasks with equal latest deadline.
-It is very complicated to make an optimal scheduling algorithm for tasks to minimize the energy consumption.
+It is very complicated to make an optimal scheduling algorithm for tasks to minimise the energy consumption.
We use a simple heuristic to evaluate tasks and determine sleep time rather than wasting energy on a fancy evaluation algorithm.
\Cref{lst:evalutionRound} gives this algorithm in pseudo code.
First the edge device checks for new tasks and updates of \glspl{SDS}.
This communication adds the new task to the queue, if there where any.
The \cleaninline{stepped} set contains all tasks evaluated in this evaluation round.
Next, we evaluate tasks from the queue until we encounter a task that has an evaluation interval that has not started.
-This may result in evaluating tasks earlier than required, but maximizes the opportunities to sleep after this evaluation round.
+This may result in evaluating tasks earlier than required, but maximises the opportunities to sleep after this evaluation round.
%Using the \prog{stepped} set ensures that we evaluate each task at most once during an evaluation round.
Executed tasks are temporarily stored in the \cleaninline{stepped} set instead of inserted directly into the queue to ensure that they are evaluated at most once in a evaluation round to ensure that there is frequent communication with the server.
A task that produces a stable value is completed and is not queued again.
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.
-Interrupts should be disabled when there are no tasks waiting for that kind of interrupt because unused interrupts can lead to unwanted wake ups, and only one kind of interrupt can be attached to a pin at the time..
+Interrupts should be disabled when there are no tasks waiting for that kind of interrupt because unused interrupts can lead to unwanted wake-ups, and only one kind of interrupt can be attached to a pin at the time.
\subsubsection{Event registration}
The \gls{MTASK} \gls{RTS} contains an event administration to register which task is waiting on which event.
This event registration is stored as a linked list of task tree nodes so that the garbage collector cleans them up when they become unused.
Registering and deregistering interrupts is a device-specific procedure, although most supported devices use the \gls{ARDUINO} \gls{API} for this.
-Which pins support which interrupt differs greatly from device to device but this information is known at compile time.
+Which pins support which interrupt differs greatly from device to device, but this information is known at compile time.
At the time of registration, the \gls{RTS} checks whether the interrupt is valid and throws an \gls{MTASK} exception if it is not.
Moreover, an exception is thrown if multiple types of interrupts are registered on the same pin.
The interrupt can be disabled as all tasks waiting for the interrupt become stable after firing.
More occurrences of the interrupts do not change the value of the task as stable tasks keep the same value forever.
Therefore, it is no longer necessary to keep the interrupt enabled, and it is relatively cheap to enable it again if needed in the future.
-Evaluating interrupt task node in the task tree is trivial because all of the work was already done when the interrupt was triggered.
+Evaluating interrupt task node in the task tree is trivial because all the work was already done when the interrupt was triggered.
The task emits the status of the pin as a stable value if the information in the task shows that it was triggered.
Otherwise, no value is emitted.
This chapter show how we can automatically associate execution intervals to tasks.
Based on these intervals, we can delay the executions of those tasks.
When all task executions can be delayed, the microprocessor executing those tasks can go to sleep mode to reduce its energy consumption.
-This is a rather difficult problem that must be solved dynamically, since we make no assumptions on the number and nature of the tasks that will be allocated to an IoT node.
+This is a rather difficult problem that must be solved dynamically, since we make no assumptions on the number and nature of the tasks that will be allocated to an \gls{IOT} device.
Furthermore, the execution intervals offer an elegant and efficient way to add interrupts to the language.
Those interrupts offer a more elegant and energy efficient implementation of watching an input than polling this input.
The actual reduction of the energy is of course highly dependent on the number and nature of the task shipped to the edge device.
Our examples show a reduction in energy consumption of two orders of magnitude.
Those reductions are a necessity for edge devices running of battery power.
-Given the exploding number of \gls{IOT} edge devices, such savings are also mandatory for other nodes to limit the total power consumption of the \gls{IOT}.
+Given the exploding number of \gls{IOT} edge devices, such savings are also mandatory for other devices to limit the total power consumption of the \gls{IOT}.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff