\input{subfilepreamble}
-\setcounter{chapter}{6}
+\setcounter{chapter}{7}
\begin{document}
\input{subfileprefix}
-\chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
+\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;
\end{itemize}
\end{chapterabstract}
-The edge layer of the \gls{IOT} contains small devices that sense and interact with the world.
+The edge layer of the \gls{IOT} is built from energy-efficient 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}.
+Furthermore, many of these 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}.
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.
+To reduce the power consumption of an \gls{IOT} edge device, the specialised low-power sleep modes of the microprocessors can be leveraged.
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.
\begin{tabular}{ccccccccc}
\toprule
& \multicolumn{4}{c}{\Gls{WEMOS} D1 mini}
- & \multicolumn{4}{c}{Adafruit Feather M0 Wifi} \\
+ & \multicolumn{4}{c}{Adafruit Feather M0 \gls{WIFI}} \\
\midrule
& active & modem & light & deep & active & modem & light & deep\\
& & sleep & sleep & sleep & & sleep & sleep & sleep\\
\endgroup
\end{table}
-\section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing}
+\section{Green \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 \gls{WEMOS} D1 mini loses the content of its \gls{RAM} in deep sleep mode.
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}
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.
In case of the \cleaninline{rpeat} task, the default refresh rate is $\rewriterate{0}{0}$ so the task immediately refreshes and starts the task again.
-\todo{netter opschrijven}
\subsubsection{Delay combinators}
Upon installation, a \cleaninline{delay} task is stored as a \cleaninline{waitUntil} task tree containing the time of installation added to the specified time to wait.
\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.
| RangeS (v Int) (v Int) // yields [+$\rewriterate{x \times 1000}{y \times 1000}$+]
\end{lstClean}
-\subsubsection{Sensors and \texorpdfstring{\glspl{SDS}}{shared data sources}}
+\subsubsection{Sensors and shared data sources}
In some applications, it is necessary to read sensors or \glspl{SDS} at a different rate than the default rate given in \cref{tbl:rewrite}, i.e.\ to customise the rewrite rate.
This is achieved by calling the access functions with a custom rewrite rate as an additional argument (suffixed with the backtick (\cleaninline{`}))
The adaptions to other classes are similar and omitted for brevity.
delayTime :: TimingInterval v | mtask v
delayTime = BeforeS (lit 60) // 1 minute in seconds
-devTask :: Main (MTask v Real) | mtask, dht, liftsds v
+devTask :: Main (MTask v Real) | mtask, dht, lowerSds v
devTask =
DHT (DHT_DHT pin DHT11) \dht =
- liftsds \localSds = tempSds
+ lowerSds \localSds = tempSds
In {main = rpeat (temperature` delayTime dht >>~. setSds localSds)}
\end{lstClean}
}
\end{lstClean}
-\section{Task scheduling in the \texorpdfstring{\gls{MTASK}}{mTask} engine}\label{sec:scheduling}
+\section{Task scheduling in the 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.
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.
}[+\label{lst:arduino_interrupt:isr_to}+]
\end{lstArduino}
-\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} language}
+\subsection{The 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}).
The interrupt handler is set up in such a way that the rewrite rate is changed to $\rewriterate{0}{0}$ once the interrupt triggers.
As a consequence, the task is executed on the next execution cycle.
-The \cleaninline{pirSwitch} function in \cref{lst:pirSwitch} creates, given an interval in \unit{\ms}, a task that reacts to motion detection by a \gls{PIR} sensor (connected to \gls{GPIO} pin 0) by lighting the \gls{LED} connected to \gls{GPIO} pin 13 for the given interval.
+The \cleaninline{pirSwitch} function in \cref{lst:pirSwitch} creates, given an interval in milliseconds, a task that reacts to motion detection by a \gls{PIR} sensor (connected to \gls{GPIO} pin 0) by lighting the \gls{LED} connected to \gls{GPIO} pin 13 for the given interval.
The system turns on the \gls{LED} again when there is still motion detected after this interval.
By changing the interrupt mode in this program text from \cleaninline{high} to \cleaninline{rising} the system lights the \gls{LED} only one interval when it detects motion, no matter how long this signal is present at the \gls{PIR} pin.
>>|. writeD ledpin true) }
\end{lstClean}
-\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} engine}
+\subsection{The 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.
-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.
\section{Conclusion}
-\todo[inline]{Conclusion}
+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 \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 devices to limit the total power consumption of the \gls{IOT}.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff