Index: /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux
===================================================================
--- /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux	(revision 715)
+++ /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux	(revision 716)
@@ -79,22 +79,31 @@
 \newlabel{workloadChatacteristics}{{2}{21}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Computational analysis}{21}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.1}Random approach}{22}}
 \@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces  Random strategy}}{22}}
 \newlabel{fig:70r}{{9}{22}}
 \@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces  Random + switching off unused nodes strategy}}{23}}
 \newlabel{fig:70rnpm}{{10}{23}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.2}Energy optimization}{23}}
+\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces  Measured power of testbed nodes in idle state}}{24}}
+\newlabel{idlePower}{{3}{24}}
 \@writefile{lof}{\contentsline {figure}{\numberline {11}{\ignorespaces  Energy usage optimization strategy}}{24}}
 \newlabel{fig:70eo}{{11}{24}}
-\@writefile{toc}{\contentsline {section}{\numberline {6}DCWoRMS application/use cases}{24}}
-\newlabel{sec:coolemall}{{6}{24}}
 \@writefile{lof}{\contentsline {figure}{\numberline {12}{\ignorespaces  Energy usage optimization + switching off unused nodes strategy}}{25}}
 \newlabel{fig:70eonpm}{{12}{25}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.3}Frequency scaling}{26}}
 \@writefile{lof}{\contentsline {figure}{\numberline {13}{\ignorespaces  Frequency downgrading strategy}}{26}}
 \newlabel{fig:70dfs}{{13}{26}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}DCWoRMS application/use cases}{26}}
+\newlabel{sec:coolemall}{{6}{26}}
+\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces  Energy usage [kWh] for different level of system load}}{27}}
+\newlabel{loadEnergy}{{4}{27}}
+\@writefile{lot}{\contentsline {table}{\numberline {5}{\ignorespaces  Makespan [s] for different level of system load}}{27}}
+\newlabel{loadMakespan}{{5}{27}}
 \bibcite{fit4green}{{1}{}{{}}{{}}}
+\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusions and future work}{28}}
+\newlabel{}{{7}{28}}
 \bibcite{CloudSim}{{2}{}{{}}{{}}}
 \bibcite{DCSG}{{3}{}{{}}{{}}}
 \bibcite{DCD_Romonet}{{4}{}{{}}{{}}}
-\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusions and future work}{27}}
-\newlabel{}{{7}{27}}
 \bibcite{networks}{{5}{}{{}}{{}}}
 \bibcite{Ghislain}{{6}{}{{}}{{}}}
Index: /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk
===================================================================
--- /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk	(revision 715)
+++ /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk	(revision 716)
@@ -1,4 +1,4 @@
 # Fdb version 2
-["pdflatex"] 1356682580 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
+["pdflatex"] 1356710663 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
   "/usr/local/texlive/2010/texmf-dist/tex/context/base/supp-pdf.mkii" 1251025892 71625 fad1c4b52151c234b6873a255b0ad6b3 ""
   "/usr/local/texlive/2010/texmf-dist/tex/generic/oberdiek/etexcmds.sty" 1267408169 5670 cacb018555825cfe95cd1e1317d82c1d ""
@@ -30,7 +30,7 @@
   "/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upsy.fd" 1137110629 148 2da0acd77cba348f34823f44cabf0058 ""
   "/usr/local/texlive/2010/texmf-dist/tex/latex/psnfss/upzd.fd" 1137110629 148 b2a94082cb802f90d3daf6dd0c7188a0 ""
-  "elsarticle-DCWoRMS.aux" 1356682582 6557 747cbb517bc749f6757901046991ff0a ""
-  "elsarticle-DCWoRMS.spl" 1356682580 0 d41d8cd98f00b204e9800998ecf8427e ""
-  "elsarticle-DCWoRMS.tex" 1356682576 61620 cec13b82c9efcd249d3e27e2ea804af9 ""
+  "elsarticle-DCWoRMS.aux" 1356710665 7300 93160f416a8461d41a3c200dac702a78 ""
+  "elsarticle-DCWoRMS.spl" 1356710663 0 d41d8cd98f00b204e9800998ecf8427e ""
+  "elsarticle-DCWoRMS.tex" 1356710660 64538 98c98b811c1eb8e1409935f8ce2553dd ""
   "elsarticle.cls" 1352447924 26095 ad44f4892f75e6e05dca57a3581f78d1 ""
   "fig/70dfs.png" 1356617710 212573 e013d714dd1377384ed7793222210051 ""
Index: /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex
===================================================================
--- /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex	(revision 715)
+++ /papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex	(revision 716)
@@ -493,6 +493,6 @@
  & \multicolumn{4}{c}{C-Ray} & uniform - 20\%\\
  & \multicolumn{4}{c}{Tar} & uniform - 20\%\\
- & \multicolumn{4}{c}{Linpac - 3Gb} & uniform - 10\%\\
- & \multicolumn{4}{c}{Linpac - tiny} & uniform - 10\%\\
+ & \multicolumn{4}{c}{Linpack - 3Gb} & uniform - 10\%\\
+ & \multicolumn{4}{c}{Linpack - tiny} & uniform - 10\%\\
  & \multicolumn{4}{c}{FFT} & uniform - 20\%\\
 
@@ -506,8 +506,11 @@
 \subsection{Computational analysis}
 
-The scheduling strategy was evaluated according to two criteria: total energy consumption and total completion time.
-In the following section we present the results obtained for the workload with load density equal to 70\% in the light of five resource management and scheduling strategies. Then we discusses the corresponding results received for workloads with other density level.
-
-The first considered by us policy was the Random strategy in which tasks were assigned to nodes in random manner with the reservation that they can be assigned only to nodes of the type which the application was possible to execute on and we have the corresponding value of power consumption and execution time. The random strategy is only the reference one and will be later used to compare benefits in terms of energy efficiency resulting from more sophisticated algorithms. 
+In the following section we present the results obtained for the workload with load density equal to 70\% in the light of five resource management and scheduling strategies.  The scheduling strategies were evaluated according to two criteria: total energy consumption and maximum completion time of all tasks (makespan).
+In the second part of this section en we discusses the corresponding results received for workloads with other density level.
+
+\subsubsection{Random approach}
+
+The first considered by us policy was the Random strategy in which tasks were assigned to nodes in random manner with the reservation that they can be assigned only to nodes of the type which the application was possible to execute on and we have the corresponding value of power consumption and execution time. The Random strategy is only the reference one and will be later used to compare benefits in terms of energy efficiency resulting from more sophisticated algorithms. Criteria values are as follows: \textbf{total energy usage}: 46,883 kWh, \textbf{workload completion time}: 533 820 s.
+Figure~\ref{fig:70r} presents the energy consumption, load of the system and obtained schedule, respectively.
 
 
@@ -518,9 +521,5 @@
 \end{figure}
 
-\textbf{total energy usage}: 46,883 kWh
-\textbf{mean power consumption}: 316,17 W
-\textbf{workload completion}: 533 820 s
-
-We investigated also the second version of this strategy, which is getting more popular due to energy costs in which unused nodes are switched off to reduce the total energy consumption. In the previous one, unused nodes are not switched off, which case is still the the primary one in many HPC centers. 
+In the second version of this strategy, which is getting more popular due to energy costs, we switched of unused nodes to reduce the total energy consumption. In the previous one, unused nodes are not switched off, which case is still the the primary one in many HPC centers. 
 
 \begin{figure}[h!]
@@ -530,12 +529,25 @@
 \end{figure}
 
-\textbf{total energy usage}: 36,705 kWh
-\textbf{mean power consumption}: 247,53 W
-\textbf{workload completion}: 533 820 s
-
-In this version of experiment we neglected additional cost and time necessary to  change the power state of resources. As expected, switching of unused nodes led to significant decrease of the total energy consumption. The overall savings reached 22\%
-
-The next two evaluate resource management strategies try to decrease the total energy consumption needed to execute the whole workload taking into account differences in applications and hardware profiles.  We tried to match both profiles to find the more energy efficient assignment. In the first case we assumed that there is again no possibility to switch off unused nodes, thus for the whole time needed to execute workload nodes consume at least power for idle state. To obtain the minimal energy consumption, tasks has to be assigned to the nodes of type for which the difference between energy consumption for the node running the application and in the idle state is minimal.
-
+In this version of experiment we neglected additional cost and time necessary to change the power state of resources. As can be observed in the power consumption chart in the Figure~\ref{fig:70rnpm}, switching of unused nodes led to decrease of the total energy consumption. As expected, with respect to the makespan criterion, both approaches perform equally reaching \textbf{workload completion time}: 533 820 s. However, the pure random strategy was significantly outperformed in terms of energy usage, by the policy with additional node power management with it \textbf{total energy usage}: 36,705 kWh. The overall energy savings reached 22\%. 
+
+\subsubsection{Energy optimization}
+
+The next two evaluate resource management strategies try to decrease the total energy consumption needed to execute the whole workload taking into account differences in applications and hardware profiles. We tried to match both profiles to find the more energy efficient assignment. In the first case we assumed that there is again no possibility to switch off unused nodes, thus for the whole time needed to execute workload nodes consume at least power for idle state. To obtain the minimal energy consumption, tasks has to be assigned to the nodes of type for which the difference between energy consumption for the node running the application and in the idle state is minimal. The power usage measured in idle state for three types of nodes is gathered in the Table~\ref{idlePower}.
+
+\begin {table}[h!]
+\centering
+\begin{tabular}{ll}
+\hline
+Type & Power usage in idle state [W]  \\
+\hline
+ Intel i7 & 11,5 \\
+AMD Fusion & 19 \\
+Atom D510  & 10 \\
+\hline
+\end{tabular}
+\caption {\label{idlePower} Measured power of testbed nodes in idle state}
+\end {table}
+
+As mentioned, we assign tasks to nodes minimizing the value of expression: $(P-Pidle)*exec\_time$, where $P$ denotes observed power of the node running the particular application and $exec_time$ refers to the measured application running time. Based on the application and hardware profiles, we expected that Atom D510 would be the preferred node. Obtained scheduled, that is presented in the Gantt chart in Figure~\ref{fig:70eo} along with the energy and system usage, confirmed our assumptions. Atom D510 nodes are nearly fully loaded, while the least energy-favorable AMD nodes are used only when other ones are busy.
 
 \begin{figure}[h!]
@@ -545,12 +557,9 @@
 \end{figure}
 
-\textbf{total energy usage}: 46,305 kWh
-\textbf{mean power consumption}: 311,94 W
-\textbf{workload completion}: 534 400 s
-
-
-The next strategy is similar to the previous one, so making the assignment of task to the node, we still take into consideration application and hardware profiles, but in that case we assume that the system supports possibility of switching off unused nodes. In this case the minimal energy consumption is achieved by assigning the task to the node for which the product of power consumption and time of execution is minimal.
-
-
+This allocation strategy, leads to slight deterioration of makespan criterion, resulting in \textbf{workload completion time} equal to 534 400 s. Nevertheless, the \textbf{total energy usage} is reduced, achieving: 46,305 kWh.
+
+
+The next strategy is similar to the previous one, so making the assignment of task to the node, we still take into consideration application and hardware profiles, but in that case we assume that the system supports possibility of switching off unused nodes. In this case the minimal energy consumption is achieved by assigning the task to the node for which the product of power consumption and time of execution is minimal. In other words we minimized the following expression: "$P*exec\_time$.
+Contrary to the previous strategy, we expected Intel I7 nodes to be allocated first. Generated Gantt chart is compatible with our expectations.
 
 \begin{figure}[h!]
@@ -560,9 +569,9 @@
 \end{figure}
 
-\textbf{total energy usage}: 30,568 kWh
-\textbf{mean power consumption}: 206,15 W
-\textbf{workload completion}: 533 820 s
-
-The last considered by us case is modification of the one of previous strategies taking into account the energy-efficiency of nodes. We assume that tasks do not have deadlines and the only criterion which is taken into consideration is the total energy consumption. All the considered workloads have been executed on the testbed configured for three different possible frequencies of CPUs â the lowest, medium and the highest one. The experiment was intended to check if the benefit of running the workload on less power-consuming frequency of CPU is not leveled by the prolonged time of execution of the workload.
+Estimated \textbf{total energy usage} of the system is 30,568 kWh. As we can see, this approach significantly improved the value of this criterion, comparing to all of the previous policies. Moreover, the proposed allocation strategy does not worsen the \textbf{workload completion time} criterion, where the resulting value is equal to 533 820 s.
+
+\subsubsection{Frequency scaling}
+
+The last considered by us case is modification of the random strategy. We assume that tasks do not have deadlines and the only criterion which is taken into consideration is the total energy consumption. All the considered workloads have been executed on the testbed configured for three different possible frequencies of CPUs â the lowest, medium and the highest one. The experiment was intended to check if the benefit of running the workload on less power-consuming frequency of CPU is not leveled by the prolonged time of execution of the workload.
 
 
@@ -574,10 +583,42 @@
 
 \textbf{total energy usage}: 77,108 kWh
-\textbf{mean power consumption}: 260,57 W
-\textbf{workload completion}: 1 065 356 s
+\textbf{workload completion time}: 1 065 356 s
 
 
 ....
 
+
+\begin {table}[h!]
+\centering
+\begin{tabular}{l|lllll}
+\hline
+&  \multicolumn{5}{c}{Strategy}\\
+Load  & R & R + NPM & EO & EO + NPM & DFS\\
+\hline
+10\% & 241,337 &	37,811 & 239,667 & 25,571 & 239,278 \\
+30\% &89,853 & 38,059 & 88,823 & 25,595.94	 & 90,545 \\
+50\% &59,112 & 36,797 & 58,524 & 26,328	& 76,020 \\
+70\% &46,883 & 36,705 & 46,3062 & 30,568 & 77,109 \\
+\hline
+\end{tabular}
+\caption {\label{loadEnergy} Energy usage [kWh] for different level of system load}
+\end {table}
+
+\begin {table}[h!]
+\centering
+\begin{tabular}{l|lllll}
+\hline
+&  \multicolumn{5}{c}{Strategy}\\
+Load  & R & R + NPM & EO & EO + NPM & DFS\\
+\hline
+10\% & 3 605 428 & 3 605 428 & 3 605 428 & 3 605 428 & 3 622 968 \\
+30\% & 1 214 464 & 1 214 464 & 1 215 044 & 1 200 807 & 1 275 093 \\
+50\% &729 066& 729 066 & 731 126& 721 617	& 1 049 485\\
+70\% & 533 820 & 533 820 & 534 400 & 533 820 & 1 065 356\\
+\hline
+\end{tabular}
+\caption {\label{loadMakespan} Makespan [s] for different level of system load}
+\end {table}
+
 \section{DCWoRMS application/use cases}\label{sec:coolemall}
 
@@ -586,9 +627,9 @@
 ...
 
-Being based on the GSSIM framework, that has been successfully applied in a substantial number of research projects and academic studies, DCWoRMS with its sophisticated energy extension has become an essential tool for studies of energy efficiency in distributed environments. For this reason, it has been adopted within the CoolEmAll project as a component of Simulation, Visualisation and Decission Support (SVD) Toolkit. In general the main goal of CoolEmAll is to provide advanced simulation, visualisation and decision support tools along with blueprints of computing building blocks for modular data centre environments. Once developed, these tools and blueprints should help to minimise the energy consumption, and consequently the CO2 emissions of the whole IT infrastructure with related facilities. The SVD Toolkit is designed to support the analysis and optimization of IT modern infrastructures. For the recent years the special attention has been paid for energy utilized by the data centers which considerable contributes to the data center operational costs.  Actual power usage and effectiveness of energy saving methods heavily depends on available resources, types of applications and workload properties. Therefore, intelligent resource management policies are gaining popularity when considering the energy efficiency of IT infrastructures.
+Being based on the GSSIM framework, that has been successfully applied in a substantial number of research projects and academic studies, DCWoRMS with its sophisticated energy extension has become an essential tool for studies of energy efficiency in distributed environments. For this reason, it has been adopted within the CoolEmAll project as a component of Simulation, Visualisation and Decision Support (SVD) Toolkit. In general the main goal of CoolEmAll is to provide advanced simulation, visualisation and decision support tools along with blueprints of computing building blocks for modular data centre environments. Once developed, these tools and blueprints should help to minimise the energy consumption, and consequently the CO2 emissions of the whole IT infrastructure with related facilities. The SVD Toolkit is designed to support the analysis and optimization of IT modern infrastructures. For the recent years the special attention has been paid for energy utilized by the data centers which considerable contributes to the data center operational costs.  Actual power usage and effectiveness of energy saving methods heavily depends on available resources, types of applications and workload properties. Therefore, intelligent resource management policies are gaining popularity when considering the energy efficiency of IT infrastructures.
 Hence, SVD Toolkit integrates also workload management and scheduling policies to support complex modeling and optimization of modern data centres.
 
 The main aim of DCWoRMS within CoolEmAll project is to enable studies of dynamic states of IT infrastructures, like power consumption and air throughput distribution, on the basis of changing workloads, resource model and energy-aware resource management policies.
-In this context, DCWoRMS takes into account the specific workload and application characteristics as well as detailed resource parameters. It will benefit from the CoolEmAll benchmarks and classification of applications and workloads. In particular various types of workload, including data centre workloads using virtualization and HPC applications, may be considered. The knowledge concerning their performance and properties as well as information about their energy consumption and heat production will be used in simulations to study their impact on thermal issues and energy efficiency. Detailed resource characteristics, will be also provided according to the CoolEmAll blueprints. Based on this data, workload simulation will support evaluation process of various resource management approaches. These policies may include a wide spectrum of energy-aware strategies such as workload consolidation/migration, dynamic switching off nodes, Dynamic Voltage and Frequency Scaling (DVFS), and thermal-aware methods. In addition to typical approaches minimizing energy consumption, policies that prevent too high temperatures in the presence of limited cooling (or no cooling) may also be analyzed. Moreover, apart from the set of predefined strategies, new approaches can easily be applied and examined.
+In this context, DCWoRMS takes into account the specific workload and application characteristics as well as detailed resource parameters. It will benefit from the CoolEmAll benchmarks and classification of applications and workloads. In particular various types of workload, including data centre workloads using virtualization and HPC applications, may be considered. The knowledge concerning their performance and properties as well as information about their energy consumption and heat production will be used in simulations to study their impact on thermal issues and energy efficiency. Detailed resource characteristics, will be also provided according to the CoolEmAll blueprints. Based on this data, workload simulation will support evaluation process of various resource management approaches. These policies may include a wide spectrum of energy-aware strategies such as workload consolidation/migration, dynamic switching off nodes, DVFS and thermal-aware methods. In addition to typical approaches minimizing energy consumption, policies that prevent too high temperatures in the presence of limited cooling (or no cooling) may also be analyzed. Moreover, apart from the set of predefined strategies, new approaches can easily be applied and examined.
 The outcome of the workload and resource management simulation phase is a distribution of power usage and air throughput for the computing models specified within the SVD Toolkit. These statistics may be analyzed directly by data centre designers and administrators and/or provided as an input to the CFD simulation phase. The former case allows studying how the above metrics change over time, while the latter harness CFD simulations to identify temperature differences between the computing modules, called hot spots. The goal of this scenario is to visualise the behavior of the temperature distribution within a server room with a number of racks for different types of executed workloads and for various policies used to manage these workloads.
 
