loic/paper-lowrate-iot
1
0
Fork 0
mirror of https://gitlab.com/manzerbredes/paper-lowrate-iot.git synced 2025-04-19 04:09:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
paper-lowrate-iot/2019-ICA3PP.org
ORGERIE Anne-Cecile 25463e0664 modifs conclusoin
2019-07-19 13:14:11 +02:00

1324 lines
58 KiB
Org Mode
Raw Blame History

#+TITLE: Estimating the end-to-end energy consumption of low-bandwidth IoT applications for WiFi devices
#+EXPORT_EXCLUDE_TAGS: noexport
#+STARTUP: hideblocks
#+OPTIONS: H:5 author:nil email:nil creator:nil timestamp:nil skip:nil toc:nil ^:nil
#+LATEX_CLASS: llncs
#+LATEX_HEADER: \usepackage{hyperref}
#+LATEX_HEADER: \usepackage{booktabs}
#+LATEX_HEADER: \usepackage{subfigure}
#+LATEX_HEADER: \usepackage{graphicx}
#+LATEX_HEADER: \usepackage{xcolor}
#+LATEX_HEADER: \author{
#+LATEX_HEADER: Loic Guegan and
#+LATEX_HEADER: Anne-Cécile Orgerie\\
#+LATEX_HEADER: }
#+LATEX_HEADER: \institute{Univ Rennes, Inria, CNRS, IRISA, Rennes, France\\
#+LATEX_HEADER: Emails: loic.guegan@irisa.fr, anne-cecile.orgerie@irisa.fr
#+LATEX_HEADER: }
#+BEGIN_EXPORT latex
\newcommand{\hl}[1]{\textcolor{red}{#1}}
#+END_EXPORT
#+BEGIN_EXPORT latex
\begin{abstract}
Information and Communication Technology takes a growing part in the
worldwide energy consumption. One of the root causes of this increase
lies in the multiplication of connected devices. Each object of the
Internet-of-Things often does not consume much energy by itself. Yet,
their number and the infrastructures they require to properly work
have leverage. In this paper, we combine simulations and real
measurements to study the energy impact of IoT devices. In particular,
we analyze the energy consumption of Cloud and telecommunication
infrastructures induced by the utilization of connected devices, And
we propose an end-to-end energy consumption model for these devices.
\end{abstract}
#+END_EXPORT
* Introduction
In 2018, Information and Communication Technology (ICT) was estimated
to absorb around 3% of the global energy consumption
\cite{ShiftProject}. This consumption is estimated to grow at a rate
of 9% per year \cite{ShiftProject}. This alarming growth is explained
by the fast emergence of numerous applications and new ICT
devices. These devices supply services for smart building, smart
factories and smart cities for instance. Through connected sensors
producing data, actuators interacting with their environment and
communication means -- all being parts of the Internet of Things (IoT)
-- they provide optimized decisions.
This increase in number of devices implies an increase in the energy
needed to manufacture and utilize them. Yet, the overall energy bill
of IoT also comprises indirect costs, as it relies on computing and
networking infrastructures that consume energy to enable smart
services. Indeed, IoT devices communicate with Cloud computing
infrastructures to store, analyze and share their data.
In February 2019, a report by Cisco stated that ``IoT connections will
represent more than half (14.6 billion) of all global connected
devices and connections (28.5 billion) by 2022" \cite{Cisco2019}. This
will represent more than 6% of global IP traffic in 2022, against 3%
in 2017 \cite{Cisco2019}. This increasing impact of IoT devices on
Internet connections induces a growing weight on ICT energy
consumption.
The energy consumption of IoT devices themselves is only the top of
the iceberg: their use induce energy costs in communication and cloud
infrastructures. In this paper, we estimate the overall energy
consumption of an IoT device environment by combining simulations and
real measurements. We focus on a given application with low bandwidth
requirement and we evaluate its overall energy consumption: from the
device, through telecommunication networks, and up to the Cloud data
center hosting the application. From this analysis, we derive an
end-to-end energy consumption model that can be used to assess the
consumption of other IoT devices.
While some IoT devices produce a lot of data, like smart vehicles for
instance, many others generate only a small amount of data, like smart
meters. However, the scale matters here: many small devices can end up
producing big data volumes. As an example, according to a report
published by Sandvine in October 2018, the Google Nest Thermostat is
the most significant IoT device in terms of worldwide connections: it
represents 0.16% of all connections, ranging 55th on the list of
connections \cite{Sandvine2018}. As a comparison, the voice assistants
Alexa and Siri are respectively 97th and 102nd with 0.05% of all
connections \cite{Sandvine2018}. This example highlights the growing
importance of low-bandwidth IoT applications on Internet
infrastructures, and consequently on their energy consumption.
In this paper, we focus on IoT devices for low-bandwidth applications
such as smart meters or smart sensors. These devices send few
data periodically to cloud servers, either to store them or to get
computing power and take decisions. This is a first step towards a
comprehensive characterization of the global IoT energy
footprint. While few studies address the energy consumption of
high-bandwidth IoT applications \cite{li_end--end_2018}, to the best
of our knowledge, none of them targets low-bandwidth applications,
despite their growing importance on the Internet infrastructures.
Low-bandwidth IoT applications, such as the Nest Thermostat, often
relies on sensors powered by batteries. For such sensors, reducing
their energy consumption is a critical target. Yet, we argue that
end-to-end energy models are required to estimate the overall impact
of IoT devices, and to understand how to reduce their complete energy
consumption. Without such models, one could optimize the consumption
of on-battery devices at a heavier cost for cloud servers and
networking infrastructures, resulting on an higher overall energy
consumption. Using end-to-end models could prevent these unwanted
effects.
Our contributions include:
- a characterization of low-bandwidth IoT applications;
- an analysis of the energy consumption of a low-bandwidth IoT
application including the energy consumption of the WiFi IoT device
and the consumption induced by its utilization on the Cloud and
telecommunication infrastructures;
- an end-to-end energy model for low-bandwidth IoT applications
relying on WiFi devices.
The paper is organized as follows. Section \ref{sec:sota} presents the
state of the art. The low-bandwidth IoT application is characterized
in Section \ref{sec:usec}, and details on its architecture are
provided in Section \ref{sec:model}. Section \ref{sec:eval} provides
our experimental results combining real measurements and
simulations. Section \ref{sec:discuss} discusses the key findings an
the end-to-end energy model. Finally, Section \ref{sec:cl} concludes
this work and presents future work.
* Related Work
#+LaTeX: \label{sec:sota}
** Energy consumption of IoT devices
The multiplication of smart devices and smart applications pushes the
limits of Internet: IoT is now used everywhere for home automation,
smart agriculture, e-health, smart cities, logistics, smart grids,
smart buildings, etc. \cite{Wang2016,Ejaz2017,Minoli2017}. IoT devices
are typically used to optimize processes and the envisioned
application domains include the energy distribution and management. It
can for instance help the energy management of product life-cycle
\cite{Tao2016}. Yet, few studies address the impact of IoT itself on
global energy consumption \cite{jalali_fog_2016,li_end--end_2018} or
CO2 emissions \cite{Sarkar2018}.
The underlying architecture of these smart applications usually
includes sensing devices, cloud servers, user applications and
telecommunication networks. Concerning the computing part, the cloud
servers can either be located on Cloud data centers, on Fog
infrastructures located at the network edge, or on home gateways
\cite{Wang2016}. Various network technologies are employed by IoT
devices to communicate with their nearby gateway; either wired
networks with Ethernet or wireless networks: WiFi, Bluetooth, Near
Field Communication (NFC), ZigBee, cellular network (like 3G, LTE, 4G),
Low Power Wide Area Network (LPWAN),
etc. \cite{Samie2016,Gray2015}. The chosen technology depends on the
smart device characteristics and the targeted communication
performance. The Google Nest Thermostat can for instance use WiFi,
802.15.4 and Bluetooth \cite{Nest}. In this paper, we focus on WiFi as
it is broadly available and employed by IoT devices
\cite{Samie2016,ns3-energywifi}.
Several works aim at reducing the energy consumption of the device
transmission \cite{Andres2017} or improving the energy efficiency of
the access network technologies \cite{Gray2015}. An extensive
literature exists on increasing the lifetime of battery-based wireless
sensor networks \cite{Wang2016}. Yet, IoT devices present more
diversity than typical wireless sensors in terms of hardware
characteristics, communication means and data production patterns.
Based on real measurements, previous studies have proposed energy
models for IoT devices. Yet, these models are specific to a given kind
of IoT device or a given transmission technology.
Martinez et al. provide energy consumption measurements for wireless
sensor networks using SIGFOX transmissions and employed for
smart-parking systems \cite{Martinez2015}. Wu et al. implement an
energy model for WiFi devices in the well-known ns3 network simulator
\cite{ns3-energywifi}.
** Energy consumption of network and cloud infrastructures
IoT architecture rely on telecommunication networks and Cloud
infrastructures to provide services. The data produced by IoT devices
are stored and exploited by servers located either in Cloud data
centers or Fog edge sites. While studies exist on the energy
consumption of network and cloud infrastructures in general
\cite{Ehsan}, they do not consider the specific case of IoT devices.
To the best of our knowledge, no study estimates the direct impact of
IoT applications on the energy consumption of these infrastructures.
Most work focusing on energy consumption, Cloud architecture and IoT
applications tries to answer the question: where to locate data
processing in order to save energy
\cite{jalali_fog_2016}, to reduce the CO2 impact \cite{Sarkar2018}, or
to optimize renewable energy consumption \cite{li_end--end_2018}.
In both cases, the network and cloud infrastructures, attributing the
energy consumption to a given user or application is a challenging
task. The complexity comes from the shared nature of these
infrastructures: a given Ethernet port in the core of the network
processes many packets coming from a high number of sources
\cite{jalali_fog_2016}. Moreover, the employed equipment is not power
proportional: servers and routers consume consequent amounts of
energy while being idle
\cite{mahadevan_power_2009,li_end--end_2018}.
The power consumed by a device is divided into two parts: a dynamic
part that varies with traffic or amount of computation to process, and
a static part that is constant and dissipated even while being idle
\cite{Ehsan}. This static part implies that a consequent energy cost
of running an application on a server is due to the device being
simply powered on. Consequently, sharing these static energy costs
among all the concerned users requires an end-to-end model
\cite{li_end--end_2018}.
In this paper, we focus on IoT devices using WiFi transmission and
generating low data volumes. Our model, extracted from real
measurements and simulations, can be adapted to other kinds of devices
and transmission technologies.
* Characterization of low-bandwidth IoT applications
#+LaTeX: \label{sec:usec}
In this section, we detail the characteristics of the considered IoT
application. While the derived model is more generic, we focus on a
given application to obtain a precise use-case with accurate power
consumption measurements.
The Google Nest Thermostat relies on five sensors: temperature,
humidity, near-field activity, far-field activity and ambient light
\cite{Nest}. Periodical measurements, sent through wireless
communications on the Internet, are stored on Google data centers and
processed to learn the home inhabitants habits. The learned behavior
is employed to automatically adjust the home temperature managed by
heating and cooling systems.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\includegraphics[width=0.5\linewidth]{./plots/home.png}
\caption{Overview of IoT devices.}
\label{fig:IoTdev}
\end{figure}
#+END_EXPORT
Each IoT device senses periodically its environment. Then, it sends
the produced data through WiFi (in our context) to its gateway or
Access Point (AP). The AP is in charge of transmitting the data to the
cloud using the Internet. Figure \ref{fig:IoTdev} illustrates this
architecture. Several IoT devices can share the same AP in a
home. We consider low-bandwidth applications where devices produces
several network packets during each sensing period. The transmitting
frequency can vary from one to several packet sent per minute
\cite{Cisco2019}.
#+BEGIN_COMMENT
The IoT part is composed of an Access Point (AP), connected to several sensors using WIFI. In the
system, the IoT part is considered as the part where the system data are created. In fact, the
data life cycle start when the sensors records their respective local temperature at a frequency
$f$ and the local timestamp. Then, these data are transmitted through the network along with an
arbitrary sensor id of 128 bits. Finally, the AP is in charge to transmit the data to the cloud
using the network part.
The network part is considered as the medium that link the IoT part to the cloud. It is composed
of several network switches and router and it is considered to be a wired network.
#+END_COMMENT
We consider that the link between the AP and the Cloud is composed of
several network switches and routers using Ethernet as shown in Figure
\ref{fig:parts}. The number of routers on the path depends on the
location of the server, either in a Cloud data center or in a Fog site
at the edge of the network.
We assume that the server hosting the application data for the users
belongs to a shared cloud facility with classical service level
agreement (SLA). The facility provides redundant storage and computing
means as virtual machines (VMs). A server can host several VMs at the
same time.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\includegraphics[width=0.6\linewidth]{./plots/parts2.png}
\caption{Overview of the IoT architecture.}
\label{fig:parts}
\end{figure}
#+END_EXPORT
In the following, we describe the experimental setup, the results and
the end-to-end model. For all these steps, we decompose the overall
IoT architecture into three parts: the IoT device part, the networking
part and the cloud part, as displayed on Figure \ref{fig:parts}.
* Experimental setup
#+Latex: \label{sec:model}
In this section, we describe the experimental setup employed to
acquire energy measurements for each of the three parts of our
system model. The IoT and the network parts are modeled
through simulations. The Cloud part is modeled using real
servers connected to wattmeters. In this way, it is possible to
evaluate the end-to-end energy consumption of the system.
** IoT Part
In the first place, the IoT part is composed of several sensors connected to an Access Point (AP)
which form a cell. This cell is studied using the ns3 network
simulator. In the experimental scenario, we setup
between 5 and 15 sensors connected to the AP using WiFi 5GHz 802.11n. The node are placed
randomly in a rectangle of $400m^2$ around the AP which corresponds
to a typical use case for a home environment. All
the cell nodes employ the default WIFI energy model provided by ns3. The different
energy values used by the energy model are provided in Table 1. These parameters
were extracted from previous work\cite{halperin_demystifying_nodate,li_end--end_2018} On
IEEE 802.11n. Besides, we suppose that the energy source of each
nodes is not limited during the experiments. Thus each node
can communicate until the end of all the simulations.
As a scenario, sensors send 192 bits packets to the AP composed of: \textbf{1)} A 128 bits
sensors id \textbf{2)} A 32 bits integer representing the temperature \textbf{3)} An integer
timestamp representing the temperature sensing date. They are stored as time series. The data are
transmitted immediately at each sensing interval $I$ that we vary from 1s to 60s. Finally, the AP is in
charge of relaying data to the cloud via the network part.
#+BEGIN_EXPORT latex
\begin{table}[]
\centering
\caption{Simulations Energy Parameters}
\label{tab:wifi-energy}
\subtable[IoT part]{
\begin{tabular}{@{}lr@{}}
Parameter & Value \\ \midrule
Supply Voltage & 3.3V \\
Tx & 0.38A \\
Rx & 0.313A \\
Idle & 0.273A \\ \bottomrule
\end{tabular}}
\hspace{0.3cm}
\subtable[Network part]{
\label{tab:net-energy}
\begin{tabular}{@{}lr@{}}
Parameter & Value \\ \midrule
Idle & 0.00001W \\
Bytes (Tx/Rx) & 3.4nJ \\
Pkt (Tx/Rx) & 192.0nJ \\ \bottomrule
\end{tabular}
}
\end{table}
#+END_EXPORT
** Network Part
The network part represents the a network section starting from the AP to the Cloud excluding the
server. It is also modeled into ns3. We consider the server to be 9 hops away from the AP with a
typical round-trip latency of 100ms from the AP to the server
\cite{li_end--end_2018}. Each node from the AP to the Cloud
is a network switch with static and dynamic network energy consumption. The first 8
hops are edge switches and the last one is consider to be a core router as mentioned in
\cite{jalali_fog_2016}. ECOFEN \cite{orgerie_ecofen:_2011} is used to model the energy
consumption of the network part. ECOFEN is an ns3 network energy module dedicated to wired
networks. It is based on an energy-per-bit and energy-per-packet
model for the dynamic energy consumption
\cite{sivaraman_profiling_2011,Serrano2015}, and it includes also a static energy consumption.
The different values used to instantiate the ECOFEN energy model for the
network part are shown in left part of Table 1 and come from previous work
\cite{cornea_studying_2014-1}.
** Cloud Part
Finally, to measure the energy consumed by the Cloud part, we use a real server from the large-scale
test-bed Grid'5000. Grid'5000 provides clusters composed of several nodes which
are connected to wattmeters. The wattmeters provide 50
instantaneous power measurements per second and per server. This
way, we can benefit from real energy measurements. The server used
in the experiment embeds two Intel Xeon E5-2620 v4 processors with
64 GB of RAM and 600GB
of disk space on a Linux based operating system. This server is configured to use KVM as
virtualization mechanism. We deploy a classical Debian x86_64 distribution on the Virtual Machine
(VM) along with a MySQL database. We use different amounts of allocated memory for the VM namely
1024MB/2048MB/4096MB to highlight its effects on the server energy
consumption. The server only hosts this VM in order to easily isolate its
power consumption.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\includegraphics[width=0.45\linewidth]{./plots/g5k-xp.png}
\caption{Grid'5000 experimental setup.}
\label{fig:g5kExp}
\end{figure}
#+END_EXPORT
The data sent by the IoT devices are simulated using another
server from the same cluster. This server is in charge of sending
the data packets to the VM hosting the application in order to fill
its database. In the following, each data packet coming from an IoT
device and addressed to the application VM is called a request. Consequently, it is easy to vary the
different application characteristics namely: \textbf{1)} The number
of requests, to virtually
add/remove sensors \textbf{2)} The requests interval, to study the
impact of the transmitting frequency. Figure \ref{fig:g5kExp} presents this simulation
setup.
* Evaluation
#+LaTeX: \label{sec:eval}
In this section, we analyze the experimental results.
** IoT and Network Power Consumption
In a first place, we start by studying the impact of the sensors' transmission frequency on their
energy consumption. To this end, we run several simulations in ns3 with 15 sensors using
different transmission frequencies. The results provided by Table
\ref{tab:sensorsSendIntervalEffects} show that the transmission frequency has a very low impact
on the energy consumption and on the average end-to-end application delay. It has an impact of
course, but it is very limited. This due to the fact that in such a scenario with very small
number of communications spread over the time, sensors don't have to contend for accessing to the
Wifi channel.
#+BEGIN_EXPORT latex
% Please add the following required packages to your document preamble:
% \usepackage{booktabs}
\begin{table*}[]
\centering
\caption{Sensors transmission interval effects with 15 sensors}
\label{tab:sensorsSendIntervalEffects}
\begin{tabular}{@{}lrrrrr@{}}
\toprule
Transmission Interval & 10s & 30s & 50s & 70s & 90s \\ \midrule
Sensor Power & 13.517\hl{94}W & 13.517\hl{67}W & 13.51767W & 13.51767W & 13.517\hl{61}W \\
Network Power & 0.441\hl{88}W & 0.441\hl{77}W & 0.44171W & 0.44171W & 0.441\hl{71}W \\
Application Delay & 0.09951s & 0.10021s & 0.10100s & 0.10203s & 0.10202s \\ \bottomrule
\end{tabular}
\end{table*}
#+END_EXPORT
Previous work \cite{li_end--end_2018} on a similar scenario shows that increasing application
accuracy impacts strongly the energy consumption in the context of data stream analysis. However,
in our case, application accuracy is driven by the sensing interval and thus, the transmission
frequency of the sensors.
In our case with small and sporadic network traffic, these results show that with a reasonable
transmission interval, the energy consumption of the IoT and the
network parts are almost not affected by the
variation of this transmission interval. In fact, transmitted data are not large enough to
leverage the energy consumed by the network.
We then vary the number of sensors in the Wifi cell.
The Figure \ref{fig:sensorsNumber} represents the energy consumed by each simulated part
according to the number of sensors. It is clear that the energy consumed by the network is the
dominant part. However, if the number of sensors is increasing, the energy consumed by the
network can become smaller than the sensors part. In fact, deploying new
sensors in the cell do not introduce much network load. To this end, sensors energy consumption
can become dominant.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\includegraphics[width=0.5\linewidth]{./plots/numberSensors-WIFINET.png}
\caption{Analysis of the variation of the number of sensors on the IoT/Network part energy consumption for a transmission interval of 10s.}
\label{fig:sensorsNumber}
\end{figure}
#+END_EXPORT
** Cloud Energy Consumption
In this end-to-end energy consumption study, cloud accounts for a huge part of the overall energy
consumption. According a report \cite{shehabi_united_2016-1} On United States data center energy
usage, the average Power Usage Effectiveness (PUE) of an hyper-scale data center is 1.2. Thus, in
our analysis, all energy measurement on cloud server will account
for this PUE. It means that the power consumption of the server is multiplied by
the PUE to include the external energy costs like server cooling
and data center facilities \cite{Ehsan}.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\includegraphics[width=0.8\linewidth]{./plots/vmSize-cloud.png}
\caption{Server power consumption multiplied by the PUE (= 1.2) using 20 sensors sending data every 10s for various VM memory sizes}
\label{fig:vmSize}
\end{figure}
#+END_EXPORT
Firstly, we analyze the impact of the VM allocated memory on the server energy
consumption. Figure \ref{fig:vmSize} depicts the server energy consumption according to the VM
allocated memory for 20 sensors sending data every 10s. Note that
the horizontal red line represents
the average energy consumption for the considered sample of energy values. We can see that at
each transmission interval, the server faces spikes of energy
consumption. However, the amount of allocated memory to the VM
does not significantly influence the server energy consumption. In
fact, simple database requests do not need any particular
heavy memory accesses and processing time. Thus, remaining experiments are based on VM with 1024MB
of allocated memory.
Next, we study the effects of increasing the number of sensors on the server energy consumption.
Figure \ref{fig:sensorsNumber-server} presents the results of the average server energy
consumption when varying the number of sensors from 20 to 500, while Figure
\ref{fig:sensorsNumber-WPS} presents the average server energy cost per sensor according to the
number of sensors. These results show a clear linear relation between the number of sensors and
the server energy consumption. Moreover, we can see that the more sensors we have per VM, the
more energy we can save. In fact, since the server's idle power
consumption is high (around 97 Watts), it is more
energy efficient to maximize the number of sensors per server. As shown on Figure
\ref{fig:sensorsNumber-WPS}, a significant amount of energy can be save when passing from 20 to
300 sensors per VM. Note that these measurements are not the row
measurements taken from the wattmeters: they include the PUE
but they are not shared among all the VMs that could be hosted on this
server. So, for the studied server, its static power consumption
(also called idle consumption) is around 83.2 Watts and we consider
a PUE of 1.2, this value is taken from \cite{shehabi_united_2016-1}}.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\subfigure[Average server energy consumption multiplied by the PUE (= 1.2)]{
\includegraphics[width=0.4\linewidth]{./plots/sensorsNumberLine-cloud.png}
\label{fig:sensorsNumber-server}
}
\hspace{0.5cm}
\subfigure[Average sensors energy cost on the server hosting only our VM]{
\includegraphics[width=0.4\linewidth]{./plots/WPS-cloud.png}
\label{fig:sensorsNumber-WPS}
}
\caption{Server energy consumption multiplied by the PUE (= 1.2) for sensors sending data every 10s}
\label{fig:sensorsNumber-cloud}
\end{figure}
#+END_EXPORT
A last parameter can leverage server energy consumption, namely
sensors transmission interval. In addition
to increasing the application accuracy, sensors transmission frequency increases network traffic and
database accesses. Figure \ref{fig:sensorsFrequency} presents the impact on the server energy
consumption when changing the transmission interval of 50 sensors
to 1s, 10s and 30s. We can see that, the lower sensors transmission
interval is, the more server energy consumption peaks
occur. Therefore, it leads to an increase of the server energy consumption.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\includegraphics[scale=0.5]{plots/sendInterval-cloud.png}
\caption{Server energy consumption multiplied by the PUE (= 1.2) for 50 sensors sending requests at different transmission interval.}
\label{fig:sensorsFrequency}
\end{figure}
#+END_EXPORT
* End-To-End Consumption Model
#+LaTeX: \label{sec:discuss}
To have an overview of the energy consumed by the overall system, it is important to consider the
end-to-end energy consumption.
We detail here the model used to attribute the energy
consumption of our application for each part of the
architecture. For a given IoT device, we have:
1. For the IoT part, the entire consumption of the IoT device
belongs to the system's accounted consumption.
2. For the network part, the data packets generated by the IoT
device travel through network switches, routers and ports that
are shared with other trafic.
3. For the cloud part, the VM hosthing the data is shared with
other IoT devices belonging to the same application and the
server hosting the VM also hosts other VMs. Furthermore, the
server belongs to a data center and takes part in the overall
energy drawn to cool the server room.
Concerning the IoT part, we include the entire IoT device power
consumption. Indeed, in our targeted low-bandwidth IoT application,
the sensor is dedicated to this application. From Table 1, one can
derive that the static power
consumption of one IoT sensor is around 0.9 Watts. Its dynamic part
depends on the transmission frequency.
Concerning the sharing of the network costs, for each router, we
consider its aggregate bandwidth (on all the ports), its average
link utilization and the share taken by our IoT application. For a
given network device, we compute our share of the static energy
part as follows:
#+BEGIN_EXPORT latex
\[P_{static}^{netdevice} = \frac{P_{static}^{device} \times Bandwidth^{application}}{AggregateBandwidth^{device}
\times LinkUtilization^{device}}\]
#+End_EXPORT
where $P_{static}^{device}$ is the static power consumption of the
network device (switch fabrics for instance or gateway),
$Bandwidth^{application }$ Is the bandwidth used by our IoT application,
$AggregateBandwidth^{device }$ is the overall aggregated bandwidth of the
network device on all its ports, and $LinkUtilization^{device}$ is the
effective link utilization percentage. The $Bandwidth^{application }$
depends on the transmission frequency in our use-case.
The formula includes the
link utilization in order to charge for the effective energy cost
per trafic and not for the theoretical upper bound which is the
link bandwidth. Indeed, using such an upper bound leads to greatly
underestimate our energy part, since link utilization typically
varies between 5 to 40% \cite{Hassidim2013,Zhang2016}.
Similarly, for each network port, we take the share attributable to
our application: the ratio of our bandwidth utilization over the
port bandwidth multiplied by the link utilization and the overall
static power consumption of the port. Table \ref{tab:netbidules}
summarizes the parameters used in our model, they are taken from
\cite{mahadevan_power_2009,Hassidim2013}. These are the parameters
used in our formula to compute the values that we used in the
simulations and that are presented in left part of Table 1.
#+BEGIN_EXPORT latex
\begin{table}[]
\centering
\caption{Network Devices Parameters}
\label{tab:netbidules}
\begin{tabular}{l|l}
Device & ~Parameters \\ \midrule
Gateway & ~Static power = 8.3 Watts, Bandwidth = 54Mbps, Utilization = 10\% \\
Core router & ~Static power = 555 Watts, 48 ports of 1 Gbps, Utilization = 25\% \\
Edge switch~ & ~Static power = 150 Watts, 48 ports of 1 Gbps, Utilization = 25\% \\
\bottomrule
\end{tabular}}
\end{table}
#+END_EXPORT
For the sharing of the Cloud costs, we take into account the number
of VMs that a server can host, the CPU utilization of a VM and the
PUE. For a given Cloud server hosting our IoT application, we
compute our share of the static energy part as follows:
#+BEGIN_EXPORT latex
\[P_{static}^{Cloudserver} = \frac{P_{static}^{server} \times PUE^{DataCenter}}{HostedVMs^{server}}\]
#+End_EXPORT
Where $P_{static}^{server}$ is the static power consumption of the
server, $PUE^{DataCenter}$ is the data center PUE, and
$HostedVMs^{server}$ is the number of VMs a server can host. This last
parameter should be adjusted in the case of VMs with multiple
virtual CPUs. We do not
consider here over-commitment of Cloud servers. Yet, the dynamic
energy part is computed with the real dynamic measurements, so it
accounts for VM over-provisionning and resource under-utilization.
In our case, the Cloud server has 14 cores, which corresponds to
the potential hosting of 14 small VMs with one virtual CPU each,
and each vCPU is pinned to a server core. We consider that for
fault-tolerance purpose, the IoT application has a replication
factor of 2, meaning that two cloud servers store its database.
The Figure \ref{fig:end-to-end} represents the end-to-end system
energy consumption using the model described above while varying
the number of sensors for a transmission interval of 10
seconds. The values are extracted from the experiments presented in
the previous section.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
\hspace{1cm}
\includegraphics[scale=0.35]{plots/final.png}
\label{fig:end-to-end}
\caption{End-to-end network energy consumption using sensors interval of 10s}
\end{figure}
#+END_EXPORT
Note that, for small-scale systems, with WiFi IoT devices, the IoT
sensor part is dominant in the overall energy consumption. Indeed,
the IoT application induces a very small cost on Cloud and network
infrastructures compared to the IoT device cost. But, our model
assumes that a single VM is handling multiple users (up to 300
sensors), thus being energy-efficient. Conclusions would be
different with one VM per user in the case of no over-commitment on
the Cloud side. For the network infrastructure, in our case of
low-bandwidth utilization (one data packet every 10 seconds), the
impact is almost negligible.
Another way of looking at these results is to observe that only for
a high number of sensors (more than 300), the power consumption of Cloud and
network parts start to be negligible (few percent). It means that,
if IoT applications handle clients one by one (i.e. one VM per
client), the impact is high on cloud and network part if they have
only few sensors. The energy efficiency is really poor for only few
devices: with 20 IoT sensors, the overall energy cost to handle these
devices is 2.5 times the energy consumption of the IoT devices
themselves. Instead of increasing the number of sensors, which
would result in a higher overall energy consumption, one should
focus on reducing the energy consumption of IoT devices, especially
WiFi devices which are common due to WiFi availability
everywhere. One could also focus on improving the energy cost of
Cloud and network infrastructure for low-bandwidth applications and
few devices.
* Conclusion
#+LaTeX: \label{sec:cl}
Information and Communication Technology takes a growing part in the
worldwide energy consumption. One of the root causes of this increase
lies in the multiplication of connected devices. Each object of the
Internet-of-Things often does not consume much energy by itself. Yet,
their number and the infrastructures they require to properly work
have leverage.
In this paper, we combine simulations and real
measurements to study the energy impact of IoT devices. In particular,
we analyze the energy consumption of Cloud and telecommunication
infrastructures induced by the utilization of connected devices.
Through the fine-grain analysis of a given low-bandwidth IoT device
periodically sending data to a Cloud server using WiFi,
we propose an end-to-end energy consumption model.
This model provides insights on the hidden part of the iceberg: the
impact of IoT devices on the energy consumption of Cloud and network
infrastructures. On our use-case, we show that for a given sensor, its
larger energy consumption is on the sensor part. But the impact on the
Cloud and network part is huge when using only few sensors with
low-bandwidth applications.
Consequently, with the
IoT exploding growth, it becomes necessary to improve the energy
efficiency of applications hosted on Cloud infrastructures and of IoT devices.
Our future work includes studying other types of IoT wireless
transmission techniques that would be more energy-efficient. We also
plan to study other
IoT applications in order to increase the applicability of our model
and provide advice for increasing the energy-efficiency of IoT infrastructures.
\bibliographystyle{IEEEtran}
\bibliography{references}
* Data Provenance :noexport:
:PROPERTIES:
:header-args: :eval never-export
:END:
** Data Analysis (R Scripts)
*** Utils
**** R
RUtils is intended to load logs (data.csv) and providing
simple plot function for them.
#+NAME: RUtils
#+BEGIN_SRC R :eval never
library("tidyverse")
# Fell free to update the following
labels=c(time="Time (s)",sensorsSendInterval="Sensors Send Interval (s)", sensorsNumber="Number of sensors")
PUE=1.2
ns3SimTime=1800
g5kSimTime=300
loadData=function(path){
data=read_csv(path)
if("sensorsEnergy"%in%colnames(data)){ # If it is ns3 logs
data=data%>%mutate(sensorsEnergy=sensorsEnergy/ns3SimTime) # Convert to watts
data=data%>%mutate(networkEnergy=networkEnergy/ns3SimTime)
data=data%>%mutate(networkEnergy=networkEnergy+getSwitchesIDLE(sensorsNumber,sensorsSendInterval)) # Add Idle conso of switches
data=data%>%mutate(totalEnergy=totalEnergy/ns3SimTime)
}
else{ # Log from g5k
data=data%>%mutate(energy=energy*PUE) # Take into account PUE
data=data%>%filter(time<=g5kSimTime) # Remove extrats values (theorical sim time != real sim time)
}
}
getSwitchesIDLE=function(nbSensors, sendInterval){
pktSize=192
nEdgeRouter=8
nCoreRouter=1
EdgeIdle=4095
EdgeMax=4550
EdgeTraffic=560*10^9
CoreIdle=11070
CoreMax=12300
CoreTraffic=4480*10^9
# Apply 0.6 factor
EdgeTraffic=EdgeTraffic*0.6
CoreTraffic=CoreTraffic*0.6
totalTraffic=pktSize/sendInterval*nbSensors
EdgeConso=EdgeIdle*(totalTraffic/EdgeTraffic)
CoreConso=CoreIdle*(totalTraffic/CoreTraffic)
return(EdgeConso+CoreConso)
}
# Get label according to varName
getLabel=function(varName){
if(is.na(labels[varName])){
return(varName)
}
return(labels[varName])
}
applyTheme=function(plot,...){
palette<- c("#00AFBB", "#E7B800", "#FC4E07","#0abb00")
plot=plot+
theme_bw(...)+
scale_fill_manual(values=palette)+
scale_colour_manual(values=palette)
return(plot)
}
#+END_SRC
**** Bash
***** Plots -> PDF
Merge all plots in plots/ folder into a pdf file.
#+NAME: plotToPDF
#+BEGIN_SRC bash :results output :noweb yes
orgFile="plots/plots.org"
<<singleRun>> # To get all default arguments
# Write helper function
function write {
echo "$1" >> $orgFile
}
echo "#+TITLE: Analysis" > $orgFile
write "#+LATEX_HEADER: \usepackage{fullpage}"
write "#+OPTIONS: toc:nil"
# Default arguments
write '\begin{center}'
write '\begin{tabular}{lr}'
write 'Parameters & Values\\'
write '\hline'
write "sensorsPktSize & ${sensorsPktSize} bytes\\\\"
write "sensorsSendInterval & ${sensorsSendInterval}s\\\\"
write "sensorsNumber & ${sensorsNumber}\\\\"
write "nbHop & ${nbHop}\\\\"
write "linksBandwidth & ${linksBandwidth}Mbps\\\\"
write "linksLatency & ${linksLatency}ms\\\\"
write '\end{tabular}'
write '\newline'
write '\end{center}'
for plot in $(find plots/ -type f -name "*.png")
do
write "\includegraphics[width=0.5\linewidth]{$(basename ${plot})}"
done
# Export to pdf
emacs $orgFile --batch -f org-latex-export-to-pdf --kill
#+END_SRC
***** CSVs -> data.csv (G5K)
Merge all energy file into one (and add additional fields).
#+NAME: G5K-mergeCSV
#+BEGIN_SRC sh
#!/bin/bash
whichLog="last"
logsLocation="logs/g5k"
whichLog="${logsLocation}/${whichLog}"
logFile="$(dirname $(readlink -f $0))"/$whichLog/simLogs.txt
dataFile=$(dirname "$logFile")/data.csv
getValue () {
line=$(echo "$1" | grep "Simulation para"|sed "s/Simulation parameters: //g")
key=$2
echo "$line"|awk 'BEGIN{RS=" ";FS=":"}"'$key'"==$1{gsub("\n","",$0);print $2}'
}
##### Add extract info to energy #####
IFS=$'\n'
for cmd in $(cat $logFile|grep "Simulation parameters")
do
nodeName=$(getValue $cmd serverNodeName)
from=$(getValue $cmd simStart)
to=$(getValue $cmd simEnd)
vmSize=$(getValue $cmd vmSize)
nbSensors=$(getValue $cmd nbSensors)
simKey=$(getValue $cmd simKey)
sendInterval=$(getValue $cmd sensorsSendInterval)
csvFile="$whichLog/${simKey}_${vmSize}VMSIZE_${nbSensors}NBSENSORS_${from}${to}.csv"
csvFileIDLE="$whichLog/${simKey}_${vmSize}VMSIZE_${nbSensors}NBSENSORS_${from}${to}_IDLE.csv"
tmpFile=${csvFile}_tmp
echo ts,energy,simKey,vmSize,nbSensors,time,state,sendInterval > $tmpFile
minTs=$(tail -n+2 $csvFile|awk -F"," 'BEGIN{min=0}$1<min||min==0{min=$1}END{print(min)}') # To compute ts field
minTsIDLE=$(tail -n+2 $csvFileIDLE|awk -F"," 'BEGIN{min=0}$1<min||min==0{min=$1}END{print(min)}') # To compute ts field
tail -n+2 ${csvFile} | awk -F"," '{print $0",'$simKey','$vmSize','$nbSensors',"$1-'$minTs'",sim,"'$sendInterval'}' >> $tmpFile
tail -n+2 ${csvFileIDLE} | awk -F"," '{print $0",'$simKey','$vmSize','$nbSensors',"$1-'$minTsIDLE'",IDLE,"'$sendInterval'}' >> $tmpFile
done
##### Fill dataFile #####
echo ts,energy,simKey,vmSize,nbSensors,time,state,sendInterval > $dataFile
for tmpFile in $(find ${whichLog}/*_tmp -type f)
do
tail -n+2 $tmpFile >> $dataFile
rm $tmpFile # Pay attention to this line :D
done
#+END_SRC
#+RESULTS: G5K-mergeCSV
#+RESULTS: mergeCSV
***** Log -> data.csv (ns3)
logToCSV extract usefull data from logs and put them into logs/data.csv.
#+NAME: NS3-logToCSV
#+BEGIN_SRC bash :results output
logsFolder="./logs/ns3/last/"
csvOutput="$logsFolder/data.csv"
# First save csv header line
aLog=$(find $logsFolder -type f -name "*.org"|head -n 1)
metrics=$(cat $aLog|grep "\-METRICSLINE\-"|sed "s/-METRICSLINE-//g")
echo $metrics | awk '{for(i=1;i<=NF;i++){split($i,elem,":");printf(elem[1]);if(i<NF)printf(",");else{print("")}}}' > $csvOutput
# Second save all values
for logFile in $(find $logsFolder -type f -name "*.org")
do
metrics=$(cat $logFile|grep "\-METRICSLINE\-"|sed "s/-METRICSLINE-//g")
echo $metrics | awk '{for(i=1;i<=NF;i++){split($i,elem,":");printf(elem[2]);if(i<NF)printf(",");else{print("")}}}' >> $csvOutput
done
#+END_SRC
#+RESULTS: NS3-logToCSV
*** Plot Scripts
**** Random R Scripts
Table sensorsSendInterval~Sensors+NetEnergyconsumption
#+BEGIN_SRC R :noweb yes :results output
<<RUtils>>
data=loadData("logs/ns3/last/data.csv")
sensorsE=data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==15) %>%select(sensorsSendInterval,sensorsEnergy)%>%arrange(sensorsSendInterval)
delay=data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==15) %>%select(sensorsSendInterval,avgDelay)%>%arrange(sensorsSendInterval)
netE=data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==15) %>%select(sensorsSendInterval,networkEnergy)%>%arrange(sensorsSendInterval)
formatData=right_join(sensorsE,netE)%>%right_join(delay)%>%filter(((sensorsSendInterval/10)%%2)!=0)
print(t(formatData))
#+END_SRC
#+RESULTS:
: [,1] [,2] [,3] [,4] [,5]
: sensorsSendInterval 10.0000000 30.000000 50.000000 70.000000 90.000000
: sensorsEnergy 13.5179444 13.517667 13.517667 13.517667 13.517611
: networkEnergy 10.4417825 10.441668 10.441612 10.441612 10.441612
: avgDelay 0.0995173 0.100214 0.101002 0.102034 0.102025
Figure Sensors Position ~ Energy/Delay
#+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsPosition-delayenergy.png
<<RUtils>>
tr=11 # Offset to center delay plot
data=loadData("logs/ns3/last/data.csv")
data=data%>%filter(simKey=="SENSORSPOS",sensorsNumber==9)
p=ggplot(data,aes(y=sensorsEnergy,x=positionSeed,color="Energy"))+xlab(getLabel("Sensors Position Seed"))+ylab(getLabel("Sensors Power Consumption (W)"))+
geom_line()+geom_point()+geom_line(aes(y=(avgDelay-tr),color="Delay"))+geom_point(aes(y=(avgDelay-tr),color="Delay"))+expand_limits(y=c(0,15))+
scale_y_continuous(sec.axis = sec_axis(~.+tr, name = "Application Delay (s)")) +
guides(color=guide_legend(title="Curves"))
p=applyTheme(p)
p=p+theme(axis.title.y.right = element_text(margin = margin(t = 0, r = -8, b = 0, l = 10)))
ggsave("plots/sensorsPosition-delayenergy.png",dpi=80, width=4, height=3.2)
#+END_SRC
#+RESULTS:
[[file:plots/sensorsPosition-delayenergy.png]]
Watt per sensor on server
#+BEGIN_SRC R :noweb yes :results output
<<RUtils>>
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()
data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%distinct()%>%ungroup()
data=data%>%distinct(nbSensors,.keep_all=TRUE)
data=data%>%mutate(WPS=(avgEnergy/nbSensors))
print(data%>%select(WPS,nbSensors))
#+END_SRC
Impact of vm size
#+BEGIN_SRC R :results graphics :file plots/vmSizeBar-cloud.png
library("tidyverse")
PUE=1.2
# Load data
data=read_csv("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="vmSize")%>%mutate(energy=PUE*energy)%>%filter(time<=300)
data=data%>%group_by(vmSize)%>%mutate(energy=mean(energy))%>%slice(1L)%>%ungroup()
data=data%>%mutate(vmSize=as.character(vmSize))
ggplot(data) + geom_bar(aes(x=vmSize,y=energy),stat="identity")+expand_limits(y=c(75,100))+ylab("Server Power Consumption (W)")+
xlab("Experiment Time (s)")+scale_y_log10()
ggsave("plots/vmSizeBar-cloud.png",dpi=90,height=3,width=6)
#+END_SRC
#+RESULTS:
[[file:plots/vmSizeBar-cloud.png]]
#+NAME: ssiNet
#+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsSendInterval-net.png
<<NS3-RUtils>>
# Load Data
data=read_csv("logs/ns3/last/data.csv")
data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==20) %>% ggplot(aes(x=sensorsSendInterval,y=networkEnergy))+xlab(getLabel("sensorsSendInterval"))+ylab(getLabel("networkEnergy"))+
geom_line()+labs(title="For 20 sensors")
ggsave("plots/sensorsSendInterval-net.png",dpi=80)
#+END_SRC
Effect of the number of sensors on the application delay
#+BEGIN_SRC R :noweb yes :results graphics :file plots/delay-nbsensors.png
<<NS3-RUtils>>
# Load Data
data=read_csv("logs/ns3/last/data.csv")
data%>%filter(simKey=="NBSENSORS") %>% ggplot(aes(y=avgDelay,x=sensorsNumber))+xlab(getLabel("sensorsNumber"))+ylab(getLabel("avgDelay"))+
geom_line()+labs(title="For 20 sensors")
ggsave("plots/delay-nbsensors.png",dpi=80)
#+END_SRC
#+RESULTS:
[[file:plots/delay-nbsensors.png]]
#+NAME: ssiWifi
#+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsSendInterval-wifi.png
<<NS3-RUtils>>
data=read_csv("logs/ns3/last/data.csv")
data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==20) %>% ggplot(aes(x=sensorsSendInterval,y=sensorsEnergy))+xlab(getLabel("sensorsSendInterval"))+ylab(getLabel("sensorsEnergy"))+
geom_line() + geom_line()+labs(title="For 20 sensors")
ggsave("plots/sensorsSendInterval-wifi.png",dpi=80)
#+END_SRC
#+BEGIN_SRC R :results graphics :noweb yes :file plots/plot-final.png :session *R*
<<NS3-RUtils>>
simTime=1800
# Network
data=read_csv("logs/ns3/last/data.csv")
data=data%>%filter(simKey=="NBSENSORS")
dataC5=data%>%filter(sensorsNumber==5)%>% mutate(energy=networkEnergy/simTime) %>%select(energy,sensorsNumber)
dataC10=data%>%filter(sensorsNumber==10)%>%mutate(energy=networkEnergy/simTime) %>%select(energy,sensorsNumber)
dataNet=rbind(dataC5,dataC10)%>%mutate(type="Network")
# Network
dataS5=data%>%filter(sensorsNumber==5)%>% mutate(energy=sensorsEnergy/simTime) %>%select(energy,sensorsNumber)
dataS10=data%>%filter(sensorsNumber==10)%>%mutate(energy=sensorsEnergy/simTime) %>%select(energy,sensorsNumber)
dataS=rbind(dataS5,dataS10)%>%mutate(type="Sensors")
data=rbind(dataNet,dataS)%>%mutate(sensorsNumber=as.character(sensorsNumber))
ggplot(data)+geom_bar(aes(x=sensorsNumber,y=energy,fill=type),stat="identity")+xlab("Sensors Number")+ylab("Power Consumption (W)")+guides(fill=guide_legend(title="Part"))
ggsave("plots/plot-final.png",dpi=80)
#+END_SRC
**** Plot In Paper
Power sensors vs network
#+BEGIN_SRC R :noweb yes :results graphics :file plots/numberSensors-WIFINET.png :session *R*
<<RUtils>>
data=loadData("logs/ns3/last/data.csv")
data=data%>%filter(simKey=="NBSENSORS")
dataW=data%>%mutate(energy=sensorsEnergy)%>% mutate(type="Sensors") %>% select(sensorsNumber,energy,type)
dataN=data%>%mutate(energy=networkEnergy)%>% mutate(type="Network") %>% select(sensorsNumber,energy,type)
data=rbind(dataN,dataW)
data=data%>%mutate(sensorsNumber=as.character(sensorsNumber))
data=data%>%mutate(sensorsNumber=fct_reorder(sensorsNumber,as.numeric(sensorsNumber)))
data=data%>%filter(sensorsNumber%in%c(2,4,6,8,10))
p=ggplot(data)+geom_bar(aes(x=sensorsNumber,y=energy,fill=type),position="dodge",stat="identity")+
xlab(getLabel("sensorsNumber"))+ ylab("Power Consumption (W)") + guides(fill=guide_legend(title=""))
p=applyTheme(p)+theme(text = element_text(size=15))
size=5
ggsave("plots/numberSensors-WIFINET.png",dpi=90,width=size,height=size-1)
#+END_SRC
#+RESULTS:
[[file:plots/numberSensors-WIFINET.png]]
Final plot: Energy cloud, network and sensors
#+BEGIN_SRC R :noweb yes :results graphics :file plots/final.png
<<RUtils>>
# Linear Approx
approx=function(data1, data2,nbSensors){
x1=data1$sensorsNumber
y1=data1$energy
x2=data2$sensorsNumber
y2=data2$energy
a=((y2-y1)/(x2-x1))
b=y1-a*x1
return(a*nbSensors+b)
}
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="nbSensors")
# Cloud
data=data%>%mutate(sensorsNumber=nbSensors)
data20=data%>%filter(nbSensors==20)%>%mutate(energy=mean(energy)) %>% slice(1L)
data100=data%>%filter(nbSensors==100)%>%mutate(energy=mean(energy)) %>% slice(1L)
data300=data%>%filter(nbSensors==300)%>%mutate(energy=mean(energy)) %>% slice(1L)
dataCloud=rbind(data20,data100,data300)%>%mutate(sensorsNumber=nbSensors)%>%mutate(type="Cloud")%>%select(sensorsNumber,energy,type)
dataCloud=bind_rows(dataCloud,tibble(sensorsNumber=1,energy=approx(data20,data100,1),type="Cloud"))
dataCloud=dataCloud%>%mutate(energy=energy/7) # Divide by 7 because 14 core so 1 machine can host 14 vm but we use redundancy (2VM for 1app)
# Network
data=loadData("./logs/ns3/last/data.csv")
data=data%>%filter(simKey=="NBSENSORS")
dataN5=data%>%filter(sensorsNumber==5)%>% mutate(energy=networkEnergy) %>%select(energy,sensorsNumber)
dataN10=data%>%filter(sensorsNumber==10)%>%mutate(energy=networkEnergy) %>%select(energy,sensorsNumber)
dataNet=rbind(dataN5,dataN10)
fakeNet=tibble(sensorsNumber=c(1,20,100,300))
fakeNet=fakeNet%>%mutate(energy=approx(dataN5,dataN10,sensorsNumber),type="Network")
# Sensors
dataS5=data%>%filter(sensorsNumber==5)%>% mutate(energy=sensorsEnergy) %>%select(energy,sensorsNumber)
dataS10=data%>%filter(sensorsNumber==10)%>%mutate(energy=sensorsEnergy) %>%select(energy,sensorsNumber)
dataS=rbind(dataS5,dataS10)
fakeS=tibble(sensorsNumber=c(1,20,100,300))
fakeS=fakeNet%>%mutate(energy=approx(dataS5,dataS10,sensorsNumber),type="Sensors")
# Combine Net/Sensors/Cloud and order factors
fakeData=rbind(fakeNet,fakeS,dataCloud)
fakeData=fakeData%>%mutate(sensorsNumber=as.character(sensorsNumber))
fakeData=fakeData%>%mutate(sensorsNumber=fct_reorder(sensorsNumber,as.numeric(sensorsNumber)))
fakeData$type=factor(fakeData$type,ordered=TRUE,levels=c("Sensors","Network","Cloud"))
# Plot
p=ggplot(fakeData)+geom_bar(position="dodge2",colour="black",aes(x=sensorsNumber,y=energy,fill=type),stat="identity")+
xlab("Sensors Number")+ylab("Power Consumption (W)")+guides(fill=guide_legend(title="System Part"))
p=applyTheme(p)+theme(text = element_text(size=16))
ggsave("plots/final.png",dpi=90,width=8,height=5.5)
#+END_SRC
#+RESULTS:
[[file:plots/final.png]]
Impact of vm size
#+BEGIN_SRC R :noweb yes :results graphics :noweb yes :file plots/vmSize-cloud.png
<<RUtils>>
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="vmSize")%>%filter(time<=300)
data=data%>%mutate(vmSize=paste0(vmSize," MB"))
data=data%>%group_by(vmSize)%>%mutate(avgEnergy=mean(energy))%>%ungroup()
p=ggplot(data,aes(x=time, y=energy)) + geom_line()+facet_wrap(~vmSize)+geom_hline(aes(yintercept=avgEnergy),color="Red",size=1.0)+expand_limits(y=c(0,40))+ylab("Server Power Consumption (W)")+
xlab("Experiment Time (s)")
p=applyTheme(p)
ggsave("plots/vmSize-cloud.png",dpi=90,height=3,width=6)
#+END_SRC
#+RESULTS:
[[file:plots/vmSize-cloud.png]]
Impact of sensors number
#+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsNumber-cloud.png
<<RUtils>>
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()
data=data%>%mutate(nbSensorsSort=nbSensors)
data=data%>%mutate(nbSensors=paste0(nbSensors," Sensors"))
data$nbSensors=fct_reorder(data$nbSensors, data$nbSensorsSort)
data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%ungroup()
p=ggplot(data,aes(x=time, y=energy)) + geom_line()+facet_wrap(~nbSensors)+expand_limits(y=c(0,40))+ylab("Server Power Consumption (W)")+
xlab("Experiment Time (s)")+geom_hline(aes(yintercept=avgEnergy),color="Red",size=1.0)
p=applyTheme(p)
ggsave("plots/sensorsNumber-cloud.png",dpi=90,height=3,width=6)
#+END_SRC
#+RESULTS:
[[file:plots/sensorsNumber-cloud.png]]
#+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsNumberLine-cloud.png :session *R:2*
<<RUtils>>
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()
data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%distinct()%>%ungroup()
data=data%>%distinct(nbSensors,.keep_all=TRUE)
data=data%>%mutate(WPS=(avgEnergy/nbSensors))
p=ggplot(data,aes(x=nbSensors, y=avgEnergy)) + geom_point() +geom_line()+
xlab(getLabel("sensorsNumber"))+ylab("Average server power consumption (W)")
p=applyTheme(p)+theme(text = element_text(size=14))+ expand_limits(y=108)
ggsave("plots/sensorsNumberLine-cloud.png",dpi=90,height=4.5,width=4)
#+END_SRC
#+RESULTS:
[[file:plots/sensorsNumberLine-cloud.png]]
#+BEGIN_SRC R :noweb yes :results graphics :file plots/WPS-cloud.png :session *R:2*
<<RUtils>>
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()
data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%distinct()%>%ungroup()
data=data%>%distinct(nbSensors,.keep_all=TRUE)
data=data%>%mutate(WPS=(avgEnergy/nbSensors))
oldNb=data$nbSensors
data=data%>%mutate(nbSensors=as.character(nbSensors))
data$nbSensors=fct_reorder(data$nbSensors,oldNb)
p=ggplot(data,aes(x=nbSensors, y=WPS)) + geom_bar(stat="identity")+
xlab(getLabel("sensorsNumber"))+ylab("Server power cost per sensors (W)")
p=applyTheme(p)+theme(text = element_text(size=14))+ theme(axis.title.y = element_text(margin = margin(t = 0, r = 8, b = 0, l = 0)))
ggsave("plots/WPS-cloud.png",dpi=90,height=4,width=4)
#+END_SRC
#+RESULTS:
[[file:plots/WPS-cloud.png]]
#+BEGIN_SRC R :noweb yes :results graphics :file plots/sendInterval-cloud.png
<<RUtils>>
# Load data
data=loadData("./logs/g5k/last/data.csv")
data=data%>%filter(state=="sim",simKey=="sendInterval")%>%ungroup()
oldSendInterval=data$sendInterval
data=data%>%mutate(sendInterval=paste0(sendInterval,"s"))
data$sendInterval=fct_reorder(data$sendInterval,oldSendInterval)
data=data%>%group_by(sendInterval)%>%mutate(avgEnergy=mean(energy))%>%ungroup()
print(data)
p=ggplot(data,aes(x=time, y=energy)) + geom_line()+facet_wrap(~sendInterval)+expand_limits(y=c(0,40))+ylab("Server power consumption (W)")+
xlab("Experiment Time (s)")+geom_hline(aes(yintercept=avgEnergy),color="Red",size=1.0)
p=applyTheme(p)
ggsave("plots/sendInterval-cloud.png",dpi=120,height=3,width=6)
#+END_SRC
#+RESULTS:
[[file:plots/sendInterval-cloud.png]]
* Emacs settings :noexport:
# Local Variables:
# eval: (unless (boundp 'org-latex-classes) (setq org-latex-classes nil))
# eval: (add-to-list 'org-latex-classes
# '("llncs" "\\documentclass[conference]{llncs}\n \[NO-DEFAULT-PACKAGES]\n \[EXTRA]\n" ("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" . "\\subsection*{%s}") ("\\subsubsection{%s}" . "\\subsubsection*{%s}") ("\\paragraph{%s}" . "\\paragraph*{%s}") ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
# End:
Reference in a new issue View git blame Copy permalink