summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLoic Guegan <manzerbredes@mailbox.org>2019-07-19 10:51:16 +0200
committerLoic Guegan <manzerbredes@mailbox.org>2019-07-19 10:51:16 +0200
commit6920157f294ccc5768d54be9440a5da050893240 (patch)
treece662b7af5f5e86b6b437b8524bc88f08fc885c6
parent8291ba58641595f2ed132003b65b00e57aba198f (diff)
Divide by 7 energy on figure 8
-rw-r--r--2019-ICA3PP.org123
-rw-r--r--2019-ICA3PP.pdfbin683252 -> 684871 bytes
-rw-r--r--plots/final.pngbin21308 -> 22921 bytes
3 files changed, 62 insertions, 61 deletions
diff --git a/2019-ICA3PP.org b/2019-ICA3PP.org
index e92e43c..ec25824 100644
--- a/2019-ICA3PP.org
+++ b/2019-ICA3PP.org
@@ -224,39 +224,39 @@ 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.6\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}.
+ #+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
@@ -270,37 +270,37 @@ frequency can vary from one to several packet sent per minute
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.85\linewidth]{./plots/parts2.png}
- \caption{Overview of the IoT architecture.}
- \label{fig:parts}
- \end{figure}
- #+END_EXPORT
+ 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}.
+ 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
-\hl{Ajouter \% de bande passante utilisé par les applis low-rate}
-#+Latex: \label{sec:model}
+ \hl{Ajouter \% de bande passante utilisé par les applis low-rate}
+ #+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
@@ -388,7 +388,7 @@ part and the cloud part, as displayed on Figure \ref{fig:parts}.
#+BEGIN_EXPORT latex
\begin{figure}
\centering
- \includegraphics[width=0.5\linewidth]{./plots/g5k-xp.png}
+ \includegraphics[width=0.45\linewidth]{./plots/g5k-xp.png}
\caption{Grid'5000 experimental setup.}
\label{fig:g5kExp}
\end{figure}
@@ -596,7 +596,7 @@ In our case with small and sporadic network traffic, these results show that wit
\begin{figure}
\centering
\hspace{1cm}
- \includegraphics[scale=0.3]{plots/final.png}
+ \includegraphics[scale=0.4]{plots/final.png}
\label{fig:end-to-end}
\caption{End-to-end network energy consumption using sensors interval of 10s}
\end{figure}
@@ -1084,6 +1084,7 @@ applicability of our model.
fakeData$type=factor(fakeData$type,ordered=TRUE,levels=c("Sensors","Network","Cloud"))
# Plot
+ fakeData=fakeData%>%mutate(energy=energy/7) # Divide by 7 because 14 core so 1 machine can host 14 vm but we use redundancy (2VM for 1app)
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))
diff --git a/2019-ICA3PP.pdf b/2019-ICA3PP.pdf
index a8b7e59..b6afc51 100644
--- a/2019-ICA3PP.pdf
+++ b/2019-ICA3PP.pdf
Binary files differ
diff --git a/plots/final.png b/plots/final.png
index d8ca1ab..31cbb8b 100644
--- a/plots/final.png
+++ b/plots/final.png
Binary files differ