Changeset 1069 for papers

Timestamp:

06/03/13 13:55:25 (12 years ago)

Author:

wojtekp

Message:

 

Location:

papers/SMPaT-2012_DCWoRMS

Files:

• elsarticle-DCWoRMS.aux (modified) (6 diffs)
• elsarticle-DCWoRMS.fdb_latexmk (modified) (2 diffs)
• elsarticle-DCWoRMS.pdf (modified) (previous)
• elsarticle-DCWoRMS.synctex.gz (modified) (previous)
• elsarticle-DCWoRMS.tex (modified) (14 diffs)

papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.aux

@@ -8 +8 @@
 \citation{fit4green}
 \citation{networks}
+\citation{fit4green_carbon_scheduler}
 \citation{sgi}
 \citation{colt}
 \citation{ecocooling}
+\citation{SimGrid}
 \citation{ff}
 \citation{DCD_Romonet}
@@ -24 +26 @@
 \@writefile{toc}{\contentsline {section}{\numberline {3}DCworms}{5}}
 \citation{GSSIM}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces  DCworms architecture}}{6}}
+\newlabel{fig:arch}{{1}{6}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Architecture}{6}}
 \citation{GWF}
 \citation{SLURM}
 \citation{TORQUE}
-\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces  DCworms architecture}}{6}}
-\newlabel{fig:arch}{{1}{6}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Architecture}{6}}
 \citation{Ghislain}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Workload modeling}{7}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Resource modeling}{7}}
 \@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces  Levels of information about jobs}}{8}}
 \newlabel{fig:jobsStructure}{{2}{8}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Resource modeling}{8}}
 \citation{d2.2}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Energy management concept in DCworms}{9}}
 \citation{GSSIM_Energy}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Energy management concept in DCworms}{9}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {3.4.1}Power management}{10}}
 \@writefile{toc}{\contentsline {paragraph}{\textbf  {Power profile}}{10}}
@@ -46 +48 @@
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.5}Application performance modeling}{11}}
 \newlabel{sec:apps}{{3.5}{11}}
+\citation{GSSIM}
 \citation{e2dc13}
 \citation{d2.2}
@@ -54 +57 @@
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Power consumption models}{13}}
 \newlabel{sec:power}{{4.1}{13}}
-\newlabel{eq:ohm-law}{{2}{13}}
 \@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces  Power in time for the highest frequency}}{14}}
 \newlabel{fig:fans_P}{{5}{14}}
+\newlabel{eq:ohm-law}{{2}{14}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Static approach}{14}}
-\newlabel{eq:static}{{3}{14}}
 \citation{fit4green_scheduler}
+\newlabel{eq:static}{{3}{15}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Resource load}{15}}
 \newlabel{eq:dynamic}{{4}{15}}
 \newlabel{eq:model}{{7}{16}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Application specific}{16}}
-\newlabel{eq:app}{{8}{16}}
 \citation{e2dc12}
 \citation{abinit}
-\citation{cray}
+\newlabel{eq:app}{{8}{17}}
 \@writefile{toc}{\contentsline {section}{\numberline {5}Experiments and evaluation}{17}}
 \newlabel{sec:experiments}{{5}{17}}
@@ -73 +75 @@
 \@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces  RECS system configuration}}{17}}
 \newlabel{testBed}{{1}{17}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Evaluated applications}{17}}
+\citation{cray}
 \citation{linpack}
 \citation{tar}
 \citation{fft}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Models}{18}}
-\newlabel{sec:models}{{5.3}{18}}
-\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces  $P_{cpubase}$ values in Watts}}{18}}
-\newlabel{nodeBasePowerUsage}{{2}{18}}
-\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces  $P_{app}$ values in Watts}}{19}}
-\newlabel{appPowerUsage}{{3}{19}}
-\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces  Power models error in \%}}{19}}
-\newlabel{expPowerModels}{{4}{19}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Methodology}{19}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.5}Computational analysis}{20}}
-\@writefile{lot}{\contentsline {table}{\numberline {5}{\ignorespaces  Workload characteristics}}{21}}
-\newlabel{workloadCharacteristics}{{5}{21}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Evaluated applications}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Methodology}{18}}
+\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces  Workload characteristics}}{19}}
+\newlabel{workloadCharacteristics}{{2}{19}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Models}{20}}
+\newlabel{sec:models}{{5.4}{20}}
+\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces  $P_{cpubase}$ values in Watts}}{20}}
+\newlabel{nodeBasePowerUsage}{{3}{20}}
+\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces  $P_{app}$ values in Watts}}{20}}
+\newlabel{appPowerUsage}{{4}{20}}
+\@writefile{lot}{\contentsline {table}{\numberline {5}{\ignorespaces  Power models error in \%}}{21}}
+\newlabel{expPowerModels}{{5}{21}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.5}Resource management policies evaluation}{21}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {5.5.1}Random approach}{21}}
 \@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces  Comparison of energy usage for Random (left) and Random + switching off unused nodes strategy (right)}}{22}}
 \newlabel{fig:70r_rnpm}{{6}{22}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {5.5.2}Energy optimization}{22}}
-\@writefile{lot}{\contentsline {table}{\numberline {6}{\ignorespaces  Measured power of testbed nodes in idle state}}{22}}
-\newlabel{idlePower}{{6}{22}}
+\@writefile{lot}{\contentsline {table}{\numberline {6}{\ignorespaces  Measured power of testbed nodes in idle state}}{23}}
+\newlabel{idlePower}{{6}{23}}
 \@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces  Energy usage optimization strategy}}{23}}
 \newlabel{fig:70eo}{{7}{23}}
@@ -102 +105 @@
 \@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces  Frequency downgrading strategy}}{25}}
 \newlabel{fig:70dfs}{{9}{25}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.6}Discussion}{25}}
 \@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces  Schedules obtained for Random strategy (left) and Random + lowest frequency strategy (right) for 10\% of system load}}{26}}
 \newlabel{fig:dfsComp}{{10}{26}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.5.4}Summary}{26}}
 \@writefile{lot}{\contentsline {table}{\numberline {7}{\ignorespaces  Energy usage [kWh] for different level of system load. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, R+LF - Random + lowest frequency}}{26}}
 \newlabel{loadEnergy}{{7}{26}}
-\@writefile{lot}{\contentsline {table}{\numberline {8}{\ignorespaces  Makespan [s] for different level of system load. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, R+LF - Random + lowest frequency}}{26}}
-\newlabel{loadMakespan}{{8}{26}}
-\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusions and future work}{27}}
+\@writefile{lot}{\contentsline {table}{\numberline {8}{\ignorespaces  Makespan [s] for different level of system load. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, R+LF - Random + lowest frequency}}{27}}
+\newlabel{loadMakespan}{{8}{27}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.6}Verification of models}{27}}
+\newlabel{eq:modelLoad}{{9}{28}}
+\@writefile{lot}{\contentsline {table}{\numberline {9}{\ignorespaces  Comparison of energy usage estimations [kWh] obtained for two power consumption models. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, R+LF - Random + lowest frequency}}{28}}
+\newlabel{modelAccuracy}{{9}{28}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusions and future work}{28}}
 \bibcite{fit4green}{{1}{}{{}}{{}}}
 \bibcite{e2dc13}{{2}{}{{}}{{}}}
 \bibcite{e2dc12}{{3}{}{{}}{{}}}
 \bibcite{CloudSim}{{4}{}{{}}{{}}}
-\newlabel{}{{6}{28}}
 \bibcite{DCSG}{{5}{}{{}}{{}}}
-\bibcite{DCD_Romonet}{{6}{}{{}}{{}}}
-\bibcite{networks}{{7}{}{{}}{{}}}
-\bibcite{Ghislain}{{8}{}{{}}{{}}}
-\bibcite{games}{{9}{}{{}}{{}}}
-\bibcite{GreenCloud}{{10}{}{{}}{{}}}
-\bibcite{GSSIM}{{11}{}{{}}{{}}}
-\bibcite{GSSIM_Energy}{{12}{}{{}}{{}}}
-\bibcite{koomey}{{13}{}{{}}{{}}}
-\bibcite{fit4green_scheduler}{{14}{}{{}}{{}}}
-\bibcite{d2.2}{{15}{}{{}}{{}}}
-\bibcite{abinit}{{16}{}{{}}{{}}}
-\bibcite{cray}{{17}{}{{}}{{}}}
-\bibcite{fft}{{18}{}{{}}{{}}}
-\bibcite{linpack}{{19}{}{{}}{{}}}
-\bibcite{tar}{{20}{}{{}}{{}}}
-\bibcite{GWF}{{21}{}{{}}{{}}}
-\bibcite{SLURM}{{22}{}{{}}{{}}}
-\bibcite{SWF}{{23}{}{{}}{{}}}
-\bibcite{TORQUE}{{24}{}{{}}{{}}}
-\bibcite{colt}{{25}{}{{}}{{}}}
-\bibcite{coolemall}{{26}{}{{}}{{}}}
-\bibcite{ecocooling}{{27}{}{{}}{{}}}
-\bibcite{ff}{{28}{}{{}}{{}}}
-\bibcite{pue}{{29}{}{{}}{{}}}
-\bibcite{sgi}{{30}{}{{}}{{}}}
+\bibcite{SimGrid}{{6}{}{{}}{{}}}
+\bibcite{DCD_Romonet}{{7}{}{{}}{{}}}
+\bibcite{networks}{{8}{}{{}}{{}}}
+\bibcite{Ghislain}{{9}{}{{}}{{}}}
+\newlabel{}{{6}{30}}
+\bibcite{games}{{10}{}{{}}{{}}}
+\bibcite{GreenCloud}{{11}{}{{}}{{}}}
+\bibcite{GSSIM}{{12}{}{{}}{{}}}
+\bibcite{GSSIM_Energy}{{13}{}{{}}{{}}}
+\bibcite{koomey}{{14}{}{{}}{{}}}
+\bibcite{fit4green_scheduler}{{15}{}{{}}{{}}}
+\bibcite{fit4green_carbon_scheduler}{{16}{}{{}}{{}}}
+\bibcite{d2.2}{{17}{}{{}}{{}}}
+\bibcite{abinit}{{18}{}{{}}{{}}}
+\bibcite{cray}{{19}{}{{}}{{}}}
+\bibcite{fft}{{20}{}{{}}{{}}}
+\bibcite{linpack}{{21}{}{{}}{{}}}
+\bibcite{tar}{{22}{}{{}}{{}}}
+\bibcite{GWF}{{23}{}{{}}{{}}}
+\bibcite{SLURM}{{24}{}{{}}{{}}}
+\bibcite{SWF}{{25}{}{{}}{{}}}
+\bibcite{TORQUE}{{26}{}{{}}{{}}}
+\bibcite{colt}{{27}{}{{}}{{}}}
+\bibcite{coolemall}{{28}{}{{}}{{}}}
+\bibcite{ecocooling}{{29}{}{{}}{{}}}
+\bibcite{ff}{{30}{}{{}}{{}}}
+\bibcite{pue}{{31}{}{{}}{{}}}
+\bibcite{sgi}{{32}{}{{}}{{}}}
 \providecommand\NAT@force@numbers{}\NAT@force@numbers

papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.fdb_latexmk

@@ -1 +1 @@
 # Fdb version 2
-["pdflatex"] 1370008374 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
+["pdflatex"] 1370260512 "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 +30 @@
   "/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" 1370008377 7677 f71d3a69833156dd0cd55997caa941bf ""
-  "elsarticle-DCWoRMS.spl" 1370008375 0 d41d8cd98f00b204e9800998ecf8427e ""
-  "elsarticle-DCWoRMS.tex" 1370007766 81944 a4f37cdda6dc074fed8954549930ec15 ""
+  "elsarticle-DCWoRMS.aux" 1370260514 8344 4fae76ffb960809b0662b0a5380c1cf5 ""
+  "elsarticle-DCWoRMS.spl" 1370260512 0 d41d8cd98f00b204e9800998ecf8427e ""
+  "elsarticle-DCWoRMS.tex" 1370260508 86035 d15304aaf50305115c88a8a70ebe8af4 ""
   "elsarticle.cls" 1352447924 26095 ad44f4892f75e6e05dca57a3581f78d1 ""
   "fig/70dfsGantt.png" 1370005142 138858 edc557d8862a7825f2941d8c69c30659 ""

papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex

@@ -174 +174 @@
 %Furthermore, available power supply is usually limited so it also may reduce data center development capabilities, especially looking at challenges related to exascale computing breakthrough foreseen within this decade.
 
-For these reasons many efforts were undertaken to measure and study energy efficiency of data centers. There are projects focused on data center monitoring and management \cite{games}\cite{fit4green} whereas others on  energy efficiency of networks \cite{networks}. Additionally, vendors offer a wide spectrum of energy efficient solutions for computing and cooling \cite{sgi}\cite{colt}\cite{ecocooling}. However, a variety of solutions and configuration options can be applied planning new or upgrading existing data centers.
+For these reasons many efforts were undertaken to measure and study energy efficiency of data centers. There are projects focused on data center monitoring and management \cite{games}\cite{fit4green} whereas others on  energy efficiency of networks \cite{networks} or distributed computing infrastructures, like grids \cite{fit4green_carbon_scheduler}. Additionally, vendors offer a wide spectrum of energy efficient solutions for computing and cooling \cite{sgi}\cite{colt}\cite{ecocooling}. However, a variety of solutions and configuration options can be applied planning new or upgrading existing data centers.
 In order to optimize a design or configuration of data center we need a thorough study using appropriate metrics and tools evaluating how much computation or data processing  can be done within given power and energy budget and how it affects temperatures, heat transfers, and airflows within data center. 
 Therefore, there is a need for simulation tools and models that approach the problem from a perspective of end users and take into account all the factors that are critical to understanding and improving the energy efficiency of data centers, in particular, hardware characteristics, applications, management policies, and cooling.
 These tools should support data center designers and operators by answering questions how specific application types, levels of load, hardware specifications, physical arrangements, cooling technology, etc. impact overall data center energy efficiency. 
-There are various tools that allow simulation of computing infrastructures. On one hand they include advanced packages for modeling heat transfer and energy consumption in data centers \cite{ff} or tools concentrating on their financial analysis \cite{DCD_Romonet}. On the other hand, there are simulators focusing on computations such as CloudSim \cite{CloudSim}. The CoolEmAll project aims to integrate these approaches and enable advanced analysis of data center efficiency taking into account all these aspects \cite{e2dc12}\cite{coolemall}.
+There are various tools that allow simulation of computing infrastructures, like SimGrid\cite{SimGrid}. On one hand they include advanced packages for modeling heat transfer and energy consumption in data centers \cite{ff} or tools concentrating on their financial analysis \cite{DCD_Romonet}. On the other hand, there are simulators focusing on computations such as CloudSim \cite{CloudSim}. The CoolEmAll project aims to integrate these approaches and enable advanced analysis of data center efficiency taking into account all these aspects \cite{e2dc12}\cite{coolemall}.
 
 One of the results of the CoolEmAll project is the Data Center Workload and Resource Management Simulator (DCworms) which enables modeling and simulation of computing infrastructures to estimate their performance, energy consumption, and energy-efficiency metrics for diverse workloads and management policies.
@@ -200 +200 @@
 In terms of application modeling, all tools, except DCSG Simulator, describe the application with a number of computational and communicational requirements. In addition, GreenCloud and DCworms allow introducing the QoS requirements by taking into account the time constraints during the simulation. DCSG Simulator instead of modeling of the single application, enables the definition of workload that leads to a given utilization level. However, only DCworms supports application performance modeling by not only incorporating simple requirements that are taken into account during scheduling, but also by allowing specification of task execution time.
 
-GreenCloud, CloudSim and DCworms are released as Open Source under the GPL. DCSG Simulator is available under an OSL V3.0 open-source license, however, it can be only accessed by the DCSG members.
+GreenCloud, CloudSim and DCworms are released as Open Source under the GPL. DCSG Simulator is available under the OSL V3.0 open-source license, however, it can be only accessed by the DCSG members.
 
 Summarizing, DCworms stands out from other tools due to the flexibility in terms of data center equipment and structure definition.
@@ -210 +210 @@
 
 Data Center workload and resource management simulator (DCworms) is a simulation tool based on the GSSIM framework \cite{GSSIM} developed by Poznan Supercomputing and Networking Center (PSNC).
-GSSIM has been proposed to provide an automated tool for experimental studies of various resource management and scheduling strategies in distributed computing systems. DCworms extends its basic functionality and adds some additional features related to the energy efficiency issues in data centers. In this section we will introduce the functionality of the simulator, in terms of modeling and simulation of large scale distributed systems like Grids and Clouds.
+GSSIM has been proposed to provide an automated tool for experimental studies of various resource management and scheduling strategies in distributed computing systems. DCworms extends its basic functionality and adds some additional features related to the energy efficiency issues in data centers. In this section we will introduce the functionality of the simulator, in terms of modeling and simulation of data centers.
 
 
@@ -222 +222 @@
 \end{figure}
 
-DCworms is an event-driven simulation tool written in Java. In general, input data for the DCworms consist of workload and resources descriptions. They can be provided by the user, read from real traces or generated using the generator module. In this terms DCworms benefits from the GSSIM workload generator tool that allows creating synthetic workloads (\cite{GSSIM}). However, the key elements of the presented architecture are plugins. They allow the researchers to configure and adapt the simulation environment to the peculiarities of their studies, starting from modeling job performance, through energy estimations up to implementation of resource management and scheduling policies. Each plugin can be implemented independently and plugged into a specific experiment. Results of experiments are collected, aggregated, and visualized using the statistics module. Due to a modular and plug-able architecture DCworms can be applied to specific resource management problems and address different users’ requirements.
+DCworms is an event-driven simulation tool written in Java. In general, input data for the DCworms consist of workload and resource descriptions. They can be provided by the user, read from real traces or generated using the generator module. In this terms DCworms benefits from the GSSIM workload generator tool that allows creating synthetic workloads (\cite{GSSIM}). However, the key elements of the presented architecture are plugins. They allow the researchers to configure and adapt the simulation environment to the peculiarities of their studies, starting from modeling job performance, through energy estimations up to implementation of resource management and scheduling policies. Each plugin can be implemented independently and plugged into a specific experiment. Afterwards, politics introduced by particular plugins are applied to a given set of tasks and resources and are triggered by each change of simulated environment state. Results of experiments are collected, aggregated, and visualized using the statistics module. The output of each simulation consists of a number of statistics created to help in
+comparative evaluations of resource and workload management policies. Due to a modular and plug-able architecture DCworms can be applied to specific resource management problems and address different users’ requirements.
 
 
@@ -333 +334 @@
   \item network parameters
 \end{itemize}
-Using these parameters developers can for instance take into account the architectures of the underlying systems, such as multi-core processors, and their impact on the final performance of applications.
+Using these parameters developers can for instance take into account the architectures of the underlying systems, such as multi-core processors, and their impact on the final performance of applications. Examples of application performance modeling in DCworms are shown in \cite{GSSIM}.
 
 
@@ -339 +340 @@
 \section{Modeling of energy consumption in DCworms}
 
-DCworms is an open framework in which various models and algorithms can be investigated as presented in Section \ref{sec:apps}. In this section, we discuss possible approaches to modeling that can be applied to simulation of energy-efficiency of distributed computing systems. In general, to facilitate the simulation process, DCworms provides some basic implementation of power consumption, air throughput and thermal models. We introduce power consumption models as examples and validate part of them by experiments in real computing system (in Section \ref{sec:experiments}).  Description of thermal models and corresponding experiments was presented in \cite{e2dc13}.
+DCworms is an open framework in which various models and algorithms can be investigated as presented in Section \ref{sec:apps}. In this section, we discuss possible approaches to modeling that can be applied to simulation of energy-efficiency of distributed computing systems. In general, to facilitate the simulation process, DCworms provides some basic implementation of power consumption, air throughput and thermal models. We introduce power consumption models as examples and validate part of them by experiments in real computing system (in Section \ref{sec:experiments}). Description of thermal models and corresponding experiments was presented in \cite{e2dc13}.
 
 The most common questions explored by researchers who study energy-efficiency of distributed computing systems is how much energy $E$ do these systems require to execute workloads. In order to obtain this value the simulator must calculate values of power $P_i(t)$ and load $L_i(t)$ in time for all $m$ computing nodes, $i=1..m$. Load function may depend on specific load models applied. In more complex cases it can even be defined as vectors of different resource usage in time. In a simple case load can be either idle or busy but even in this case estimation of job processing times $p_j$ is needed to calculate total energy consumption. The total energy consumption of computing nodes is given by (\ref{eq:E}):
@@ -513 +514 @@
 
 
-\subsection{Models}\label{sec:models}
-
-Based on the measured values we evaluated three types of models that can be applied, among others, to the simulation environment.
-
-\textbf{Static}
-This model refers to the static approach presented in Section~\ref{sec:power}. According to the measured values we created a resource power consumption model that is based on a static definition of resource power usage. 
-%With each node power state, understood as a possible operating state (p-state), we associated a power consumption value that derives from the averaged values of measurements obtained for different types of application. Therefore, the current power usage of the node, can be expressed as: $P = P_{idle} + P_{f}$ where $P$ denotes power consumed by the node, $P_{idle}$ is a power usage of node in idle state and $P_{f}$ stands for power usage of CPU operating at the given frequency level.
-
-\textbf{Dynamic}
-This model refers to the Resource load approach presented in Section~\ref{sec:power}. Based on the measured values of the total node power usage for various levels of load and frequencies of CPUs node power usage was defined as in \ref{eq:model}.
-
-%and referring to the existing models presented in literature, we assumed the following equation: $P = P_{idle} + load*P_{cpubase}*c^{(f-f_{base})/100} + P_{app}$, where $P$ denotes power consumed by the node executing the given application, $P_{idle}$ is a power usage of node in idle state, load is the current utilization level of the node, $P_{cpubase}$ stands for power usage of fully loaded CPU working in the lowest frequency, $c$ is the constant factor indicating the increase of power consumption with respect to the frequency increase $f$- is a current frequency, $f_{base}$- is the lowest available frequency within the given CPU and $P_{app}$ denotes the additional power usage derived from executing a particular application).
-
-
-Table~\ref{nodeBasePowerUsage} and Table~\ref{appPowerUsage} contain values of $P_{cpubase}$ and $P_{app}$, respectively, obtained for the particular application and resource architectures. Lack of the corresponding value means that the application did not run on the given type of node.
-\begin {table}[h!]
-\centering
-\begin{tabular}{lccc}
-\hline
-Intel I7 & AMD Fusion  & Atom D510  \\
-\hline
- 8 & 2 & 1 \\
-\hline
-\end{tabular}
-\caption {\label{nodeBasePowerUsage} $P_{cpubase}$ values in Watts}
-\end {table}
-
-
-\begin {table}[h!]
-\centering
-\begin{tabular}{l|ccc}
-\hline
- & \multicolumn{3}{c} {Node type}\\ 
-Application & Intel I7 & AMD Fusion  & Atom D510  \\
-\hline
-Abinit & 3.3 &  - &  - \\
-Linpactiny & 2.5 & - & 0.2 \\
-Linpack3gb &  6 &  -  & -  \\
-C-Ray & 4 & 1 & 0.05 \\
-FFT & 3.5 & 2 & 0.1 \\
-Tar & 3 & 2.5 & 0.5 \\
-
-\hline
-\end{tabular}
-\caption {\label{appPowerUsage} $P_{app}$ values in Watts}
-\end {table}
-
-
-\textbf{Mapping}
-This model refers to the Application specific approach presented in Section~\ref{sec:power}. However, in this model we applied the measured values for each application exactly to the power model. Neither dependencies with load nor application profiles are modeled. Obviously this model is contaminated only with the inaccuracy of the measurements and variability of power usage (caused by other unmeasured factors).
-        
-The following table (Table~\ref{expPowerModels}) contains the relative errors of the models with respect to the measured values
-\begin {table}[h!]
-\centering
-\begin{tabular}{llr}
-\hline
-Static & Dynamic  & Mapping \\
-\hline
-13.74 & 10.85 & 0 \\
-\hline
-\end{tabular}
-\caption {\label{expPowerModels} Power models error in \%}
-\end {table}
-
-Obviously, 0\% error in the case of the Mapping model is caused by the use of a tabular data, which for each application stores a specific power usage. Nevertheless, in all models we face possible deviations from the average caused by power usage fluctuations not explained by variables used in models. These deviations reached around 7\% for each case.
-
-For the experimental purposes we decided to use the latter model. Thus, we introduce into the simulation environment exact values obtained within our testbed, to build both the power profiles of applications as well as the application performance models, denoting their execution times.
-
 
 \subsection{Methodology}
@@ -622 +555 @@
 In all cases we assumed that tasks are scheduled and served in order of their arrival (FIFO strategy) using relaxed backfilling approach, with indefinite delay for the highest priority task. Moreover, all tasks were assigned to nodes with the condition that they can be assigned only to nodes of the type on which the application was able to run (in other words - we had the corresponding value of power consumption and execution time). 
 
-\subsection{Computational analysis}
+
+\subsection{Models}\label{sec:models}
+
+Based on the measured values we evaluated three types of models that can be applied, among others, to the simulation environment.
+
+\textbf{Static}
+This model refers to the static approach presented in Section~\ref{sec:power}. According to the measured values we created a resource power consumption model that is based on a static definition of resource power usage. 
+%With each node power state, understood as a possible operating state (p-state), we associated a power consumption value that derives from the averaged values of measurements obtained for different types of application. Therefore, the current power usage of the node, can be expressed as: $P = P_{idle} + P_{f}$ where $P$ denotes power consumed by the node, $P_{idle}$ is a power usage of node in idle state and $P_{f}$ stands for power usage of CPU operating at the given frequency level.
+
+\textbf{Dynamic}
+This model refers to the Resource load approach presented in Section~\ref{sec:power}. Based on the measured values of the total node power usage for various levels of load and frequencies of CPUs node power usage was defined as in \ref{eq:model}.
+
+%and referring to the existing models presented in literature, we assumed the following equation: $P = P_{idle} + load*P_{cpubase}*c^{(f-f_{base})/100} + P_{app}$, where $P$ denotes power consumed by the node executing the given application, $P_{idle}$ is a power usage of node in idle state, load is the current utilization level of the node, $P_{cpubase}$ stands for power usage of fully loaded CPU working in the lowest frequency, $c$ is the constant factor indicating the increase of power consumption with respect to the frequency increase $f$- is a current frequency, $f_{base}$- is the lowest available frequency within the given CPU and $P_{app}$ denotes the additional power usage derived from executing a particular application).
+
+
+Table~\ref{nodeBasePowerUsage} and Table~\ref{appPowerUsage} contain values of $P_{cpubase}$ and $P_{app}$, respectively, obtained for the particular application and resource architectures. Lack of the corresponding value means that the application did not run on the given type of node.
+\begin {table}[h!]
+\centering
+\begin{tabular}{lccc}
+\hline
+Intel I7 & AMD Fusion  & Atom D510  \\
+\hline
+ 8 & 2 & 1 \\
+\hline
+\end{tabular}
+\caption {\label{nodeBasePowerUsage} $P_{cpubase}$ values in Watts}
+\end {table}
+
+
+\begin {table}[h!]
+\centering
+\begin{tabular}{l|ccc}
+\hline
+ & \multicolumn{3}{c} {Node type}\\ 
+Application & Intel I7 & AMD Fusion  & Atom D510  \\
+\hline
+Abinit & 3.3 &  - &  - \\
+Linpactiny & 2.5 & - & 0.2 \\
+Linpack3gb &  6 &  -  & -  \\
+C-Ray & 4 & 1 & 0.05 \\
+FFT & 3.5 & 2 & 0.1 \\
+Tar & 3 & 2.5 & 0.5 \\
+
+\hline
+\end{tabular}
+\caption {\label{appPowerUsage} $P_{app}$ values in Watts}
+\end {table}
+
+
+\textbf{Mapping}
+This model refers to the Application specific approach presented in Section~\ref{sec:power}. However, in this model we applied the measured values for each application exactly to the power model. Neither dependencies with load nor application profiles are modeled. Obviously this model is contaminated only with the inaccuracy of the measurements and variability of power usage (caused by other unmeasured factors).
+        
+The following table (Table~\ref{expPowerModels}) contains the relative errors of the models with respect to the measured values
+\begin {table}[h!]
+\centering
+\begin{tabular}{llr}
+\hline
+Static & Dynamic  & Mapping \\
+\hline
+13.74 & 10.85 & 0 \\
+\hline
+\end{tabular}
+\caption {\label{expPowerModels} Power models error in \%}
+\end {table}
+
+Obviously, 0\% error in the case of the Mapping model is caused by the use of a tabular data, which for each application stores a specific power usage. Nevertheless, in all models we face possible deviations from the average caused by power usage fluctuations not explained by variables used in models. These deviations reached around 7\% for each case.
+
+For the experimental purposes we decided to use the latter model. Thus, we introduce into the simulation environment exact values obtained within our testbed, to build both the power profiles of applications as well as the application performance models, denoting their execution times.
+
+
+
+\subsection{Resource management policies evaluation}
 
 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). These evaluation criteria employed in our experiments represent interests of various groups of stakeholders present in data centers.
@@ -665 +669 @@
 Type of processor within the node & Power usage in idle state [W]  \\
 \hline
- Intel i7 & 11.5 \\
+Intel i7 & 11.5 \\
 AMD Fusion & 10 \\
 Atom D510  & 19 \\
@@ -706 +710 @@
 
 
-As we were looking for the trade-off between total completion time and energy usage, we were searching for the workload load level that can benefit from the lower system performance in terms of energy-efficiency. For the frequency downgrading policy, we noticed the improvement on the energy usage criterion only for the workload resulting in 10\% system load. For this threshold we observed that slowdown in task execution does not affect the subsequent tasks in the system and thus the total completion time of the whole workload.
+As we were looking for the trade-off between total completion time and energy usage, we were searching for the workload load level that can benefit from the lower system performance in terms of energy-efficiency. For the frequency downgrading policy, we noticed the improvement on the energy usage criterion only for the workload resulting in 10\% system load. For this threshold we observed that slowdown in task execution does not affect the subsequent tasks in the system and thus the total completion time of the whole workload. In general, for the low loaded systems, where the longer execution times do not affect the computations of subsequent tasks, downgrading the frequency can reduce the overall energy consumption. However, for the more loaded systems, which are typical for HPC centers, and taking into account that idle nodes can be turned off after all, both the simulation results as well as the measurements obtained on real hardware show that the best way to save energy is to perform computations at the maximum frequency level. Due to the shorter execution times, idle nodes can be turned off sooner which results in lower energy usage.
         
 Figure~\ref{fig:dfsComp} shows schedules obtained for Random and Random + lowest frequency strategy. 
@@ -717 +721 @@
 \end{figure}
 
-\subsection{Discussion}
+\subsubsection{Summary}
 The following tables: Table~\ref{loadEnergy} and Table~\ref{loadMakespan} contain the values of evaluation criteria (total energy usage and makespan respectively) gathered for all investigated workloads.
 
@@ -756 +760 @@
 We also demonstrated differences between power usage models. They span from rough static approach to accurate application specific models. However, the latter can be difficult or even infeasible to use, as it requires real measurements for specific applications beforehand. This issue can be partially resolved by introducing application profiles and classification, which can deteriorate the accuracy though. This issue is begin studied more deeply within CoolEmAll project. 
 
+\subsection{Verification of models} 
+
+This section contains more detailed comparison of two types of power consumption models that can be applied, among others, within the DCworms. The first one, called Mapping approach, was applied to the experiments in the previous section. As mentioned within this model, the values measured on the CoolEmAll testbed for each application were applied directly to the power consumption model used in DCworms. 
+
+Model evaluated in this section is a modification of the Mapping and Dynamic model by additional modeling of dependencies with the processor load. 
+Within this model, we benefited from the power profiles based on the measurements made on CoolEmAll testbed (and adopted also by the previous model). However, data applied to the simulation environment consisted only of measurements gathered for applications ran in mode resulting in lowest and highest processor load. For all load levels between the given two values we assumed the linear dependency between the load and power consumption. Thus, the power consumption for the given processor load can be expressed using the following equation (\ref{eq:modelLoad}):
+
+\begin{equation}
+P_L = P_{LL} + (L-LL)*(P_{HL}-P_{LL})/(HL-LL), \label{eq:modelLoad}
+\end{equation}
+
+where $L$ is a given processor load, $LL$ is the lowest measured processor load, $HL$ is the highest measured processor load, $P_L$ denotes power consumption for a given processor load, $P_{LL}$ is a power consumption measured for the lowest processor load and $P_{HL}$ stands for power consumption measured for the highest processor load.
+
+\begin {table}[h!]
+\centering
+\begin{tabular}{l| c | c | c }
+\hline
+Policy / Model  & Mapping & Mapping + Dynamic  & Accuracy [\%]\\
+\hline
+R & 46.883 & 44.476 & 94.87 \\
+R+NPM & 30.568 &        28.250 & 92.42 \\
+EO & 77.109 &   75.277 &        97.62\\
+EO+NPM & 46.305 & 44.050 & 95.13\\
+R+LF & 36.705 & 34.298 & 93.44\\
+\hline
+\end{tabular}
+\caption {\label{modelAccuracy} Comparison of energy usage estimations [kWh] obtained for two power consumption models. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, R+LF - Random + lowest frequency}
+\end {table}
+
+As it can be observed the accuracy of the Mapping + Dynamic based model is high and exceeds visibly 90\%. Satisfactory accuracy suggests that applying various power consumption models, while verifying different approaches or in case of lack of detailed measurements, does not lead to deterioration of overall results. This fact confirms also the important role of simulations in the experiments related to the distributed computing systems. 
 
 
@@ -830 +864 @@
 \bibitem{DCSG} http://dcsg.bcs.org/welcome-dcsg-simulator
 
+\bibitem{SimGrid} http://simgrid.gforge.inria.fr/index.html
+
 \bibitem{DCD_Romonet} http://www.datacenterdynamics.com/blogs/ian-bitterlin/it-does-more-it-says-tin\%E2\%80\%A6
 
@@ -852 +888 @@
 \bibitem{fit4green_scheduler} O. M{\"a}mmel{\"a}, M. Majanen, R. Basmadjian, H. De Meer, A. Giesler, W. Homberg, Energy-aware job scheduler for high-performance computing, Computer Science - Research and Development, November 2012, Volume 27, Issue 4, pp 265-275.
 
+\bibitem {fit4green_carbon_scheduler} M. Majanen, O. M{\"a}mmel{\"a}, A. Giesler, Energy and carbon aware scheduling in supercomputing, International Journal on Advances in Intelligent Systems. Vol. 5 (2012) Nr: 3 \& 4, pp. 451 - 469.
+
 \bibitem {d2.2} U. Woessner, E. Volk, G. Gallizo, M. vor dem Berge, G. Da Costa, P. Domagalski, W. Piatek, J-M. Pierson. (2012) D2.2 Design of the CoolEmAll simulation and visualisation environment - CoolEmAll Deliverable, http://coolemall.eu