]> AND Private Git Repository - ThesisAhmed.git/blob - CHAPITRE_03.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
adding the ch3
[ThesisAhmed.git] / CHAPITRE_03.tex
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 %%                          %%
3 %%       CHAPTER 03         %%
4 %%                          %%
5 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
6  \chapter{Energy Optimization of Heterogeneous Platforms}
7 \label{ch3}
8
9 \newcommand{\CL}{\Xsub{C}{L}}
10 \newcommand{\Dist}{\mathit{Dist}}
11 \newcommand{\EdNew}{\Xsub{E}{dNew}}
12 \newcommand{\Eind}{\Xsub{E}{ind}}
13 \newcommand{\Enorm}{\Xsub{E}{Norm}}
14 \newcommand{\Eoriginal}{\Xsub{E}{Original}}
15 \newcommand{\Ereduced}{\Xsub{E}{Reduced}}
16 \newcommand{\Es}{\Xsub{E}{S}}
17 \newcommand{\Fdiff}[1][]{\Xsub{F}{diff}_{\!#1}}
18 \newcommand{\Fmax}[1][]{\Xsub{F}{max}_{\fxheight{#1}}}
19 \newcommand{\Fnew}{\Xsub{F}{new}}
20 \newcommand{\Ileak}{\Xsub{I}{leak}}
21 \newcommand{\Kdesign}{\Xsub{K}{design}}
22 \newcommand{\MaxDist}{\mathit{Max}\Dist}
23 \newcommand{\MinTcm}{\mathit{Min}\Tcm}
24 \newcommand{\Ntrans}{\Xsub{N}{trans}}
25 \newcommand{\Pd}[1][]{\Xsub{P}{d}_{\fxheight{#1}}}
26 \newcommand{\PdNew}{\Xsub{P}{dNew}}
27 \newcommand{\PdOld}{\Xsub{P}{dOld}}
28 \newcommand{\Pnorm}{\Xsub{P}{Norm}}
29 \newcommand{\Ps}[1][]{\Xsub{P}{s}_{\fxheight{#1}}}
30 \newcommand{\Scp}[1][]{\Xsub{S}{cp}_{#1}}
31 \newcommand{\Sopt}[1][]{\Xsub{S}{opt}_{#1}}
32 \newcommand{\Tcm}[1][]{\Xsub{T}{cm}_{\fxheight{#1}}}
33 \newcommand{\Tcp}[1][]{\Xsub{T}{cp}_{#1}}
34 \newcommand{\TcpOld}[1][]{\Xsub{T}{cpOld}_{#1}}
35 \newcommand{\Tnew}{\Xsub{T}{New}}
36 \newcommand{\Told}{\Xsub{T}{Old}}
37 \newcommand{\Pmax}[1][]{\Xsub{P}{max}_{\fxheight{#1}}}
38 \newcommand{\Pidle}[1][]{\Xsub{P}{idle}_{\fxheight{#1}}}
39
40
41 \renewcommand{\algorithmicdo}{\textbf{do}}
42 \renewcommand{\algorithmicwhile}{\textbf{while}}
43 \renewcommand{\algorithmicrequire}{\textbf{Require:}}
44 \renewcommand{\algorithmicensure}{\textbf{Ensure:}}
45 \renewcommand{\algorithmicend}{\textbf{end}}
46 \renewcommand{\algorithmicif}{\textbf{if}}
47 \renewcommand{\algorithmicthen}{\textbf{then}}
48
49 \section{Introduction}
50 \label{ch3:intro}
51
52
53   Computing platforms are consuming more and more energy due to the increasing
54   number of nodes composing them.  In the heterogeneous computing platform composed 
55   of multiple computing   nodes, each node is different in the computing power from 
56   the others.  Accordingly, the fast nodes have to waits to the slow ones to finish 
57   their works. The resulting waiting times is called the idle times that are increased 
58   proportionally to the increase in the heterogeneity between the computing nodes. 
59   This leads to a big waste in the computing power and thus the energy consumed by the fast nodes.   
60   To minimize the operating costs of these  platforms many techniques have been used. 
61   Dynamic voltage and   frequency  scaling (DVFS) is one of them. It reduces the frequency 
62   of a CPU to lower its energy consumption.  However, lowering the frequency of a CPU may 
63   increase the execution time of an application running on that processor.  Therefore,
64   the frequency that gives the best trade-off between the energy consumption and
65   the performance of an application must be selected.
66
67   In this chapter, two new online frequency selecting algorithms for heterogeneous local
68   cluster (heterogeneous CPUs)  and grid platform are presented.  
69   They select the frequencies that tray to give the best
70   trade-off between energy saving and performance degradation, for each node
71   computing the synchronous message passing iterative application. These algorithms have a small
72   overhead and work without training or profiling. They use new energy models
73   for  message passing iterative synchronous applications running on both the heterogeneous
74   local cluster and grid platform. The first proposed algorithm for a heterogeneous local 
75   cluster is evaluated on the SimGrid simulator while running the NAS parallel
76   benchmarks class C. The experiments conducted  over 8 heterogeneous nodes show that it reduces on 
77   average the energy consumption by  29.8\%  while limiting the performance degradation by 3.8\%.  
78   The second proposed algorithm for a grid platform is evaluated on the Grid5000 testbed 
79   platform  while running the NAS parallel benchmarks class D.
80   Its experiments on 16 nodes, distributed on three clusters, show that it reduces  on average the
81   energy consumption by 30\% while  the performance  is on average only degraded
82    by 3.2\%.  
83   Finally, both the two algorithms are compared to an  existing methods, the comparison 
84   results show that they outperform the latter in term of energy and performance trade-off. 
85
86
87 This chapter is organized as follows: Section~\ref{ch3:relwork} presents some
88 related works from other authors.  Section~\ref{ch3:1} presents the performance and energy 
89 models of synchronous message passing programs running over a heterogeneous local cluster.
90 It also describes the proposed frequencies selecting algorithm then the precision of the proposed algorithm is verified. 
91 Section~\ref{ch3:2} presents the simulation results of applying the algorithm on the NAS parallel 
92 benchmarks class C and executing them on a heterogeneous local cluster. It shows the results of running
93 three different power scenarios and comparing them. Moreover, it also shows the
94 comparison results between the proposed method and an existing method.
95 Section~\ref{ch3:3} shows the energy and performance models in addition to the frequencies 
96 selecting algorithm of synchronous message passing programs running over a grid platform.
97 Section~\ref{ch3:4} presents the results of applying the algorithm on the 
98 NAS parallel benchmarks class D and executing them on the Grid'5000 testbed. 
99 It also evaluates the algorithm over multi-cores per node architectures and over three different power scenarios. Moreover, it shows the comparison results between the proposed method and an existing method.
100 Finally, in Section~\ref{ch3:concl}  the chapter ends with a summary.
101
102 \section{Related works}
103 \label{ch3:relwork}
104
105 DVFS is a technique used in modern processors to scale down both the voltage and
106 the frequency of the CPU while computing, in order to reduce the energy
107 consumption of the processor. DVFS is also allowed in GPUs to achieve the same
108 goal. Reducing the frequency of a processor lowers its number of FLOPS and may
109 degrade the performance of the application running on that processor, especially
110 if it is compute bound. Therefore selecting the appropriate frequency for a
111 processor to satisfy some objectives, while taking into account all the
112 constraints, is not a trivial operation.  Many researchers used different
113 strategies to tackle this problem. Some of them developed online methods that
114 compute the new frequency while executing the application, such
115 as~\cite{ref64,ref67}.
116 Others used offline methods that may need to run the application and profile
117 it before selecting the new frequency, such
118 as~\cite{ref58,ref91}.
119 The methods could be heuristics, exact or brute force methods that satisfy
120 varied objectives such as energy reduction or performance. They also could be
121 adapted to the execution's environment and the type of the application such as
122 sequential, parallel or distributed architecture, homogeneous or heterogeneous
123 platform, synchronous or asynchronous application, \dots{}
124
125 In this chapter, we are interested in reducing energy for message passing
126 iterative synchronous applications running over heterogeneous platforms.  Some
127 works have already been done for such platforms and they can be classified into
128 two types of heterogeneous platforms:
129 \begin{itemize}
130 \item the platform is composed of homogeneous GPUs and homogeneous CPUs.
131 \item the platform is only composed of heterogeneous CPUs.
132 \end{itemize}
133
134 For the first type of platform, the computing intensive parallel tasks are
135 executed on the GPUs and the rest are executed on the CPUs.  Luley et
136 al.~\cite{ref68}, proposed a
137 heterogeneous cluster composed of Intel Xeon CPUs and NVIDIA GPUs. Their main
138 goal was to maximize the energy efficiency of the platform during computation by
139 maximizing the number of FLOPS per watt generated.
140 In~\cite{ref69}, Kai Ma et al. developed a scheduling algorithm that distributes  
141 workloads proportional to
142 the computing power of the nodes which could be a GPU or a CPU. All the tasks
143 must be completed at the same time.  In~\cite{ref70},
144 Rong et al. showed that a heterogeneous (GPUs and CPUs) cluster that enables
145 DVFS gave better energy and performance efficiency than other clusters only
146 composed of CPUs.
147
148 The work presented in this chapter concerns the second type of platform, with
149 heterogeneous CPUs.  Many methods were conceived to reduce the energy
150 consumption of this type of platform.  Naveen et
151 al.~\cite{ref71} developed a method that
152 minimizes the value of $\mathit{energy}\times \mathit{delay}^2$ (the delay is
153 the sum of slack times that happen during synchronous communications) by
154 dynamically assigning new frequencies to the CPUs of the heterogeneous cluster.
155 Lizhe et al.~\cite{ref72} proposed an
156 algorithm that divides the executed tasks into two types: the critical and non
157 critical tasks. The algorithm scales down the frequency of non critical tasks
158 proportionally to their slack and communication times while limiting the
159 performance degradation percentage to less than 10\%.
160 In~\cite{ref73}, they developed a
161 heterogeneous cluster composed of two types of Intel and AMD processors. They
162 use a gradient method to predict the impact of DVFS operations on performance.
163 In~\cite{ref74} and
164 \cite{ref75}, the best
165 frequencies for a specified heterogeneous cluster are selected offline using
166 some heuristic.  Chen et
167 al.~\cite{ref76} used a greedy dynamic
168 programming approach to minimize the power consumption of heterogeneous servers
169 while respecting given time constraints.  This approach had considerable
170 overhead.  In contrast to the above described works, the work of this chapter presents the
171 following contributions:
172 \begin{enumerate}
173 \item two new energy and two performance models for message passing iterative
174   synchronous applications running over a heterogeneous local cluster and grid platform. 
175   All the models take into account communication and slack times. The models can predict the
176   required energy and the execution time of the application.
177
178 \item two new online frequencies selecting algorithms for heterogeneous
179   local cluster and grid platform. The algorithms have a very small overhead and do not need any
180   training or profiling. They use a new optimization function which
181   simultaneously maximizes the performance and minimizes the energy consumption
182   of a message passing iterative synchronous application.
183 \end{enumerate}
184
185 \section[The energy optimization of heterogeneous cluster]{The energy optimization of parallel iterative applications running over local heterogeneous 
186 cluster}
187 \label{ch3:1}
188
189 \subsection{The execution time of message passing distributed iterative
190   applications on a heterogeneous local cluster}
191 \label{ch3:1:1}
192 In this section, we are interested in reducing the energy consumption of message
193 passing distributed iterative synchronous applications running over
194 heterogeneous local cluster. A heterogeneous local cluster is defined as a collection of
195 heterogeneous computing nodes interconnected via a high speed homogeneous
196 network. Therefore, each node has different characteristics such as computing
197 power (FLOPS), energy consumption, CPU's frequency range, \dots{} but they all
198 have the same network bandwidth and latency.
199
200 \begin{figure}[h!]
201   \centering
202   \includegraphics[scale=0.8]{fig/ch3/commtasks}
203   \caption{Parallel tasks on a heterogeneous platform}
204   \label{fig:task-heter}
205 \end{figure}
206
207 The overall execution time of a distributed iterative synchronous application
208 over a heterogeneous local cluster consists of the sum of the computation time and
209 the communication time for every iteration on a node. However, due to the
210 heterogeneous computation power of the computing nodes, slack times may occur
211 when fast nodes have to wait, during synchronous communications, for the slower
212 nodes to finish their computations (see Figure~\ref{fig:task-heter}).  Therefore, the
213 overall execution time of the program is the execution time of the slowest task
214 which has the highest computation time and no slack time.
215
216 The frequency reduction process by applying DVFS operation can be expressed by the scaling
217 factor S which is the ratio between  the maximum and the new frequency of a CPU
218 as in (\ref{eq:s}).
219 The execution time of a compute bound sequential program is linearly
220 proportional to the frequency scaling factor $S$.  On the other hand, message
221 passing distributed applications consist of two parts: computation and
222 communication.  The execution time of the computation part is linearly
223 proportional to the frequency scaling factor $S$ but the communication time is
224 not affected by the scaling factor because the processors involved remain idle
225 during the communications~\cite{ref53}.  The
226 communication time for a task is the summation of periods of time that begin
227 with an MPI call for sending or receiving a message until the message is
228 synchronously sent or received.
229
230 Since in a heterogeneous cluster each node has different characteristics,
231 especially different frequency gears, when applying DVFS operations on these
232 nodes, they may get different scaling factors represented by a scaling vector:
233 $(S_1, S_2,\dots, S_N)$ where $S_i$ is the scaling factor of processor $i$. To
234 be able to predict the execution time of message passing synchronous iterative
235 applications running over a heterogeneous local cluster, for different vectors of
236 scaling factors, the communication time and the computation time for all the
237 tasks must be measured during the first iteration before applying any DVFS
238 operation. Then the execution time for one iteration of the application with any
239 vector of scaling factors can be predicted using (\ref{eq:perf_heter}).
240 \begin{equation}
241   \label{eq:perf_heter}
242   \Tnew = \max_{i=1,2,\dots,N} ({\TcpOld[i]} \cdot S_{i}) +  \min_{i=1,2,\dots,N} (\Tcm[i])
243 \end{equation}
244
245 where $\TcpOld[i]$ is the computation time of processor $i$ during the first
246 iteration.  The model computes the maximum computation time with
247 scaling factor from each node added to the communication time of the slowest
248 node. It means only the communication time without any slack time is taken into
249 account.  Therefore, the execution time of the iterative application is equal to
250 the execution time of one iteration as in (\ref{eq:perf_heter}) multiplied by the
251 number of iterations of that application.
252
253 This prediction model is developed from the model to predict the execution time
254 of message passing distributed applications for homogeneous
255 architectures presented in chapter \ref{ch2} section \ref{ch2:3}.  The execution time prediction model is
256 used in the method to optimize both the energy consumption and the performance
257 of iterative methods, which is presented in the following sections.
258
259 \subsection{Energy model for heterogeneous local cluster}
260 \label{ch3:1:2}
261 In the chapter \ref{ch2}, the dynamic and the static  energy consumption of the  individual 
262 processor is computed in \ref{eq:Edyn_new} and \ref{eq:Estatic_new} respectively. Then,
263 the total energy consumption of the individual processor is the sum of these two metrics.  
264 Therefore, the overall energy consumption for the parallel tasks over  parallel cluster 
265 is the  summation of the individual energies consumed for all processors. 
266
267 In the considered heterogeneous platform, each processor $i$ may have
268 different dynamic and static powers, noted as $\Pd[i]$ and $\Ps[i]$
269 respectively.  Therefore, even if the distributed message passing iterative
270 application is load balanced, the computation time of each CPU $i$ noted
271 $\Tcp[i]$ may be different and different frequency scaling factors may be
272 computed in order to decrease the overall energy consumption of the application
273 and reduce slack times.  The communication time of a processor $i$ is noted as
274 $\Tcm[i]$ and could contain slack times when communicating with slower nodes,
275 see Figure~\ref{fig:task-heter}.  Therefore, all nodes do not have equal
276 communication times. While the dynamic energy is computed according to the
277 frequency scaling factor and the dynamic power of each node as in
278 (\ref{eq:Edyn_new}), the static energy is computed as the sum of the execution time
279 of one iteration as in \ref{eq:perf_heter}  multiplied by the static power of each processor.  
280 The overall energy consumption of a message passing distributed application executed over a
281 heterogeneous cluster during one iteration is the summation of all dynamic and
282 static energies for each processor.  It is computed as follows:
283 \begin{equation}
284   \label{eq:energy-heter}
285  E = \sum_{i=1}^{N} {(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} + 
286  \sum_{i=1}^{N} (\Ps[i] \cdot (\max_{i=1,2,\dots,N} (\Tcp[i] \cdot S_{i}) +
287   { \min_{i=1,2,\dots,N} (\Tcm[i]) ))}
288 \end{equation}
289
290 Reducing the frequencies of the processors according to the vector of scaling
291 factors $(S_1, S_2,\dots, S_N)$ may degrade the performance of the application
292 and thus, increase the static energy because the execution time is
293 increased~\cite{ref78}. The overall energy consumption
294 for the iterative application can be measured by measuring the energy
295 consumption for one iteration as in (\ref{eq:energy-heter}) multiplied by the number
296 of iterations of that application.
297
298 \subsection{Optimization of both energy consumption and performance}
299 \label{ch3:1:3}
300 Using the lowest frequency for each processor does not necessarily give the most
301 energy efficient execution of an application. Indeed, even though the dynamic
302 power is reduced while scaling down the frequency of a processor, its
303 computation power is proportionally decreased. Hence, the execution time might
304 be drastically increased and during that time, dynamic and static powers are
305 being consumed.  Therefore, it might cancel any gains achieved by scaling down
306 the frequency of all nodes to the minimum and the overall energy consumption of
307 the application might not be the optimal one.  It is not trivial to select the
308 appropriate frequency scaling factor for each processor while considering the
309 characteristics of each processor (computation power, range of frequencies,
310 dynamic and static powers) and the task executed (computation/communication
311 ratio). The aim being to reduce the overall energy consumption and to avoid
312 increasing significantly the execution time.  In last chapter
313 ~\ref{ch2}, we proposed a method that selects the optimal
314 frequency scaling factor for a homogeneous cluster executing a message passing
315 iterative synchronous application while giving the best trade-off between the
316 energy consumption and the performance for such applications.  In this section, we
317 are interested in heterogeneous clusters as described above.  Due to the
318 heterogeneity of the processors, a vector of scaling factors should be selected
319 and it must give the best trade-off between energy consumption and performance.
320
321 As described before, the  relation between the energy consumption and the execution time for an
322 application is complex and nonlinear. Thus, to find the trade-off relation between the energy consumption in \ref{eq:energy-heter} and the performance in \ref{eq:perf_heter}  of the iterative message passing applications, first we need to normalized both of them as follows:
323
324
325 \begin{equation}
326   \label{eq:enorm-heter}
327   \Enorm = \frac{\Ereduced}{\Eoriginal} 
328     = \frac{ \sum_{i=1}^{N}{(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} +
329  \sum_{i=1}^{N} {(\Ps[i] \cdot \Tnew)}}{\sum_{i=1}^{N}{( \Pd[i] \cdot  \Tcp[i])} +
330  \sum_{i=1}^{N} {(\Ps[i] \cdot \Told)}}
331 \end{equation}
332
333
334
335 \begin{equation}
336   \label{eq:pnorm-heter}
337   \Pnorm = \frac{\Told}{\Tnew}
338           = \frac{\max_{i=1,2,\dots,N}{(\Tcp[i]+\Tcm[i])}}
339             { \max_{i=1,2,\dots,N} (\Tcp[i] \cdot S_{i}) + \min_{i=1,2,\dots,N} (\Tcm[i])}
340 \end{equation}
341
342 Therefore, the vector of frequency scaling factors $S_1,S_2,\dots,S_N$ of the heterogeneous 
343 cluster reduce both the energy and the execution time simultaneously.  
344
345 \begin{figure}[!t]
346   \centering
347     \includegraphics[width=.7\textwidth]{fig/ch3/heter}
348   \caption{The energy and performance relation in Heterogeneous cluster}
349   \label{fig:rel-heter}
350 \end{figure}
351
352 Then, the objective function can be modeled in order to find the maximum
353 distance between the energy curve (\ref{eq:enorm-heter}) and the performance curve
354 (\ref{eq:pnorm-heter}) over all available sets of scaling factors of the heterogeneous 
355 computing cluster.  This represents the minimum energy consumption with minimum execution time (maximum
356 performance) at the same time, see Figure~\ref{fig:rel-heter}. Then the objective function has the following form:
357 \begin{equation}
358   \label{eq:max-heter}
359   \MaxDist =
360   \mathop{\max_{i=1,\dots F}}_{j=1,\dots,N}
361       (\overbrace{\Pnorm(S_{ij})}^{\text{Maximize}} -
362        \overbrace{\Enorm(S_{ij})}^{\text{Minimize}} )
363 \end{equation}
364 where $N$ is the number of nodes and $F$ is the number of available frequencies
365 for each node.  Then, the optimal set of scaling factors that satisfies
366 (\ref{eq:max-heter}) can be selected. 
367
368 \subsection[The scaling algorithm for heterogeneous cluster]{The scaling factors selection algorithm for heterogeneous cluster }
369 \label{ch3:1:4}
370
371
372 \begin{algorithm}[h!]
373   \begin{algorithmic}[1]
374     % \footnotesize
375     \Require ~
376     %\begin{description}
377     \item[{$\Tcp[i]$}] array of all computation times for all nodes during one iteration and with highest frequency.
378     \item[{$\Tcm[i]$}] array of all communication times for all nodes during one iteration and with highest frequency.
379     \item[{$\Fmax[i]$}] array of the maximum frequencies for all nodes.
380     \item[{$\Pd[i]$}] array of the dynamic powers for all nodes.
381     \item[{$\Ps[i]$}] array of the static powers for all nodes.
382     \item[{$\Fdiff[i]$}] array of the differences between two successive frequencies for all nodes.
383     %\end{description}
384     \Ensure $\Sopt[1],\Sopt[2] \dots, \Sopt[N]$ is a vector of optimal scaling factors
385
386     \State $\Scp[i] \gets \frac{\max_{i=1,2,\dots,N}(\Tcp[i])}{\Tcp[i]} $
387     \State $F_{i} \gets  \frac{\Fmax[i]}{\Scp[i]},~{i=1,2,\cdots,N}$
388     \State Round the computed initial frequencies $F_i$ to the closest one available in each node.
389     \If{(not the first frequency)}
390           \State $F_i \gets F_i+\Fdiff[i],~i=1,\dots,N.$
391     \EndIf
392     \State $\Told \gets \max_{i=1,\dots,N} (\Tcp[i]+\Tcm[i])$
393     % \State $\Eoriginal \gets \sum_{i=1}^{N}{( \Pd[i] \cdot  \Tcp[i])} +\sum_{i=1}^{N} {(\Ps[i] \cdot \Told)}$
394     \State $\Eoriginal \gets \sum_{i=1}^{N}{( \Pd[i] \cdot  \Tcp[i] + \Ps[i] \cdot \Told)}$
395     \State $\Sopt[i] \gets 1,~i=1,\dots,N. $
396     \State $\Dist \gets 0 $
397     \While {(all nodes not reach their  minimum  frequency)}
398         \If{(not the last freq. \textbf{and} not the slowest node)}
399         \State $F_i \gets F_i - \Fdiff[i],~i=1,\dots,N.$
400         \State $S_i \gets \frac{\Fmax[i]}{F_i},~i=1,\dots,N.$
401         \EndIf
402        \State $\Tnew \gets  \max_{i=1,2,\dots,N} ({\TcpOld[i]} \cdot S_{i}) +  \min_{i=1,2,\dots,N} (\Tcm[i])$
403 %       \State $\Ereduced \gets \sum_{i=1}^{N}{(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} + \sum_{i=1}^{N} {(\Ps[i] \cdot \rlap{\Tnew)}} $
404        \State $\Ereduced \gets \sum_{i=1}^{N} {(S_i^{-2} \cdot \Pd[i] \cdot  \Tcp[i])} + 
405  \sum_{i=1}^{N} (\Ps[i] \cdot (\max_{i=1,2,\dots,N} (\Tcp[i] \cdot S_{i}) +
406   { \min_{i=1,2,\dots,N} (\Tcm[i]) ))} $
407        \State $\Pnorm \gets \frac{\Told}{\Tnew}$
408        \State $\Enorm\gets \frac{\Ereduced}{\Eoriginal}$
409       \If{$(\Pnorm - \Enorm > \Dist)$}
410         \State $\Sopt[i] \gets S_{i},~i=1,\dots,N. $
411         \State $\Dist \gets \Pnorm - \Enorm$
412       \EndIf
413     \EndWhile
414     \State  Return $\Sopt[1],\Sopt[2],\dots,\Sopt[N]$
415   \end{algorithmic}
416   \caption{Scaling factors selection algorithm for heterogeneous cluster}
417   \label{HSA}
418 \end{algorithm}
419
420
421
422 \begin{algorithm}[h!]
423   \begin{algorithmic}[1]
424     % \footnotesize
425     \For {$k=1$ to \textit{some iterations}}
426       \State Computations section.
427       \State Communications section.
428       \If {$(k=1)$}
429         \State Gather all times of computation and communication from each node.
430         \State Call Algorithm \ref{HSA}.
431         \State Compute the new frequencies from the returned optimal scaling factors.
432         \State Set the new frequencies to nodes.
433       \EndIf
434     \EndFor
435   \end{algorithmic}
436   \caption{DVFS algorithm of heterogeneous platform}
437   \label{dvfs-heter}
438 \end{algorithm}
439
440
441
442 In this section, Algorithm~\ref{HSA} is presented. It selects the frequency
443 scaling factors vector that gives the best trade-off between minimizing the
444 energy consumption and maximizing the performance of a message passing
445 synchronous iterative application executed on a heterogeneous local cluster. It works
446 online during the execution time of the iterative message passing program.  It
447 uses information gathered during the first iteration such as the computation
448 time and the communication time in one iteration for each node. The algorithm is
449 executed after the first iteration and returns a vector of optimal frequency
450 scaling factors that satisfies the objective function (\ref{eq:max-heter}). The
451 program applies DVFS operations to change the frequencies of the CPUs according
452 to the computed scaling factors.  This algorithm is called just once during the
453 execution of the program. Algorithm~\ref{dvfs-heter} shows where and when the proposed
454 scaling algorithm is called in the iterative MPI program.
455
456 \begin{figure}[!t]
457   \centering
458   \includegraphics[scale=0.75]{fig/ch3/start_freq}
459   \caption{Selecting the initial frequencies in heterogeneous cluster}
460   \label{fig:st_freq-cluster}
461 \end{figure}
462
463 The nodes in a heterogeneous cluster have different computing powers, thus
464 while executing message passing iterative synchronous applications, fast nodes
465 have to wait for the slower ones to finish their computations before being able
466 to synchronously communicate with them as in Figure~\ref{fig:task-heter}.  These
467 periods are called idle or slack times.  The algorithm takes into account this
468 problem and tries to reduce these slack times when selecting the frequency
469 scaling factors vector. At first, it selects initial frequency scaling factors
470 that increase the execution times of fast nodes and minimize the differences
471 between the computation times of fast and slow nodes. The value of the initial
472 frequency scaling factor for each node is inversely proportional to its
473 computation time that was gathered from the first iteration. These initial
474 frequency scaling factors are computed as a ratio between the computation time
475 of the slowest node and the computation time of the node $i$ as follows:
476 \begin{equation}
477   \label{eq:Scp}
478   \Scp[i] = \frac{\max_{i=1,2,\dots,N}(\Tcp[i])}{\Tcp[i]}
479 \end{equation}
480 Using the initial frequency scaling factors computed in (\ref{eq:Scp}), the
481 algorithm computes the initial frequencies for all nodes as a ratio between the
482 maximum frequency of node $i$ and the computation scaling factor $\Scp[i]$ as
483 follows:
484 \begin{equation}
485   \label{eq:Fint}
486   F_{i} = \frac{\Fmax[i]}{\Scp[i]},~{i=1,2,\dots,N}
487 \end{equation}
488 If the computed initial frequency for a node is not available in the gears of
489 that node, it is replaced by the nearest available frequency.  In
490 Figure~\ref{fig:st_freq-cluster}, the nodes are sorted by their computing power in
491 ascending order and the frequencies of the faster nodes are scaled down
492 according to the computed initial frequency scaling factors.  The resulting new
493 frequencies are highlighted in Figure~\ref{fig:st_freq-cluster}.  This set of
494 frequencies can be considered as a higher bound for the search space of the
495 optimal vector of frequencies because selecting scaling factors higher
496 than the higher bound will not improve the performance of the application and it
497 will increase its overall energy consumption.  Therefore the algorithm that
498 selects the frequency scaling factors starts the search method from these
499 initial frequencies and takes a downward search direction toward lower
500 frequencies. The algorithm iterates on all remaining frequencies, from the higher
501 bound until all nodes reach their minimum frequencies, to compute their overall
502 energy consumption and performance, and select the optimal frequency scaling
503 factors vector. At each iteration the algorithm determines the slowest node
504 according to the equation (\ref{eq:perf_heter}) and keeps its frequency unchanged,
505 while it lowers the frequency of all other nodes by one gear.  The new overall
506 energy consumption and execution time are computed according to the new scaling
507 factors.  The optimal set of frequency scaling factors is the set that gives the
508 highest distance according to the objective function (\ref{eq:max-heter}).
509
510 Figure~\ref{fig:rel-heter} illustrate the normalized performance and
511 consumed energy for an application running on a
512 heterogeneous cluster  while increasing the scaling factors. It can
513 be noticed that in a homogeneous cluster, as in the figure \ref{fig:rel} (a), 
514 the search for the optimal scaling
515 factor should start from the maximum frequency because the performance and the
516 consumed energy decrease from the beginning of the plot. On the other hand, in
517 the heterogeneous cluster the performance is maintained at the beginning of the
518 plot even if the frequencies of the faster nodes decrease until the computing
519 power of scaled down nodes are lower than the slowest node. In other words,
520 until they reach the higher bound. It can also be noticed that the higher the
521 difference between the faster nodes and the slower nodes is, the bigger the
522 maximum distance between the energy curve and the performance curve is while the
523 scaling factors are varying which results in bigger energy savings. 
524 Finally, in a homogeneous platform the energy consumption is increased when the scaling factor is very high. 
525 Indeed, the dynamic energy  saved  by reducing the frequency of the processor is compensated by the significant increase of the execution time and thus the increased of the static energy. On the other hand, in a heterogeneous platform this is not the case.
526
527 \subsection{The evaluation of the proposed algorithm}
528 \label{ch3:1:5}
529 The precision of the proposed algorithm mainly depends on the execution time
530 prediction model defined in (\ref{eq:perf_heter}) and the energy model computed by
531 (\ref{eq:energy-heter}).  The energy model is also significantly dependent on the
532 execution time model because the static energy is linearly related to the
533 execution time and the dynamic energy is related to the computation time. So,
534 all the works presented in this chapter are based on the execution time model. To
535 verify this model, the predicted execution time was compared to the real
536 execution time over SimGrid/SMPI simulator,
537 v3.10~\cite{ref66}, for all the NAS
538 parallel benchmarks NPB v3.3 \cite{ref65}, running class B on
539 8 or 9 nodes. The comparison showed that the proposed execution time model is
540 very precise, the maximum normalized difference between the predicted execution
541 time and the real execution time is equal to 0.03 for all the NAS benchmarks.
542
543 Since the proposed algorithm is not an exact method, it does not test all the
544 possible solutions (vectors of scaling factors) in the search space. To prove
545 its efficiency, it was compared on small instances to a brute force search
546 algorithm that tests all the possible solutions. The brute force algorithm was
547 applied to different NAS benchmarks classes with different number of nodes. The
548 solutions returned by the brute force algorithm and the proposed algorithm were
549 identical and the proposed algorithm was on average 10 times faster than the
550 brute force algorithm. It has a small execution time: for a heterogeneous
551 cluster composed of four different types of nodes having the characteristics
552 presented in Table~\ref{table:platform-cluster}, it takes on average  0.04 \textit{ms} for 4
553 nodes and 0.15 \textit{ms} on average for 144 nodes to compute the best scaling
554 factors vector.  The algorithm complexity is $O(F\cdot N)$, where $F$ is the
555 maximum number of available frequencies, and $N$ is the number of computing
556 nodes. The algorithm needs from 12 to 20 iterations to select the best vector of
557 frequency scaling factors that gives the results of the next sections.
558
559 \begin{table}[h!]
560   \caption{Heterogeneous nodes characteristics}
561   % title of Table
562   \centering
563   \begin{tabular}{|*{7}{r|}}
564     \hline
565     Node   & Simulated & Max   & Min   & Diff. & Dynamic    & Static    \\
566     type   & GFLOPS    & Freq. & Freq. & Freq. & power      & power     \\
567            &           & GHz   & GHz   & GHz   &            &           \\
568     \hline
569     1      & 40        & 2.50  & 1.20  & 0.100 & 20 W & 4 W \\
570     \hline
571     2      & 50        & 2.66  & 1.60  & 0.133 & 25 W & 5 W \\
572     \hline
573     3      & 60        & 2.90  & 1.20  & 0.100 & 30 W & 6 W \\
574     \hline
575     4      & 70        & 3.40  & 1.60  & 0.133 & 35 W & 7 W \\
576     \hline
577   \end{tabular}
578   \label{table:platform-cluster}
579 \end{table}
580
581 \section{Experimental results over heterogeneous  local cluster}
582 \label{ch3:2}
583 To evaluate the efficiency and the overall energy consumption reduction of
584 Algorithm~\ref{HSA}, it was applied to the NAS parallel benchmarks NPB v3.3 which 
585 is composed of synchronous message passing applications. The 
586 experiments were executed on the simulator SimGrid/SMPI which offers easy tools
587 to create a heterogeneous local cluster and run message passing applications over it.
588 The heterogeneous cluster that was used in the experiments, had one core per
589 node because just one process was executed per node.  The heterogeneous cluster
590 was composed of four types of nodes. Each type of nodes had different
591 characteristics such as the maximum CPU frequency, the number of available
592 frequencies and the computational power, see Table~\ref{table:platform-cluster}. The
593 characteristics of these different types of nodes are inspired from the
594 specifications of real Intel processors.  The heterogeneous cluster had up to
595 144 nodes and had nodes from the four types in equal proportions, for example if
596 a benchmark was executed on 8 nodes, 2 nodes from each type were used. Since the
597 constructors of CPUs do not specify the dynamic and the static power of their
598 CPUs, for each type of node they were chosen proportionally to its computing
599 power (FLOPS).  In the initial heterogeneous cluster, while computing with
600 highest frequency, each node consumed an amount of power proportional to its
601 computing power (which corresponds to 80\% of its dynamic power and the
602 remaining 20\% to the static power), the same assumption was made in chapter \ref{ch2} and
603 \cite{ref3}.  Finally, These
604 nodes were connected via an Ethernet network with 1 \textit{Gbit/s} bandwidth.
605
606
607 \subsection{The experimental results of the scaling algorithm }
608 \label{ch3:2:1}
609
610 The proposed algorithm was applied to the seven parallel NAS benchmarks (EP, CG,
611 MG, FT, BT, LU and SP). The benchmarks were executed with class C while being 
612 run on different number of nodes, ranging from 8 to 128 or 144 nodes depending 
613 on the benchmark being executed. 
614 Indeed, the benchmarks CG, MG, LU, EP and FT had to be executed on 1,
615 2, 4, 8, 16, 32, 64, or 128 nodes.  The other benchmarks such as BT and SP had
616 to be executed on 1, 4, 9, 16, 36, 64, or 144 nodes.
617
618
619   
620  \begin{table}[h!]
621   \caption{Running NAS benchmarks on 8 and 9 nodes }
622   % title of Table
623   \centering
624   \begin{tabular}{|*{7}{r|}}
625     \hline
626     \hspace{-2.2084pt}%
627     Program & Execution & Energy        & Energy   & Performance   & Distance \\
628     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
629     \hline
630     CG      &  36.11    &  3263.49      & 31.25    & 7.12          & 24.13    \\
631     \hline
632     MG      &   8.99    &   953.39      & 33.78    & 6.41          & 27.37    \\
633     \hline
634     EP      &  40.39    &  5652.81      & 27.04    & 0.49          & 26.55    \\
635     \hline
636     LU      & 218.79    & 36149.77      & 28.23    & 0.01          & 28.22    \\
637     \hline
638     BT      & 166.89    & 23207.42      & 32.32    & 7.89          & 24.43    \\
639     \hline
640     SP      & 104.73    & 18414.62      & 24.73    & 2.78          & 21.95    \\
641     \hline
642     FT      &  51.10    &  4913.26      & 31.02    & 2.54          & 28.48    \\
643     \hline
644   \end{tabular}
645   \label{table:res_8n}
646  \end{table}
647
648   \medskip
649  \begin{table}[h!]
650   \caption{Running NAS benchmarks on 16 nodes }
651   % title of Table
652   \centering
653   \begin{tabular}{|*{7}{r|}}
654     \hline
655     \hspace{-2.2084pt}%
656     Program & Execution & Energy        & Energy   & Performance   & Distance \\
657     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
658     \hline
659     CG      &  31.74    &  4373.90      & 26.29    & 9.57          & 16.72    \\
660     \hline
661     MG      &   5.71    &  1076.19      & 32.49    & 6.05          & 26.44    \\
662     \hline
663     EP      &  20.11    &  5638.49      & 26.85    & 0.56          & 26.29    \\
664     \hline
665     LU      & 144.13    & 42529.06      & 28.80    & 6.56          & 22.24    \\
666     \hline
667     BT      &  97.29    & 22813.86      & 34.95    & 5.80          & 29.15    \\
668     \hline
669     SP      &  66.49    & 20821.67      & 22.49    & 3.82          & 18.67    \\
670     \hline
671     FT      &  37.01    &  5505.60      & 31.59    & 6.48          & 25.11    \\
672     \hline
673   \end{tabular}
674   \label{table:res_16n}
675  \end{table}
676
677   \medskip
678  \begin{table}[h!]
679   \caption{Running NAS benchmarks on 32 and 36 nodes }
680   % title of Table
681   \centering
682   \begin{tabular}{|*{7}{r|}}
683     \hline
684     \hspace{-2.2084pt}%
685     Program & Execution & Energy        & Energy   & Performance   & Distance \\
686     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
687     \hline
688     CG      & 32.35     &  6704.21      & 16.15    & 5.30          & 10.85    \\
689     \hline
690     MG      &  4.30     &  1355.58      & 28.93    & 8.85          & 20.08    \\
691     \hline
692     EP      &  9.96     &  5519.68      & 26.98    & 0.02          & 26.96    \\
693     \hline
694     LU      & 99.93     & 67463.43      & 23.60    & 2.45          & 21.15    \\
695     \hline
696     BT      & 48.61     & 23796.97      & 34.62    & 5.83          & 28.79    \\
697     \hline
698     SP      & 46.01     & 27007.43      & 22.72    & 3.45          & 19.27    \\
699     \hline
700     FT      & 28.06     &  7142.69      & 23.09    & 2.90          & 20.19    \\
701     \hline
702   \end{tabular}
703   \label{table:res_32n}
704  \end{table}
705
706   \medskip
707  \begin{table}[h!]
708   \caption{Running NAS benchmarks on 64 nodes }
709   % title of Table
710   \centering
711   \begin{tabular}{|*{7}{r|}}
712     \hline
713     \hspace{-2.2084pt}%
714     Program & Execution & Energy        & Energy   & Performance   & Distance \\
715     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
716     \hline
717     CG      & 46.65     &  17521.83     &  8.13    &  1.68         &  6.45    \\
718     \hline
719     MG      &  3.27     &   1534.70     & 29.27    & 14.35         & 14.92    \\
720     \hline
721     EP      &  5.05     &   5471.11     & 27.12    &  3.11         & 24.01    \\
722     \hline
723     LU      & 73.92     & 101339.16     & 21.96    &  3.67         & 18.29    \\
724     \hline
725     BT      & 39.99     &  27166.71     & 32.02    & 12.28         & 19.74    \\
726     \hline
727     SP      & 52.00     &  49099.28     & 24.84    &  0.03         & 24.81    \\
728     \hline
729     FT      & 25.97     &  10416.82     & 20.15    &  4.87         & 15.28    \\
730     \hline
731   \end{tabular}
732   \label{table:res_64n}
733  \end{table}
734
735   \medskip \begin{table}[h!]
736   \caption{Running NAS benchmarks on 128 and 144 nodes }
737   % title of Table
738   \centering
739   \begin{tabular}{|*{7}{r|}}
740     \hline
741     \hspace{-2.2084pt}%
742     Program & Execution & Energy        & Energy   & Performance   & Distance \\
743     name    & time/s    & consumption/J & saving\% & degradation\% &          \\
744     \hline
745     CG      & 56.92     &  41163.36     &  4.00    &  1.10         &  2.90    \\
746     \hline
747     MG      &  3.55     &   2843.33     & 18.77    & 10.38         &  8.39    \\
748     \hline
749     EP      &  2.67     &   5669.66     & 27.09    &  0.03         & 27.06    \\
750     \hline
751     LU      & 51.23     & 144471.90     & 16.67    &  2.36         & 14.31    \\
752     \hline
753     BT      & 37.96     &  44243.82     & 23.18    &  1.28         & 21.90    \\
754     \hline
755     SP      & 64.53     & 115409.71     & 26.72    &  0.05         & 26.67    \\
756     \hline
757     FT      & 25.51     &  18808.72     & 12.85    &  2.84         & 10.01    \\
758     \hline
759   \end{tabular}
760   \label{table:res_128n}
761 \end{table}
762
763 \begin{figure}[h!]
764   \centering
765   \centering
766     \includegraphics[width=.7\textwidth]{fig/ch3/energy}\\~ ~ ~ ~ ~(a) \\ 
767     
768     \includegraphics[width=.7\textwidth]{fig/ch3/per_deg}\\~ ~ ~ ~ ~(b) 
769   \caption{NAS benchmarks running with a different number of nodes  (a) the  energy saving and 
770       (b) the performance degradation }
771       \label{fig:res}
772 \end{figure}
773
774 The overall energy consumption was computed for each instance according to the
775 energy consumption model (\ref{eq:energy-heter}), with and without applying the
776 algorithm. The execution time was also measured for all these experiments. Then,
777 the energy saving and performance degradation percentages were computed for each
778 instance.  The results are presented in Tables 
779 \ref{table:res_8n}, \ref{table:res_16n}, \ref{table:res_32n},
780 \ref{table:res_64n} and \ref{table:res_128n}. All these results are the average
781 values from many experiments for energy savings and performance degradation.
782 The tables show the experimental results for running the NAS parallel benchmarks
783 on different numbers of nodes.  The experiments show that the algorithm
784 significantly reduces the energy consumption (up to 34\%) and tries to
785 limit the performance degradation.  They also show that the energy saving
786 percentage decreases when the number of computing nodes increases.  This
787 reduction is due to the increase of the communication times compared to the
788 execution times when the benchmarks are run over a higher number of nodes.
789 Indeed, the benchmarks with the same class, C, are executed on different numbers
790 of nodes, so the computation required for each iteration is divided by the
791 number of computing nodes.  On the other hand, more communications are required
792 when increasing the number of nodes so the static energy increases linearly
793 according to the communication time and the dynamic power is less relevant in
794 the overall energy consumption.  Therefore, reducing the frequency with
795 Algorithm~\ref{HSA} is less effective in reducing the overall energy savings. It
796 can also be noticed that for the benchmarks EP and SP that contain little or no
797 communications, the energy savings are not significantly affected by the high
798 number of nodes.  No experiments were conducted using bigger classes than D,
799 because they require a lot of memory (more than 64 \textit{CB}) when being executed
800 by the simulator on one machine.  The maximum distance between the normalized
801 energy curve and the normalized performance for each instance is also shown in
802 the result tables. It decrease in the same way as the energy saving percentage.
803 The tables also show that the performance degradation percentage is not
804 significantly increased when the number of computing nodes is increased because
805 the computation times are small when compared to the communication times.
806
807 Figure~\ref{fig:res} (a) and (b) present the energy saving and
808 performance degradation respectively for all the benchmarks according to the
809 number of used nodes. As shown in the first plot, the energy saving percentages
810 of the benchmarks MG, LU, BT and FT decrease linearly when the number of nodes
811 increase. While for the EP and SP benchmarks, the energy saving percentage is
812 not affected by the increase of the number of computing nodes, because in these
813 benchmarks there are little or no communications. Finally, the energy saving of
814 the CG benchmark significantly decreases when the number of nodes increase
815 because this benchmark has more communications than the others. The second plot
816 shows that the performance degradation percentages of most of the benchmarks
817 decrease when they run on a big number of nodes because they spend more time
818 communicating than computing, thus, scaling down the frequencies of some nodes
819 has less effect on the performance.
820
821 \subsection{The results for different power consumption scenarios}
822 \label{ch3:2:2}
823
824 The results of the previous section were obtained while using processors that
825 consume during computation an overall power which is 80\% composed of
826 dynamic power and of 20\% of static power. In this section, these ratios
827 are changed and two new power scenarios are considered in order to evaluate how
828 the proposed algorithm adapts itself according to the static and dynamic power
829 values.  The two new power scenarios are the following:
830
831 \begin{itemize}
832 \item 70\% of dynamic power and 30\% of static power
833 \item 90\% of dynamic power and 10\% of static power
834 \end{itemize}
835
836 The NAS parallel benchmarks were executed again over processors that follow the
837 new power scenarios.  The class C of each benchmark was run over 8 or 9 nodes
838 and the results are presented in Tables~\ref{table:res_s1} and
839 \ref{table:res_s2}. These tables show that the energy saving percentage of the
840 70\%-30\% scenario is smaller for all benchmarks compared to the
841 energy saving of the 90\%-10\% scenario.  Indeed, in the latter
842 more dynamic power is consumed when nodes are running on their maximum
843 frequencies, thus, scaling down the frequency of the nodes results in higher
844 energy savings than in the 70\%-30\% scenario. On the other hand,
845 the performance degradation percentage is smaller in the 70\%-30\%
846 scenario compared to the 90\%-\%10 scenario. This is due to the
847 higher static power percentage in the first scenario which makes it more
848 relevant in the overall consumed energy.  Indeed, the static energy is related
849 to the execution time and if the performance is degraded the amount of consumed
850 static energy directly increases.  Therefore, the proposed algorithm does not
851 really significantly scale down much the frequencies of the nodes in order to
852 limit the increase of the execution time and thus limiting the effect of the
853 consumed static energy.
854
855 Both new power scenarios are compared to the old one in
856 Figure~\ref{fig:powers-heter} (a). It shows the average of the performance degradation,
857 the energy saving and the distances for all NAS benchmarks of class C running on
858 8 or 9 nodes.  The comparison shows that the energy saving ratio is proportional
859 to the dynamic power ratio: it is increased when applying the
860 90\%-10\% scenario because at maximum frequency the dynamic energy
861 is the most relevant in the overall consumed energy and can be reduced by
862 lowering the frequency of some processors. On the other hand, the energy saving
863 decreases when the 70\%-30\% scenario is used because the dynamic
864 energy is less relevant in the overall consumed energy and lowering the
865 frequency does not return big energy savings.  Moreover, the average of the
866 performance degradation is decreased when using a higher ratio for static power
867 (e.g.  70\%-30\% scenario and 80\%-20\% scenario). Since the proposed 
868 algorithm optimizes the energy consumption when
869 using a higher ratio for dynamic power the algorithm selects bigger frequency
870 scaling factors that result in more energy saving but less performance, for
871 example see Figure~\ref{fig:powers-heter} (b). The opposite happens when using a
872 higher ratio for static power, the algorithm proportionally selects smaller
873 scaling values which result in less energy saving but also less performance
874 degradation.
875
876 \begin{table}[!t]
877   \caption{The results of the 70\%-30\% power scenario}
878   % title of Table
879   \centering
880   \begin{tabular}{|*{6}{r|}}
881     \hline
882     Program & Energy        & Energy   & Performance   & Distance \\
883     name    & consumption/J & saving\% & degradation\% &          \\
884     \hline
885     CG      &  4144.21      & 22.42    & 7.72          & 14.70    \\
886     \hline
887     MG      &  1133.23      & 24.50    & 5.34          & 19.16    \\
888    \hline
889     EP      &  6170.30      & 16.19    & 0.02          & 16.17    \\
890    \hline
891     LU      & 39477.28      & 20.43    & 0.07          & 20.36    \\
892     \hline
893     BT      & 26169.55      & 25.34    & 6.62          & 18.71    \\
894    \hline
895     SP      & 19620.09      & 19.32    & 3.66          & 15.66    \\
896    \hline
897     FT      &  6094.07      & 23.17    & 0.36          & 22.81    \\
898     \hline
899   \end{tabular}
900   \label{table:res_s1}
901 \end{table}
902
903 \begin{table}[!t]
904   \caption{The results of the 90\%-10\% power scenario}
905   % title of Table
906   \centering
907   \begin{tabular}{|*{6}{r|}}
908     \hline
909     Program & Energy          & Energy      & Performance   & Distance \\
910     name    & consumption/J   & saving\%    & degradation\% &          \\
911     \hline
912     CG      &  2812.38        & 36.36       &  6.80         & 29.56    \\
913     \hline
914     MG      &   825.43        & 38.35       &  6.41         & 31.94    \\
915     \hline
916     EP      &  5281.62        & 35.02       &  2.68         & 32.34    \\
917     \hline
918     LU      & 31611.28        & 39.15       &  3.51         & 35.64    \\
919     \hline
920     BT      & 21296.46        & 36.70       &  6.60         & 30.10    \\
921     \hline
922     SP      & 15183.42        & 35.19       & 11.76         & 23.43    \\
923     \hline
924     FT      &  3856.54        & 40.80       &  5.67         & 35.13    \\
925     \hline
926   \end{tabular}
927   \label{table:res_s2}
928 \end{table}
929
930 \begin{table}[!t]
931   \caption{Comparing the proposed algorithm}
932   \centering
933   \begin{tabular}{|*{7}{r|}}
934     \hline
935     Program & \multicolumn{2}{c|}{Energy saving \%}
936             & \multicolumn{2}{c|}{Perf.  degradation \%}
937             & \multicolumn{2}{c|}{Distance} \\
938     \cline{2-7}
939     name    & EDP   & MaxDist & EDP  & MaxDist & EDP   & MaxDist \\
940     \hline
941     CG      & 27.58 & 31.25   & 5.82 & 7.12    & 21.76 & 24.13   \\
942     \hline
943     MG      & 29.49 & 33.78   & 3.74 & 6.41    & 25.75 & 27.37   \\
944     \hline
945     LU      & 19.55 & 28.33   & 0.00 & 0.01    & 19.55 & 28.22   \\
946     \hline
947     EP      & 28.40 & 27.04   & 4.29 & 0.49    & 24.11 & 26.55   \\
948     \hline
949     BT      & 27.68 & 32.32   & 6.45 & 7.87    & 21.23 & 24.43   \\
950     \hline
951     SP      & 20.52 & 24.73   & 5.21 & 2.78    & 15.31 & 21.95   \\
952     \hline
953     FT      & 27.03 & 31.02   & 2.75 & 2.54    & 24.28 & 28.48   \\
954     \hline
955   \end{tabular}
956   \label{table:compare_EDP}
957 \end{table}
958
959 \begin{figure}[h!]
960   \centering
961  
962     \includegraphics[width=.75\textwidth]{fig/ch3/sen_comp}\\~ ~ ~ ~ ~ (a)\\
963
964     \includegraphics[width=.75\textwidth]{fig/ch3/three_scenarios}\\~ ~ ~ ~ ~ (b)
965  
966   \caption{(a) Comparison the results of the three power scenarios and
967     (b) Comparison the selected frequency scaling factors of MG benchmark class C running on 8 nodes}
968      \label{fig:powers-heter}
969 \end{figure}
970
971 \begin{figure}[h!]
972   \centering
973    \includegraphics[scale=0.85]{fig/ch3/compare_EDP.pdf}
974   \caption{Trade-off comparison for NAS benchmarks class C}
975   \label{fig:compare_EDP}
976 \end{figure}
977
978
979 \subsection{The comparison of the proposed scaling algorithm }
980 \label{ch3:2:3}
981 In this section, the scaling factors selection algorithm, called MaxDist, is
982 compared to Spiliopoulos et al. algorithm
983 \cite{ref67}, called EDP.  They developed a
984 green governor that regularly applies an online frequency selecting algorithm to
985 reduce the energy consumed by a multicore architecture without degrading much
986 its performance. The algorithm selects the frequencies that minimize the energy
987 and delay products, $\mathit{EDP}=\mathit{energy}\times \mathit{delay}$ using
988 the predicted overall energy consumption and execution time delay for each
989 frequency.  To fairly compare both algorithms, the same energy and execution
990 time models, equations (\ref{eq:energy-heter}) and (\ref{eq:perf_heter}), were used for both
991 algorithms to predict the energy consumption and the execution times. Also
992 Spiliopoulos et al. algorithm was adapted to start the search from the initial
993 frequencies computed using the equation (\ref{eq:Fint}). The resulting algorithm
994 is an exhaustive search algorithm that minimizes the EDP and has the initial
995 frequencies values as an upper bound.
996
997 Both algorithms were applied to the parallel NAS benchmarks to compare their
998 efficiency. Table~\ref{table:compare_EDP} presents the results of comparing the
999 execution times and the energy consumption for both versions of the NAS
1000 benchmarks while running the class C of each benchmark over 8 or 9 heterogeneous
1001 nodes. The results show that our algorithm provides better energy savings than
1002 Spiliopoulos et al. algorithm, on average it results in 29.76\% energy
1003 saving while their algorithm returns just 25.75\%. The average of
1004 performance degradation percentage is approximately the same for both
1005 algorithms, about 4\%.
1006
1007 For all benchmarks,  our algorithm outperforms Spiliopoulos et  al. algorithm in
1008 terms of  energy and  performance trade-off, see  Figure~\ref{fig:compare_EDP},
1009 because it maximizes the distance  between the energy saving and the performance
1010 degradation values while giving the same weight for both metrics.
1011
1012 \section[The energy optimization of grid]{The energy optimization of parallel iterative applications running over grid}
1013 \label{ch3:3}
1014
1015 \subsection{The energy and performance models of grid platform}
1016 \label{ch3:3:1}
1017 In this section, we are interested in reducing the energy consumption of message
1018 passing distributed iterative synchronous applications running over
1019 heterogeneous grid platforms. A heterogeneous grid platform could be defined as a collection of
1020 heterogeneous computing clusters interconnected via a long distance network which has lower bandwidth 
1021 and higher latency than the local networks of the clusters. Each computing cluster in the grid is composed of homogeneous nodes that are connected together via a high speed network. Therefore, each cluster has different characteristics such as computing power (FLOPS), energy consumption, CPU's frequency range, network bandwidth and latency.
1022
1023 Since in a heterogeneous grid each cluster has different characteristics,
1024 especially different frequency gears, when applying DVFS operations on the nodes 
1025 of these clusters, they may get different scaling factors represented by a scaling vector:
1026 $(S_{11}, S_{12},\dots, S_{NM})$ where $S_{ij}$ is the scaling factor of processor $j$ in cluster $i$ . To
1027 be able to predict the execution time of message passing synchronous iterative
1028 applications running over a heterogeneous grid, for different vectors of
1029 scaling factors, the communication time and the computation time for all the
1030 tasks must be measured during the first iteration before applying any DVFS
1031 operation. Then the execution time for one iteration of the application with any
1032 vector of scaling factors can be predicted using (\ref{eq:perf-grid}).
1033 %
1034 \begin{equation}
1035   \label{eq:perf-grid}
1036   \Tnew = \mathop{\max_{i=1,\dots N}}_{j=1,\dots,M}({\TcpOld[ij]} \cdot S_{ij}) 
1037   +\mathop{\min_{j=1,\dots,M}}  (\Tcm[hj])
1038 \end{equation}
1039 %
1040 where $N$ is the number of  clusters in the grid, $M$ is the number of  nodes in
1041 each cluster, $\TcpOld[ij]$ is the computation time of processor $j$ in the cluster $i$ 
1042 and $\Tcm[hj]$ is the communication time of processor $j$ in the cluster $h$ during the 
1043 first  iteration.  The execution time for one iteration is equal to the sum of the maximum computation time for all nodes with the new scaling factors
1044 and the slowest communication time without slack time during one iteration.
1045 The latter is equal to the  communication time of the slowest node in the slowest cluster $h$.
1046 It means that only the communication time without any slack time is taken into account.
1047 Therefore, the execution time of the iterative application is equal to
1048 the execution time of one iteration as in (\ref{eq:perf-grid}) multiplied by the
1049 number of iterations of that application.
1050
1051
1052 In the considered heterogeneous grid platform, each node $j$ in cluster $i$ may have
1053 different dynamic and static powers from the nodes of the other clusters, 
1054 noted as $\Pd[ij]$ and $\Ps[ij]$ respectively.  Therefore, even if the distributed 
1055 message passing iterative application is load balanced, the computation time of each CPU $j$ 
1056 in cluster $i$ noted $\Tcp[ij]$ may be different and different frequency scaling factors may be
1057 computed in order to decrease the overall energy consumption of the application
1058 and reduce slack times.  The communication time of a processor $j$ in cluster $i$ is noted as
1059 $\Tcm[ij]$ and could contain slack times when communicating with slower nodes,
1060 see Figure~\ref{fig:task-heter}.  Therefore, all nodes do not have equal
1061 communication times. While the dynamic energy is computed according to the
1062 frequency scaling factor and the dynamic power of each node as in
1063 (\ref{eq:Edyn}), the static energy is computed as the sum of the execution time
1064 of one iteration multiplied by the static power of each processor.  The overall
1065 energy consumption of a message passing distributed application executed over a
1066 heterogeneous grid platform during one iteration is the summation of all dynamic and
1067 static energies for $M$ processors in $N$ clusters.  It is computed as follows:
1068 \begin{equation}
1069   \label{eq:energy-grid}
1070  E = \sum_{i=1}^{N} \sum_{i=1}^{M} {(S_{ij}^{-2} \cdot \Pd[ij] \cdot  \Tcp[ij])} +  
1071  \sum_{i=1}^{N} \sum_{j=1}^{M} (\Ps[ij] \cdot 
1072   (\mathop{\max_{i=1,\dots N}}_{j=1,\dots,M}({\Tcp[ij]} \cdot S_{ij}) 
1073   +\mathop{\min_{j=1,\dots M}} (\Tcm[hj]) ))
1074 \end{equation}
1075
1076
1077 To optimize both of the energy model \ref{eq:energy-grid} and the performance model\ref{eq:perf-grid},
1078 they must normalizes respectively as in \ref{eq:enorm-heter} and \ref{eq:pnorm-heter}.
1079 While the original energy consumption is the consumed energy with
1080 maximum frequency for all  nodes computes as follows:
1081
1082 \begin{equation}
1083   \label{eq:eorginal-grid}
1084     \Eoriginal = \sum_{i=1}^{N} \sum_{j=1}^{M} ( \Pd[ij] \cdot  \Tcp[ij])  + 
1085      \mathop{\sum_{i=1}^{N}} \sum_{j=1}^{M} (\Ps[ij] \cdot \Told)       
1086 \end{equation}
1087
1088 By the same way, the old execution time with  maximum frequency for all  nodes computes as follows:
1089
1090 \begin{equation}
1091   \label{eq:told-grid}
1092    \Told = \mathop{\max_{i=1,2,\dots,N}}_{j=1,2,\dots,M} (\Tcp[ij]+\Tcm[ij])             
1093 \end{equation}
1094 Therefore, the objective function can be modeled in order to find the maximum
1095 distance between the normalized energy curve  and the normalized performance curve
1096 over all available sets of scaling factors as follows:
1097
1098  \begin{equation}
1099   \label{eq:max-grid}
1100   \MaxDist =
1101 \mathop{  \mathop{\max_{i=1,\dots N}}_{j=1,\dots,M}}_{k=1,\dots,F}
1102       (\overbrace{\Pnorm(S_{ijk})}^{\text{Maximize}} -
1103        \overbrace{\Enorm(S_{ijk})}^{\text{Minimize}} )
1104 \end{equation}
1105
1106 where $N$ is the number of clusters, $M$ is the number of nodes in each cluster and
1107 $F$ is the number of available frequencies for each node.  Then, the optimal set 
1108 of scaling factors that satisfies (\ref{eq:max-grid}) can be selected. 
1109
1110 \subsection{The scaling factors selection algorithm for a grid }
1111 \label{ch3:3:2}
1112
1113 \begin{algorithm}
1114 \setstretch{1}
1115   \begin{algorithmic}[1]
1116     % \footnotesize
1117     
1118     \Require ~
1119
1120     \item [{$N$}] number of clusters in the grid. 
1121     \item [{$M$}] number of nodes in each cluster.
1122     \item[{$\Tcp[ij]$}] array of all computation times for all nodes during one iteration and with the highest frequency.
1123     \item[{$\Tcm[ij]$}] array of all communication times for all nodes during one iteration and with the highest frequency.
1124     \item[{$\Fmax[ij]$}] array of the maximum frequencies for all nodes.
1125     \item[{$\Pd[ij]$}] array of the dynamic powers for all nodes.
1126     \item[{$\Ps[ij]$}] array of the static powers for all nodes.
1127     \item[{$\Fdiff[ij]$}] array of the differences between two successive frequencies for all nodes.
1128
1129     \Ensure $\Sopt[11],\Sopt[12] \dots, \Sopt[NM_i]$,  a vector of scaling factors that gives the optimal trade-off between energy consumption and execution time
1130
1131     \State $\Scp[ij] \gets \frac{ \mathop{\max\limits_{i=1,\dots N}}\limits_{j=1,\dots,M}(\Tcp[ij])} {\Tcp[ij]} $
1132     \State $F_{ij} \gets  \frac{\Fmax[ij]}{\Scp[i]},~{i=1,2,\cdots,N},~{j=1,2,\dots,M_i}.$
1133     \State Round the computed initial frequencies $F_i$ to the closest  available frequency for each node.
1134     \If{(not the first frequency)}
1135           \State $F_{ij} \gets F_{ij}+\Fdiff[ij],~i=1,\dots,N,~{j=1,\dots,M_i}.$
1136     \EndIf
1137     \State $\Told \gets \mathop{\max\limits_{i=1,2,\dots,N}}\limits_{j=1,2,\dots,M} (\Tcp[ij]+\Tcm[ij])     $ 
1138     \State $\Eoriginal \gets \sum_{i=1}^{N} \sum_{j=1}^{M} ( \Pd[ij] \cdot  \Tcp[ij])  + 
1139      \mathop{\sum_{i=1}^{N}} \sum_{j=1}^{M} (\Ps[ij] \cdot \Told)  $ 
1140     \State $\Sopt[ij] \gets 1,~i=1,\dots,N,~{j=1,\dots,M_i}. $
1141     \State $\Dist \gets 0 $
1142     \While {(all nodes have not reached their  minimum   frequency \textbf{or}  $\Pnorm - \Enorm < 0 $)}
1143         \If{(not the last freq. \textbf{and} not the slowest node)}
1144         \State $F_{ij} \gets F_{ij} - \Fdiff[ij],~{i=1,\dots,N},~{j=1,\dots,M_i}$.
1145         \State $S_{ij} \gets \frac{\Fmax[ij]}{F_{ij}},~{i=1,\dots,N},~{j=1,\dots,M_i}.$
1146         \EndIf
1147        \State $\Tnew \gets \mathop{\max\limits_{i=1,\dots N}}\limits_{j=1,\dots,M}({\TcpOld[ij]}
1148         \cdot S_{ij})  +\mathop{\min\limits_{j=1,\dots,M}}  (\Tcm[hj]) $. 
1149        \State $\Ereduced \gets  \sum\limits_{i=1}^{N} \sum\limits_{i=1}^{M} {(S_{ij}^{-2} \cdot \Pd[ij] 
1150         \cdot \Tcp[ij])} +  \sum\limits_{i=1}^{N} \sum\limits_{j=1}^{M} (\Ps[ij] \cdot  
1151         (\mathop{\max\limits_{i=1,\dots N}}\limits_{j=1,\dots,M}({\Tcp[ij]} \cdot S_{ij}) 
1152          +\mathop{\min\limits_{j=1,\dots M}} (\Tcm[hj]) ))$ 
1153        \State $\Pnorm \gets \frac{\Told}{\Tnew}$
1154   
1155        \State $\Enorm \gets \frac{\Ereduced}{\Eoriginal}$
1156       \If{$(\Pnorm - \Enorm > \Dist)$}
1157         \State $\Sopt[ij] \gets S_{ij},~i=1,\dots,N,~j=1,\dots,M_i. $
1158         \State $\Dist \gets \Pnorm - \Enorm$
1159       \EndIf
1160     \EndWhile
1161     \State  Return $\Sopt[11],\Sopt[12],\dots,\Sopt[NM_i]$
1162   \end{algorithmic}
1163   \caption{Scaling factors selection algorithm for grid}
1164   \label{HSA-grid}
1165 \end{algorithm}
1166
1167 \begin{figure}[!t]
1168   \centering
1169   \includegraphics[scale=0.7]{fig/ch3/init_freq}
1170   \caption{Selecting the initial frequencies in grid}
1171   \label{fig:st_freq-grid}
1172 \end{figure}
1173
1174 \begin{figure}[!t]
1175   \centering
1176     \includegraphics[width=.7\textwidth]{fig/ch3/heter2}
1177   \caption{The energy and performance relation in grid}
1178   \label{fig:rel-grid}
1179 \end{figure}
1180
1181
1182 In this section, the scaling factors selection algorithm for a grid, Algorithm~\ref{HSA-grid}, 
1183 is presented. It selects the vector of the frequency
1184 scaling factors  that gives the best trade-off between minimizing the
1185 energy consumption and maximizing the performance of a message passing
1186 synchronous iterative application executed on a  grid that satisfies the objective function 
1187 (\ref{eq:max-grid}).
1188 It has the same  principles and specifications of the frequencies selection algorithm of the heterogeneous 
1189 local cluster \ref{HSA}. 
1190
1191 The value of the initial frequency scaling factor for each node is inversely proportional to its
1192 computation time that was gathered from the first iteration. These initial
1193 frequency scaling factors are computed as a ratio between the computation time
1194 of the slowest node and the computation time of the node $i$ as follows:
1195 \begin{equation}
1196   \label{eq:Scp-grid}
1197   \Scp[ij] =  \frac{ \mathop{\max\limits_{i=1,\dots N}}\limits_{j=1,\dots,M}(\Tcp[ij])} {\Tcp[ij]}
1198 \end{equation}
1199 Using the initial frequency scaling factors computed in (\ref{eq:Scp-grid}), the
1200 algorithm computes the initial frequencies for all nodes as a ratio between the
1201 maximum frequency of node $i$ and the computation scaling factor $\Scp[i]$ as
1202 follows:
1203 \begin{equation}
1204   \label{eq:Fint-grid}
1205   F_{ij} = \frac{\Fmax[ij]}{\Scp[ij]},~{i=1,2,\dots,N},~{j=1,\dots,M}
1206 \end{equation}
1207 Figure \ref{fig:st_freq-grid} shows the selected initial frequencies for a grid composed of three clusters.
1208 In contrast to algorithm \ref{HSA}, algorithm \ref{HSA-grid} replaces the computed initial frequency for a node by the nearest available frequency if not available in the gears of
1209 that node.
1210 The frequency scaling algorithm of the grid stops its iteration if it reaches to lower bound, which is the computed distance between the energy and performance at this frequency if it is less than zero.
1211 A negative distance means that the performance degradation ratio is higher than the energy saving ratio as in figure \ref{fig:rel-grid}.
1212 In this situation, the algorithm must stop the downward search because it has reached the lower bound and it is useless to test the lower frequencies. Indeed, they will all give worse distances. 
1213 Therefore, the algorithm iterates on all remaining frequencies, from the higher
1214 bound until all nodes reach their minimum frequencies or their lower bounds, to compute the overall
1215 energy consumption and performance and selects the optimal vector of the frequency scaling
1216 factors. The DVFS algorithm~\ref{dvfs-heter} is also used to call the algorithm \ref{HSA-grid} in the MPI 
1217 program executed over grid platform. 
1218
1219 \section{Experimental results over Grid5000 platform}
1220 \label{ch3:4}
1221
1222 In this section,  real experiments were conducted over the Grid'5000 platform. 
1223 Grid'5000~\cite{ref21} is a large-scale testbed that consists of ten sites distributed all over  metropolitan France and Luxembourg.  These sites are: Grenoble, Lille, Luxembourg, Lyon, Nancy, Reims, Rennes , Sophia, Toulouse, Bordeaux. Figure \ref{fig:grid5000-dis} shows the geographical distribution of grid'5000 sites over France and Luxembourg. All the sites are connected together via a  special long distance network called RENATER, which is abbreviation of the French
1224 National Telecommunication Network for Technology. Each site in the grid is
1225 composed of a few heterogeneous computing clusters and each cluster contains
1226 many homogeneous nodes. In total, Grid'5000 has about one thousand heterogeneous nodes and eight thousand cores. In each site, the clusters and their nodes
1227 are connected via high speed local area networks. Two types of local networks
1228 are used, Ethernet or Infiniband networks, which have different characteristics
1229 in terms of bandwidth and latency.
1230 Grid'5000 is dedicated as a test-bed for grid computing and thus users can book the required nodes from different sites. 
1231 It also gives the opportunity to the users to deploy their configured image of the operating system over the reserved nodes.
1232 Indeed, many software tools are available for  users in order to control and manage the reservation and deployment processes from their local machines. For example, OAR \cite{ref22} is a  batch scheduler that is used to manage the heterogeneous resources of the grid'5000.
1233
1234 \begin{figure}[h!]
1235 \centering
1236 \includegraphics[scale=1]{fig/ch3/grid5000.pdf}
1237 \caption{Grid5000's sites distribution in France and Luxembourg}
1238 \label{fig:grid5000-dis}
1239 \end{figure}
1240
1241
1242  Moreover, the Grid'5000 testbed provides at some sites a power measurement tool to capture 
1243 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, memory, \dots{} For more details refer to \cite{ref79}. 
1244 In order to correctly measure the CPU power of one core in a node $j$, 
1245  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 
1246 dynamic power consumption of that core with the maximum frequency, see  Figure~\ref{fig:power_cons}. 
1247
1248
1249 The dynamic power $\Pd[j]$ is computed as in Equation~\ref{eq:pdyn}
1250 \begin{equation}
1251   \label{eq:pdyn}
1252     \Pd[j] = \max_{x=\beta_1,\dots \beta_2} (\Pmax[jx])  -  \min_{y=\Theta_1,\dots \Theta_2} (\Pidle[jy])
1253 \end{equation}
1254
1255 where $\Pd[j]$ is the dynamic power consumption for one core of node $j$, 
1256 $\lbrace \beta_1,\beta_2 \rbrace$ is the time interval for the measured maximum power values, 
1257 $\lbrace\Theta_1,\Theta_2\rbrace$ is the time interval for the measured  idle power values.
1258 Therefore, the dynamic power of one core is computed as the difference between the maximum 
1259 measured value in maximum powers vector and the minimum measured value in the idle powers vector.
1260
1261 On the other hand, the static power consumption by one core is a part of the measured idle power consumption of the node. Since in Grid'5000 there is no way to measure precisely the consumed static power and same as in sections  \ref{ch3:2} and \ref{ch2:6} it was assumed that  the static power  represents a ratio of the dynamic power, the value of the static power is assumed as  20\% of dynamic power consumption of the core.
1262
1263 In the experiments presented in the following sections, two sites of Grid'5000 were used, Lyon and Nancy sites. These two sites have in total seven different clusters as shown on Figure~\ref{fig:grid5000}.
1264
1265 Four clusters from the two sites were selected in the experiments: one cluster from 
1266 Lyon's site, Taurus, and three clusters from Nancy's site, Graphene, 
1267 Griffon and Graphite. Each one of these clusters has homogeneous nodes inside, while nodes from different clusters are heterogeneous in many aspects such as: computing power, power consumption, available 
1268 frequency ranges and local network features: the bandwidth and the latency.  Table~\ref{table:grid5000-1} shows 
1269 the detailed characteristics of these four clusters. Moreover, the dynamic powers were computed  using Equation~\ref{eq:pdyn} for all the nodes in the 
1270 selected clusters and are presented in Table~\ref{table:grid5000-1}.
1271
1272
1273 \begin{figure}[!t]
1274   \centering
1275   \includegraphics[scale=1.4]{fig/ch3/grid5000-2}
1276   \caption{The selected two sites of Grid'5000}
1277   \label{fig:grid5000}
1278 \end{figure}
1279 \begin{figure}[!t]
1280   \centering
1281   \includegraphics[scale=0.8]{fig/ch3/power_consumption.pdf}
1282   \caption{The power consumption by one core from the Taurus cluster}
1283   \label{fig:power_cons}
1284 \end{figure}
1285
1286
1287 The energy model and the scaling factors selection algorithm were applied to the NAS parallel benchmarks v3.3 \cite{ref65} and evaluated over Grid'5000.
1288 The benchmark suite contains seven applications: CG, MG, EP, LU, BT, SP and FT. These applications have different computations and communications ratios and strategies which make them good testbed applications to evaluate the proposed algorithm and energy model.
1289 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. 
1290
1291
1292   
1293 \begin{table}[!t]
1294   \caption{CPUs characteristics of the selected clusters}
1295   % title of Table
1296   \centering
1297   \begin{tabular}{|*{7}{c|}}
1298     \hline
1299                 &             & Max   & Min   & Diff. &                 &               \\
1300     Cluster     & CPU         & Freq. & Freq. & Freq. & Cores           & Dynamic power \\
1301     Name        & model       & GHz   & GHz   & GHz   & per CPU         & of one core   \\
1302     \hline
1303                 & Intel       &       &       &         &           &              \\
1304     Taurus      & Xeon        & 2.3   & 1.2   & 0.1     & 6         & \np[W]{35}    \\
1305                 & E5-2630     &       &       &         &           &            \\         
1306     \hline
1307                 & Intel       &       &       &         &           &             \\
1308     Graphene    & Xeon        & 2.53  & 1.2   & 0.133   & 4         & \np[W]{23}  \\
1309                 & X3440       &       &       &         &           &             \\    
1310     \hline
1311                 & Intel       &       &       &         &           &            \\
1312     Griffon     & Xeon        & 2.5   & 2     & 0.5     & 4         & \np[W]{46}  \\
1313                 & L5420       &       &       &         &           &            \\  
1314     \hline
1315                 & Intel       &       &       &         &           &            \\
1316      Graphite   & Xeon        & 2     & 1.2   & 0.1     & 8         & \np[W]{35} \\
1317                 & E5-2650     &       &       &         &           &            \\  
1318     \hline
1319   \end{tabular}
1320   \label{table:grid5000-1}
1321 \end{table} 
1322
1323
1324
1325 \subsection{The experimental results of the scaling algorithm of  Grid}
1326 \label{ch3:4:1}
1327 In this section, the results of applying  the scaling factors selection algorithm \ref{HSA} 
1328 to NAS parallel benchmarks are presented. 
1329
1330 As mentioned previously, the experiments 
1331 were conducted over two sites of Grid'5000,  Lyon and Nancy sites. 
1332 Two scenarios were considered while selecting the clusters from these two sites :
1333 \begin{itemize}
1334 \item In the first scenario, nodes from two sites and three heterogeneous clusters were selected. The two sites are connected 
1335  via a long distance network.
1336 \item In the second scenario nodes from three clusters located in one site, Nancy site, were selected.  
1337 \end{itemize}
1338
1339 The main reason 
1340 for using these two scenarios is to evaluate the influence of long distance communications (higher latency) on the performance of the 
1341 scaling factors selection algorithm. Indeed, in the first scenario the computations to communications ratio 
1342 is very low due to the higher communication times which reduce the effect of DVFS operations.
1343
1344 The NAS parallel benchmarks are executed over 
1345 16 and 32 nodes for each scenario. The number of participating computing nodes from each cluster 
1346 is different because all the selected clusters do not have the same available number of nodes and all benchmarks do not require the same number of computing nodes.
1347 Table~\ref{tab:sc} shows the number of nodes used from each cluster for each scenario. 
1348
1349 \begin{table}[h]
1350
1351 \caption{The different clusters scenarios}
1352 \centering
1353 \begin{tabular}{|*{4}{c|}}
1354 \hline
1355 \multirow{2}{*}{Scenario name}        & \multicolumn{3}{c|} {The participating clusters} \\ \cline{2-4} 
1356                                       & Cluster & Site           & Nodes per cluster     \\ 
1357 \hline
1358 \multirow{3}{*}{Two sites / 16 nodes} & Taurus & Lyon                & 5                      \\ \cline{2-4} 
1359                                       & Graphene  & Nancy             & 5                      \\ \cline{2-4} 
1360                                       & Griffon       & Nancy        & 6                      \\ 
1361 \hline
1362 \multirow{3}{*}{Tow sites / 32 nodes} & Taurus  & Lyon               & 10                     \\ \cline{2-4} 
1363                                       & Graphene  & Nancy             & 10                     \\ \cline{2-4} 
1364                                       & Griffon     &Nancy           & 12                     \\ 
1365 \hline
1366 \multirow{3}{*}{One site / 16 nodes}  & Graphite    & Nancy            & 4                      \\ \cline{2-4} 
1367                                       & Graphene     & Nancy           & 6                      \\ \cline{2-4} 
1368                                       & Griffon         & Nancy        & 6                      \\ 
1369 \hline
1370 \multirow{3}{*}{One site / 32 nodes}  & Graphite   & Nancy             & 4                      \\ \cline{2-4} 
1371                                       & Graphene      & Nancy          & 14                     \\ \cline{2-4} 
1372                                       & Griffon          & Nancy       & 14                       \\ 
1373 \hline
1374 \end{tabular}
1375  \label{tab:sc}
1376 \end{table}
1377
1378
1379 The NAS parallel benchmarks are executed over these two platforms
1380  with different number of nodes, as in Table~\ref{tab:sc}. 
1381 The overall energy consumption of all the benchmarks solving the class D instance and
1382 using the proposed frequency selection algorithm is measured 
1383 using the equation of the reduced energy consumption, Equation~\ref{eq:energy-grid}. This model uses the measured dynamic power showed in Table~\ref{table:grid5000-1}
1384 and the static 
1385 power is assumed to be equal to 20\% of the dynamic power. The execution
1386 time is measured for all the benchmarks over these different scenarios.  
1387
1388 The energy consumptions  and the execution times for all the benchmarks are 
1389 presented in Figures~\ref{fig:exp-time-energy} (a) and (b) respectively.
1390
1391 For the majority of the benchmarks, the energy consumed while executing  the NAS benchmarks over one site scenario 
1392 for  16 and 32 nodes is lower than the energy consumed while using two sites. 
1393 The long distance communications between the two distributed sites increase the idle time, which leads to more static energy consumption. 
1394
1395 The execution times of these benchmarks 
1396 over one site with 16 and 32 nodes are also lower when  compared to those of the  two sites 
1397 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).
1398
1399 However, the execution times and the energy consumptions of EP and MG
1400 benchmarks, which have no or small communications, are not significantly
1401 affected in both scenarios, even when the number of nodes is doubled.  On the
1402 other hand, the communication times of the rest of the benchmarks increases when
1403 using long distance communications between two sites or increasing the number of
1404 computing nodes.
1405
1406
1407 The energy saving percentage is computed as the ratio between the reduced 
1408 energy consumption, Equation~\ref{eq:energy-grid}, and the original energy consumption,
1409 Equation~\ref{eq:eorginal-grid}, for all benchmarks as in Figure~\ref{fig:eng_s}. 
1410 This figure shows that the energy saving percentages of one site scenario for
1411 16 and 32 nodes are bigger than those of the two sites scenario which is due
1412 to the higher  computations to communications ratio in the first scenario   
1413 than in the second one. Moreover, the frequency selecting algorithm selects smaller frequencies when the computation times are bigger than the communication times which
1414 results in  a lower energy consumption. Indeed, the dynamic  consumed power
1415 is exponentially related to the CPU's frequency value. On the other hand, the increase in the number of computing nodes can 
1416 increase the communication times and thus produces less energy saving depending on the 
1417 benchmarks being executed. The results of benchmarks CG, MG, BT and FT show more 
1418 energy saving percentage in one site scenario when executed over 16 nodes comparing to 32 nodes. While, 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. 
1419 \begin{figure}[!t]
1420   \centering
1421   \centering
1422    \includegraphics[width=.7\textwidth]{fig/ch3/eng_con_scenarios.eps}\\~~~~~~~~~(a)\\
1423    \includegraphics[width=.7\textwidth]{fig/ch3/time_scenarios.eps}\\~~~~~~~~~(b)
1424   \caption{ (a) energy consumption and (b) execution time of NAS  Benchmarks over different scenarios}
1425   \label{fig:exp-time-energy}
1426   
1427 \end{figure}
1428
1429
1430 The energy saving percentage is reduced for all the benchmarks because of the long distance communications in the two sites 
1431 scenario, except for the   EP benchmark which has  no communication. Therefore, the energy saving percentage of this benchmark is 
1432 dependent on the maximum difference between the computing powers of the heterogeneous computing nodes, for example 
1433 in the one site scenario, the graphite cluster is selected but in the two sites scenario 
1434 this cluster is replaced with the Taurus cluster which is more powerful. 
1435 Therefore, the energy savings of the EP benchmark are bigger in the two sites scenario due 
1436 to the higher maximum difference between the computing powers of the nodes. 
1437
1438 In fact, high differences between the nodes' computing powers make the proposed frequencies selecting  
1439 algorithm  select smaller frequencies for the powerful nodes which 
1440 produces less energy consumption and thus more energy saving.
1441 The best energy saving percentage was obtained in the one site scenario with 16 nodes, the energy consumption was on average reduced up to 30\%.
1442
1443
1444
1445 \begin{figure*}[t]
1446 \centering
1447 \includegraphics[width=.7\textwidth]{fig/ch3/eng_s.eps}
1448 \caption{The energy reduction while executing the NAS benchmarks over different scenarios}
1449 \label{fig:eng_s}
1450 \end{figure*}
1451 \begin{figure*}[t]
1452 \centering
1453 \includegraphics[width=.7\textwidth]{fig/ch3/per_d.eps}
1454 \caption{The performance degradation of the NAS benchmarks over different scenarios}
1455 \label{fig:per_d}
1456 \end{figure*}
1457 \begin{figure*}[t]
1458 \centering
1459 \includegraphics[width=.7\textwidth]{fig/ch3/dist.eps}
1460 \caption{The trade-off distance between the energy reduction and the performance of the NAS benchmarks  
1461       over different scenarios}
1462 \label{fig:dist-grid}
1463 \end{figure*}
1464
1465
1466
1467 Figure \ref{fig:per_d} presents the performance degradation percentages for all benchmarks over the two scenarios.
1468 The performance degradation percentage for the benchmarks running on two sites  with
1469 16 or 32  nodes is on average equal to 8.3\% or 4.7\% respectively. 
1470 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
1471 16 or 32  nodes is on average equal to 3.2\% or 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 
1472 nodes when the communications occur in high speed network does not decrease the computations to 
1473 communication ratio. 
1474
1475 The performance degradation percentage of the EP benchmark after applying the scaling factors selection algorithm is the highest in comparison to 
1476 the other benchmarks. Indeed, in the EP benchmark, there are no communication and slack times and its 
1477 performance degradation percentage only depends on the frequencies values selected by the algorithm for the computing nodes.
1478 The rest of the benchmarks showed different performance degradation percentages, which decrease
1479 when the communication times increase and vice versa.
1480
1481 Figure \ref{fig:dist-grid} presents the  distance percentage between the energy saving  and the performance degradation for each benchmark  over both  scenarios. The trade-off distance percentage can be 
1482 computed as in Equation~\ref{eq:max-grid}. The one site scenario with 16 nodes gives the best energy and performance 
1483 trade-off, on average it is equal to  26.8\%. The one site scenario using both 16 and 32 nodes had better energy and performance 
1484 trade-off comparing to the two sites scenario  because the former has high speed local communications 
1485 which increase the computations to communications ratio  and the latter uses long distance communications which decrease this ratio. 
1486
1487  Finally, the best energy and performance trade-off depends on all of the following:
1488 1) the computations to communications ratio when there are  communications and slack times, 2) the heterogeneity of the computing powers of the nodes and 3) the heterogeneity of the consumed  static and dynamic powers of the nodes.
1489
1490
1491
1492
1493 \subsection{The experimental results over multi-cores clusters}
1494 \label{ch3:4:2}
1495
1496 The  clusters of Grid'5000 have different number of cores embedded in their nodes
1497 as shown in Table~\ref{table:grid5000-1}. In 
1498 this section, the proposed scaling algorithm of the grid is evaluated over the  Grid'5000 platform  while using multi-cores nodes selected according to the one site scenario described in  Section
1499 ~\ref{ch3:4:1}.
1500 The one site scenario uses  32 cores from multi-cores nodes instead of 32 distinct nodes. For example if 
1501 the participating number of cores from a certain cluster is equal to 14, 
1502 in the multi-core scenario the selected nodes is equal to  4 nodes while using 
1503 3 or 4 cores from each node. The platforms with one  
1504 core per node and  multi-cores nodes are  shown in Table~\ref{table:sen-mc}. 
1505 The energy consumptions and execution times of running  class D of the NAS parallel 
1506 benchmarks over these two different scenarios are presented 
1507 in Figures \ref{fig:eng-cons-mc} and \ref{fig:time-mc} respectively.
1508
1509
1510 \begin{table}[]
1511 \centering
1512 \caption{The multicores scenarios}
1513 \begin{tabular}{|*{4}{c|}}
1514 \hline
1515 Scenario name                          & Cluster name & Nodes per cluster & 
1516                                        Cores per node  \\ \hline
1517 \multirow{3}{*}{One core per node}    & Graphite     & 4               & 1                   \\  \cline{2-4}
1518                                        & Graphene     & 14              & 1                   \\  \cline{2-4}
1519                                        & Griffon      & 14              & 1                   \\ \hline
1520 \multirow{3}{*}{Multi-cores per node}  & Graphite     & 1               &  4              \\  \cline{2-4}
1521                                        & Graphene     & 4               & 3 or 4              \\  \cline{2-4}
1522                                        & Griffon      & 4               & 3 or 4                   \\ \hline
1523 \end{tabular}
1524 \label{table:sen-mc}
1525 \end{table}
1526
1527
1528
1529
1530 \begin{figure}[!t]
1531  \centering
1532  \includegraphics[width=.7\textwidth]{fig/ch3/time.eps}
1533  \caption{The execution times of running NAS benchmarks over one core and multicores scenarios}
1534   \label{fig:time-mc}
1535 \end{figure}
1536 \begin{figure}[!t]
1537  \centering
1538  \includegraphics[width=.7\textwidth]{fig/ch3/eng_con.eps}
1539  \caption{The energy consumptions and execution times of NAS benchmarks over one core and multi-cores per node architectures}
1540 \label{fig:eng-cons-mc}
1541 \end{figure}
1542
1543 The execution times for most of  the NAS  benchmarks are higher over the multi-cores per node scenario 
1544 than over single core per node  scenario. Indeed,  
1545  the communication times  are higher in the one site multi-cores scenario than in the latter scenario because all the cores of a node  share  the same node network link which can be  saturated when running communication bound applications. Moreover, the cores of a node share the memory bus which can be also saturated and become a bottleneck.    
1546 Moreover, the energy consumptions of the NAS benchmarks are lower over the 
1547  one core scenario  than over the multi-cores scenario because 
1548 the first scenario had less execution time than the latter which results in less static energy being consumed.
1549 The computations to communications ratios of the NAS benchmarks are higher over 
1550 the one site one core scenario  when compared to the ratio of the multi-cores scenario. 
1551 More energy reduction can be gained when this ratio is big because it pushes the proposed scaling algorithm to select smaller frequencies that decrease the dynamic power consumption. These experiments also showed that the energy 
1552 consumption and the execution times of the EP and MG benchmarks do not change significantly over these two
1553 scenarios  because there are no or small communications. Contrary to EP and MG, the  energy consumptions and the execution times of the rest of the  benchmarks  vary according to the  communication times that are different from one scenario to the other.
1554
1555   
1556 \begin{figure*}[!t]
1557  \centering
1558  \includegraphics[width=.7\textwidth]{fig/ch3/eng_s_mc.eps}
1559   \caption{The energy saving of running NAS benchmarks over one core and multicores scenarios}
1560   \label{fig:eng-s-mc}
1561 \end{figure*}   
1562 \begin{figure*}[!t]
1563  \centering
1564 \includegraphics[width=.7\textwidth]{fig/ch3/per_d_mc.eps}
1565   \caption{The performance degradation of running NAS benchmarks over one core and multicores scenarios}
1566   \label{fig:per-d-mc}
1567 \end{figure*}
1568 \begin{figure*}[!t]
1569  \centering
1570  \includegraphics[width=.7\textwidth]{fig/ch3/dist_mc.eps}
1571   \caption{The trade-off distance of running NAS benchmarks over one core and multicores scenarios}
1572   \label{fig:dist-mc}
1573 \end{figure*}
1574   
1575 The energy saving percentages of all NAS benchmarks running over these two scenarios are presented in Figure~\ref{fig:eng-s-mc}. 
1576 The figure shows that  the energy saving percentages in the one 
1577 core and the multi-cores scenarios
1578 are approximately equivalent, on average they are equal to  25.9\% and 25.1\% respectively.
1579 The energy consumption is reduced at the same rate in the two scenarios when compared to the energy consumption of the executions without DVFS. 
1580
1581
1582 The performance degradation percentages of the NAS benchmarks are presented in
1583 Figure~\ref{fig:per-d-mc}. It shows that the performance degradation percentages are higher for the NAS benchmarks over the  one core per node scenario  (on average equal to 10.6\%)  than over the  multi-cores scenario (on average equal to 7.5\%). The performance degradation percentages over the multi-cores scenario are lower because  the computations to communications ratios are smaller than the ratios of the other scenario. 
1584
1585 The trade-off distances percentages of the NAS benchmarks over the two scenarios are presented 
1586 in ~Figure~\ref{fig:dist-mc}. These  trade-off distances between energy consumption reduction and performance  are used to verify which scenario is the best in both terms  at the same time. The figure shows that  the  trade-off distance percentages are on average   bigger over the multi-cores scenario  (17.6\%) than over the  one core per node scenario  (15.3\%).
1587
1588
1589 \subsection{Experiments with different static power scenarios}
1590 \label{ch3:4:3}
1591
1592 In Section~\ref{ch3:4}, since it was not possible to measure the static power consumed by a CPU,   the static power was assumed to be equal to 20\% of the measured dynamic power. This power is consumed during the whole execution time, during computation and communication times. Therefore, when the DVFS operations are applied by the scaling algorithm and the CPUs' frequencies lowered, the execution time might increase and consequently the consumed static energy will be increased too. 
1593
1594 The aim of  this section is to evaluate the scaling algorithm while assuming different values of static powers. 
1595 In addition to the previously used  percentage of static power, two new static power ratios,  10\% and 30\% of the measured dynamic power of the core, are used in this section.
1596 The experiments have been executed with these two new static power scenarios  over the one site one core per node scenario.
1597 In these experiments, class D of the NAS parallel benchmarks are executed over the Nancy site. 16 computing nodes from the three clusters, Graphite, Graphene and Griffon, where used in this experiment. 
1598
1599
1600
1601
1602 \begin{figure}[!t]
1603   \centering
1604   \includegraphics[width=.7\textwidth]{fig/ch3/eng_pow.eps}
1605   \caption{The energy saving percentages for the nodes executing the NAS benchmarks over the three power scenarios}
1606   \label{fig:eng-pow}
1607 \end{figure}
1608 \begin{figure}[!t]
1609   \centering
1610    \includegraphics[width=.7\textwidth]{fig/ch3/per_pow.eps}
1611   \caption{The performance degradation percentages for the NAS benchmarks over the three power scenarios}
1612   \label{fig:per-pow}
1613 \end{figure}
1614 \begin{figure}[!t]
1615   \centering
1616   \includegraphics[width=.7\textwidth]{fig/ch3/dist_pow.eps}
1617   \caption{The trade-off distance between the energy reduction and the performance of the NAS benchmarks over the three power scenarios}
1618   \label{fig:dist-pow}
1619 \end{figure}
1620
1621
1622 \begin{figure}
1623   \centering
1624   \includegraphics[scale=0.7]{fig/ch3/three_scenarios2.pdf}
1625   \caption{Comparing the selected frequency scaling factors for the MG benchmark over the three static power scenarios}
1626   \label{fig:fre-pow}
1627 \end{figure}
1628
1629 The energy saving percentages of the NAS benchmarks with the three static power scenarios are presented 
1630 in Figure~\ref{fig:eng-pow}. This figure shows that the  10\% of static power scenario 
1631 gives the biggest energy saving percentages in comparison to the 20\% and 30\% static power 
1632 scenarios. The small value of the static power consumption makes the proposed 
1633 scaling algorithm  select smaller frequencies for the CPUs. 
1634 These smaller frequencies reduce the dynamic energy consumption more than increasing the consumed static energy which gives             less overall energy consumption. 
1635 The energy saving percentages of the 30\% static power scenario is the smallest between the other scenarios, because the scaling algorithm selects bigger frequencies for the CPUs which increases the energy consumption. Figure \ref{fig:fre-pow} demonstrates that the proposed scaling algorithm selects   the best frequency scaling factors   according to the static power consumption ratio being used.
1636
1637 The performance degradation percentages are presented in Figure~\ref{fig:per-pow}.
1638 The 30\% static power scenario had less performance degradation percentage  because the scaling algorithm
1639 had  selected big frequencies for the CPUs. While, 
1640 the inverse happens in the 10\% and 20\% scenarios because the scaling algorithm had selected  CPUs' frequencies smaller than those of the 30\% scenario. The trade-off distance percentage for the NAS benchmarks with these three static power scenarios 
1641 are presented in Figure~\ref{fig:dist-pow}. 
1642 It shows that the best  trade-off
1643 distance percentage is obtained with  the  10\% static power scenario  and this percentage 
1644 is decreased for the other two scenarios because the scaling algorithm had selected different frequencies according to the static power values.
1645
1646 In the EP benchmark, the energy saving, performance degradation and trade-off 
1647 distance percentages for these static power scenarios are not significantly different because there is no communication in this benchmark. Therefore, the static power is only consumed during computation and   the proposed scaling algorithm selects similar frequencies for the three scenarios.  On the other hand,  for the rest of the benchmarks,  the scaling algorithm  selects  the values of the frequencies according to the communication times of each benchmark because the static energy consumption increases  proportionally to the  communication times.
1648
1649
1650  
1651 \subsection{Comparison of the proposed frequencies selecting algorithm }
1652 \label{ch3:4:4}
1653
1654 Finding the frequencies that give the best trade-off between the energy consumption and the performance for a parallel 
1655 application is not a trivial task.  Many algorithms have been proposed to tackle this problem.  
1656 In this section, the proposed frequencies selecting algorithm is compared to a method that uses the well known  energy and delay product objective function, $EDP=energy \times delay$, that has been used by many researchers  \cite{ref80,ref81,ref82}. 
1657 This objective function  was also used by Spiliopoulos et al. algorithm \cite{ref67} where they select the frequencies that minimize the EDP product and apply them with DVFS operations to  the multi-cores 
1658 architecture. Their online algorithm predicts the energy consumption and execution time of a processor before using the EDP method.
1659
1660 To fairly compare the proposed frequencies scaling algorithm to  Spiliopoulos et al. algorithm, called Maxdist and EDP respectively, both algorithms use the same energy model,  Equation~\ref{eq:energy-grid} and
1661 execution time model, Equation~\ref{eq:perf-grid}, to predict the energy consumption and the execution time for each computing node.
1662 Moreover, both algorithms start the search space from the upper bound computed as in Equation~\ref{eq:Fint}.
1663 Finally, the resulting EDP algorithm is an exhaustive search algorithm that tests all the possible frequencies, starting from the initial frequencies (upper bound), 
1664 and selects the vector of frequencies that minimize the EDP product.
1665 Both algorithms were applied to class D of the NAS benchmarks over 16 nodes.
1666 The participating computing nodes are distributed  according to the two scenarios described in  Section~\ref{ch3:4:1}. 
1667 The experimental results, the energy saving, performance degradation and trade-off distance percentages, are 
1668 presented in  Figures~\ref{fig:edp-eng}, \ref{fig:edp-perf} and \ref{fig:edp-dist} respectively.
1669
1670
1671
1672 \begin{figure*}[!t]
1673   \centering
1674   \includegraphics[width=.7\textwidth]{fig/ch3/edp_eng}
1675 \caption{The energy reduction induced by the Maxdist method and the EDP method}
1676 \label{fig:edp-eng}
1677 \end{figure*}
1678 \begin{figure*}[!t]
1679   \centering
1680   \includegraphics[width=.7\textwidth]{fig/ch3/edp_per}
1681 \caption{The performance degradation induced by the Maxdist method and the EDP method}
1682 \label{fig:edp-perf}
1683 \end{figure*}
1684 \begin{figure*}[!t]
1685   \centering
1686    \includegraphics[width=.7\textwidth]{fig/ch3/edp_dist}
1687 \caption{The trade-off distance between the energy consumption reduction and the performance for the Maxdist method and the  EDP method}
1688 \label{fig:edp-dist}
1689 \end{figure*}
1690
1691
1692 As shown in these figures, the proposed frequencies selection algorithm, Maxdist, outperforms the EDP algorithm in terms of energy consumption reduction and performance for all of the benchmarks executed over the two scenarios. 
1693 The proposed algorithm gives better results than EDP  because it 
1694 maximizes the energy saving and the performance at the same time. 
1695 Moreover, the proposed scaling algorithm gives the same weight for these two metrics.
1696 Whereas, the EDP algorithm gives sometimes negative trade-off values for some benchmarks in the two sites scenarios.
1697 These negative trade-off values mean that the performance degradation percentage is higher than the energy saving percentage.
1698 The high positive values of the trade-off distance percentage mean that the  energy saving percentage is much higher than the performance degradation percentage. 
1699 The time complexity of both Maxdist and EDP algorithms are $O(N \cdot M \cdot F)$ and 
1700 $O(N \cdot M \cdot F^2)$ respectively, where $N$ is the number of the clusters, $M$ is the number of nodes and $F$ is the 
1701 maximum number of available frequencies. When Maxdist is applied to a benchmark that is being executed over 32 nodes distributed between Nancy and Lyon sites, it takes on average  $0.01 ms$  to compute the best frequencies while EDP is on average ten times slower over the same architecture.  
1702
1703
1704 \section{Conclusion}
1705 \label{ch3:concl}
1706 In this chapter,  two new online frequency scaling factors selecting algorithms have been presented. They select the best possible vectors of frequency scaling factors that give the
1707 maximum distance (optimal trade-off) between the predicted energy and the
1708 predicted performance curves for a heterogeneous cluster and grid. Both  algorithms use a
1709 new energy models for measuring and predicting the energy of distributed
1710 iterative applications running over a heterogeneous local cluster and a grid platform. 
1711 Firstly, the  proposed scaling factors selection algorithm for a heterogeneous local cluster  is applied to  NAS parallel benchmarks class C and  simulated by SimGrid.
1712 The results of the experiments showed  that the algorithm on average reduces by 29.8\% the energy 
1713 consumption of NAS benchmarks executed over 8 nodes while limiting the degradation of the performance by 3.8\%.  The algorithm also selects different scaling factors according to
1714 the percentage of the computing and communication times, and according to the
1715 values of the static and dynamic powers of the CPUs. 
1716 Secondly, the proposed scaling factors selection algorithm for a grid is applied to  NAS parallel benchmarks class D and  executed over Grid5000 testbed platform.
1717 The experiments on 16 nodes, distributed over three clusters, showed that the algorithm   on average reduces by 30\% the energy consumption
1718 for all the NAS benchmarks   while  on average only degrading by 3.2\%   the performance. 
1719 The  algorithm was also evaluated in different scenarios that vary in the distribution of the computing nodes between different clusters' sites or  use multi-cores per node architecture or consume different static power values. The algorithm selects different vectors of frequencies according to the 
1720 computations and communication times ratios, and  the values of the static and measured dynamic powers of the CPUs. Thus, the simulation and the real results are comparable in term of energy saving and performance degradation percentages.
1721 Finally, both the proposed algorithms were compared to another method that uses
1722 the well known energy and delay product as an objective function. The comparison results showed 
1723 that the proposed algorithms outperform the latter by selecting vectors of frequencies that give a better 
1724 trade-off results.