X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/mpi-energy2.git/blobdiff_plain/47017a08cb1074a60d85aae0f647d757c576c8b7..a0bdba4899ff6f56547996a8f02d8c2d407fb562:/mpi-energy2-extension/Heter_paper.tex?ds=inline

diff --git a/mpi-energy2-extension/Heter_paper.tex b/mpi-energy2-extension/Heter_paper.tex
index 3fa9968..35ec661 100644
--- a/mpi-energy2-extension/Heter_paper.tex
+++ b/mpi-energy2-extension/Heter_paper.tex
@@ -107,9 +107,9 @@
 
 
 
-\title{Energy Consumption Reduction with DVFS for Message \\
+\title{Optimizing Energy Consumption with DVFS for Message \\
          Passing Iterative Applications on \\
-                    Grid Architecture} 
+                    Grid Architectures} 
   
 
 
@@ -490,9 +490,9 @@ In the considered heterogeneous grid platform, each node $j$ in cluster $i$ may
 different dynamic and static powers from the nodes of the other clusters, 
 noted as $\Pd[ij]$ and $\Ps[ij]$ respectively.  Therefore, even if the distributed 
 message passing iterative application is load balanced, the computation time of each CPU $j$ 
-in cluster $i$ noted $\Tcp[ij]$ may be different and different frequency scaling factors may be
+in cluster $i$ noted $\Tcp[ij]$ may be slightly different due to the delay caused by the scheduler of the operating system. Therefore, different frequency scaling factors may be
 computed in order to decrease the overall energy consumption of the application
-and reduce slack times.  The communication time of a processor $j$ in cluster $i$ is noted as
+and reduce the slack times.  The communication time of a processor $j$ in cluster $i$ is noted as
 $\Tcm[ij]$ and could contain slack times when communicating with slower nodes,
 see Figure~\ref{fig:heter}.  Therefore, all nodes do not have equal
 communication times. While the dynamic energy is computed according to the
@@ -846,8 +846,6 @@ selected clusters and are presented in Table~\ref{table:grid5000}.
 \begin{figure}[!t]
   \centering
   \includegraphics[scale=0.6]{fig/power_consumption.pdf}
-  \AG{I don't understand the labels on the horizontal axis: 10:30:37, 10:30:38,
-    etc.}
   \caption{The power consumption by one core from the Taurus cluster}
   \label{fig:power_cons}
 \end{figure}
@@ -866,7 +864,7 @@ The benchmarks have seven different classes, S, W, A, B, C, D and E, that repres
   \begin{tabular}{|*{7}{c|}}
     \hline
                 &             & Max   & Min   & Diff. &                 &               \\
-    Cluster     & CPU         & Freq. & Freq. & Freq. & No. of cores    & Dynamic power \\
+    Cluster     & CPU         & Freq. & Freq. & Freq. & Cores           & Dynamic power \\
     Name        & model       & GHz   & GHz   & GHz   & per CPU         & of one core   \\
     \hline
                 & Intel       &       &       &         &           &              \\
@@ -922,7 +920,7 @@ Table~\ref{tab:sc} shows the number of nodes used from each cluster for each sce
 \begin{tabular}{|*{4}{c|}}
 \hline
 \multirow{2}{*}{Scenario name}        & \multicolumn{3}{c|} {The participating clusters} \\ \cline{2-4} 
-                                      & Cluster & Site           & No. of  nodes     \\ 
+                                      & Cluster & Site           & Nodes per cluster     \\ 
 \hline
 \multirow{3}{*}{Two sites / 16 nodes} & Taurus & Lyon                & 5                      \\ \cline{2-4} 
                                       & Graphene  & Nancy             & 5                      \\ \cline{2-4} 
@@ -965,7 +963,7 @@ The long distance communications between the two distributed sites increase the
 
 The execution times of these benchmarks 
 over one site with 16 and 32 nodes are also lower when  compared to those of the  two sites 
-scenario. Moreover, most of the benchmarks running over the one site scenario their execution times  are approximately divided by two  when the number of computing nodes is doubled from 16 to 32 nodes (linear speed up according to the number of the nodes).\AG{Parse error (cannot understand the previous sentence).}
+scenario. Moreover, most of the benchmarks running over the one site scenario have their execution times  approximately divided by two  when the number of computing nodes is doubled from 16 to 32 nodes (linear speed up according to the number of the nodes).
 
 However, the execution times and the energy consumptions of EP and MG
 benchmarks, which have no or small communications, are not significantly
@@ -1073,8 +1071,8 @@ in Figures \ref{fig:eng-cons-mc} and \ref{fig:time-mc} respectively.
 \caption{The multicores scenarios}
 \begin{tabular}{|*{4}{c|}}
 \hline
-Scenario name                          & Cluster name & \begin{tabular}[c]{@{}c@{}}No. of  nodes\\ in each cluster\end{tabular} & 
-                                       \begin{tabular}[c]{@{}c@{}}No. of  cores\\ for each node\end{tabular}  \\ \hline
+Scenario name                          & Cluster name & Nodes per cluster & 
+                                       Cores per node  \\ \hline
 \multirow{3}{*}{One core per node}    & Graphite     & 4               & 1                   \\  \cline{2-4}
                                        & Graphene     & 14              & 1                   \\  \cline{2-4}
                                        & Griffon      & 14              & 1                   \\ \hline
