]> AND Private Git Repository - mpi-energy2.git/blobdiff - mpi-energy2-extension/Heter_paper.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
adding reviewers remarks
[mpi-energy2.git] / mpi-energy2-extension / Heter_paper.tex
index 29d06ab07949cea1537a5d1dceacc0f40d898e87..5ef27298690893c35cdb23d425ac60510eec3e40 100644 (file)
@@ -652,7 +652,7 @@ in~\cite{Zhuo_Energy.efficient.Dynamic.Task.Scheduling,Rauber_Analytical.Modelin
     \Require ~
     \begin{description}
     \item [{$N$}] number of clusters in the grid. 
-    \item [{$M$}] number of nodes in each cluster.
+    \item [{$M_i$}] number of nodes in each cluster.
     \item[{$\Tcp[ij]$}] array of all computation times for all nodes during one iteration and with the highest frequency.
     \item[{$\Tcm[ij]$}] array of all communication times for all nodes during one iteration and with the highest frequency.
     \item[{$\Fmax[ij]$}] array of the maximum frequencies for all nodes.
@@ -746,15 +746,15 @@ frequency scaling factors are computed as a ratio between the computation time
 of the slowest node and the computation time of the node $i$ as follows:
 \begin{equation}
   \label{eq:Scp}
-  \Scp[ij] =  \frac{ \mathop{\max\limits_{i=1,\dots N}}\limits_{j=1,\dots,M}(\Tcp[ij])} {\Tcp[ij]}
+  \Scp[ij] =  \frac{ \mathop{\max\limits_{i=1,\dots N}}\limits_{j=1,\dots,M_i}(\Tcp[ij])} {\Tcp[ij]}
 \end{equation}
 Using the initial frequency scaling factors computed in (\ref{eq:Scp}), the
 algorithm computes the initial frequencies for all nodes as a ratio between the
-maximum frequency of node $i$ and the computation scaling factor $\Scp[i]$ as
+maximum frequency of node and its computed scaling factor as
 follows:
 \begin{equation}
   \label{eq:Fint}
-  F_{ij} = \frac{\Fmax[ij]}{\Scp[ij]},~{i=1,2,\dots,N},~{j=1,\dots,M}
+  F_{ij} = \frac{\Fmax[ij]}{\Scp[ij]},~{i=1,2,\dots,N},~{j=1,\dots,M_i}
 \end{equation}
 If the computed initial frequency for a node is not available in the gears of
 that node, it is replaced by the nearest available frequency.  In
@@ -800,7 +800,7 @@ in this paper real experiments were conducted over the Grid'5000 platform.
 
 \subsection{Grid'5000 architecture and power consumption}
 \label{sec.grid5000}
-Grid'5000~\cite{grid5000} is a large-scale testbed that consists of ten sites distributed all over  metropolitan France and Luxembourg. All the sites are connected together via       a special long distance network called RENATER,
+Grid'5000~\cite{grid5000} is a large-scale testbed that consists of ten sites distributed all over  metropolitan France and Luxembourg. All the sites are connected together via a special long distance network called RENATER,
 which is the French National Telecommunication Network for Technology.
 Each site of the grid is composed of a few heterogeneous 
 computing clusters and each cluster contains many homogeneous nodes. In total,
@@ -809,7 +809,7 @@ the clusters and their nodes are connected via  high speed local area networks.
 Two types of local networks are used, Ethernet or Infiniband networks which have  different characteristics in terms of bandwidth and latency.  
 
 Since Grid'5000 is dedicated to  testing, contrary to production grids it allows a user to deploy its own customized operating system on all the booked nodes. The user could have root rights and thus apply DVFS operations while executing a distributed application. Moreover, the Grid'5000 testbed provides at some sites a power measurement tool to capture 
-the power consumption  for each node in those sites. The measured power is the overall consumed power  by all the components of a node at a given instant, such as CPU, hard drive, main-board and memory. For more details refer to
+the power consumption  for each node in those sites. The measured power is the overall consumed power  by all the components of a node at a given instant. For more details refer to
 \cite{Energy_measurement}. In order to correctly measure the CPU power of one core in a node $j$, 
  firstly,  the power consumed by the node while being idle at instant $y$, noted as $\Pidle[jy]$, was measured. Then, the power was measured while running a single thread benchmark with no communication (no idle time) over the same node with its CPU scaled to the maximum available frequency. The latter power measured at time $x$ with maximum frequency for one core of node $j$ is noted $\Pmax[jx]$. The difference between the two measured power consumptions represents the 
 dynamic power consumption of that core with the maximum frequency, see  Figure~\ref{fig:power_cons}. 
@@ -858,7 +858,7 @@ The benchmark suite contains seven applications: CG, MG, EP, LU, BT, SP and FT.
 the same block of operations several times, starting from the initial solution until reaching
 the acceptable approximation of the exact solution.}
  These applications have different computations and communications ratios and strategies which make them good testbed applications to evaluate the proposed algorithm and energy model.
-The benchmarks have seven different classes, S, W, A, B, C, D and E, that represent the size of the problem that the method solves. In this work,  class D was used for all benchmarks in all the experiments presented in the next sections. 
+The benchmarks have seven different classes, S, W, A, B, C, D and E, that represent the size of the problem that the method solves. In the next sections, the  class D was used for all the benchmarks in all the experiments. 
 
 
   
@@ -911,7 +911,7 @@ Two scenarios were considered while selecting the clusters from these two sites
 The main reason 
 for using these two scenarios is to evaluate the influence of long distance communications (higher latency) on the performance of the 
 scaling factors selection algorithm. Indeed, in the first scenario the computations to communications ratio 
-is very low due to the higher communication times which reduce the effect of DVFS operations.
+is very low due to the higher communication times which reduces the effect of the DVFS operations.
 
 The NAS parallel benchmarks are executed over 
 16 and 32 nodes for each scenario. The number of participating computing nodes from each cluster 
@@ -931,7 +931,7 @@ Table~\ref{tab:sc} shows the number of nodes used from each cluster for each sce
                                       & Graphene  & Nancy             & 5                      \\ \cline{2-4} 
                                       & Griffon       & Nancy        & 6                      \\ 
 \hline
-\multirow{3}{*}{Tow sites / 32 nodes} & Taurus  & Lyon               & 10                     \\ \cline{2-4} 
+\multirow{3}{*}{Two sites / 32 nodes} & Taurus  & Lyon               & 10                     \\ \cline{2-4} 
                                       & Graphene  & Nancy             & 10                     \\ \cline{2-4} 
                                       & Griffon     &Nancy           & 12                     \\ 
 \hline
@@ -997,7 +997,7 @@ results in  a lower energy consumption. Indeed, the dynamic  consumed power
 is exponentially related to the CPU's frequency value. On the other hand, the increase in the number of computing nodes can 
 increase the communication times and thus produces less energy saving depending on the 
 benchmarks being executed. The results of benchmarks CG, MG, BT and FT show more 
-energy saving percentage in the one site scenario when executed over 16 nodes than over 32 nodes.  LU and SP consume more energy with 16 nodes than 32 in one site  because their computations to communications ratio is not affected by the increase of the number of local communications. 
+energy saving percentage in the one site scenario when executed over 16 nodes than over 32 nodes.  LU and SP consume more energy with 16 nodes than 32 nodes on one site  because their computations to communications ratio is not affected by the increase of the number of local communications. 
 
 \begin{figure*}[!h]
   \centering
@@ -1031,7 +1031,7 @@ The best energy saving percentage was obtained in the one site scenario with 16
 Figure \ref{fig:per_d} presents the performance degradation percentages for all benchmarks over the two scenarios.
 The performance degradation percentage for the benchmarks running on two sites  with
 16 or 32  nodes is on average equal to 8.3\% or 4.7\% respectively. 
-For this scenario, the proposed scaling algorithm selects smaller frequencies for the executions with 32 nodes  without significantly degrading their performance because the communication times are higher with 32 nodes which results in smaller  computations to communications ratio.  On the other hand, the performance degradation percentage  for the benchmarks running  on one site  with
+For this scenario, the proposed scaling algorithm selects smaller frequencies for the executions with 32 nodes  without significantly degrading their performance because the communication times are high with 32 nodes which results in smaller  computations to communications ratio.  On the other hand, the performance degradation percentage  for the benchmarks running  on one site  with
 16 or 32  nodes is on average equal to 3.2\% and 10.6\% respectively. In contrary to the two sites scenario, when the number of computing nodes is increased in the one site scenario, the performance degradation percentage is increased. Therefore, doubling the number of computing 
 nodes when the communications occur in high speed network does not decrease the computations to 
 communication ratio.