Changeset 722 for papers/SMPaT-2012_DCWoRMS

Timestamp:

12/30/12 17:29:34 (12 years ago)

Author:

wojtekp

Message:

 

Location:

papers/SMPaT-2012_DCWoRMS

Files:

• elsarticle-DCWoRMS.aux (modified) (1 diff)
• elsarticle-DCWoRMS.fdb_latexmk (modified) (2 diffs)
• elsarticle-DCWoRMS.pdf (modified) (previous)
• elsarticle-DCWoRMS.synctex.gz (modified) (previous)
• elsarticle-DCWoRMS.tex (modified) (7 diffs)

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

@@ -100 +100 @@
 \@writefile{lot}{\contentsline {table}{\numberline {5}{\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, DFS - Dynamic Frequency Scaling}}{28}}
 \newlabel{loadMakespan}{{5}{28}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.4}Summary}{28}}
 \@writefile{toc}{\contentsline {section}{\numberline {6}DCWoRMS application/use cases}{28}}
 \newlabel{sec:coolemall}{{6}{28}}

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

@@ -1 +1 @@
 # Fdb version 2
-["pdflatex"] 1356870621 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
+["pdflatex"] 1356884949 "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" 1356870623 7837 4960583060a2754ef122f8caaf9474c9 ""
-  "elsarticle-DCWoRMS.spl" 1356870621 0 d41d8cd98f00b204e9800998ecf8427e ""
-  "elsarticle-DCWoRMS.tex" 1356870617 66523 d88fbb09e8ee8d9b632ad41e82486d77 ""
+  "elsarticle-DCWoRMS.aux" 1356884952 7917 147f1af66978610ae4a69a8b85a11045 ""
+  "elsarticle-DCWoRMS.spl" 1356884950 0 d41d8cd98f00b204e9800998ecf8427e ""
+  "elsarticle-DCWoRMS.tex" 1356884931 66578 c43af5b87c1fa3a28be089811d01f3e6 ""
   "elsarticle.cls" 1352447924 26095 ad44f4892f75e6e05dca57a3581f78d1 ""
   "fig/70dfs.png" 1356617710 212573 e013d714dd1377384ed7793222210051 ""

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

@@ -419 +419 @@
 TODO - correct, improve, refactor...
 
-In this section, we present computational analysis that were conducted to emphasize the role of modelling and simulation in studying computing systems performance. To this end we evaluate the impact of energy-aware resource management policies on overall energy-efficiency of specific workloads on heterogeneous resources. The following sections contains description of the used system, tested application and the results of simulation experiments conducted for the evaluated strategies.
+In this section, we present computational analysis that were conducted to emphasize the role of modelling and simulation in studying computing systems performance. To this end we evaluate the impact of energy-aware resource management policies on overall energy-efficiency of specific workloads on heterogeneous resources. The following sections contain description of the used system, tested application and the results of simulation experiments conducted for the evaluated strategies.
 
 \subsection{Testbed description}
@@ -446 +446 @@
 
 
-The RECS system was chosen due to its heterogeneous platform with very high density and energy efficiency that has a monitoring and controlling mechanism integrated. The built-in and additional sensors allow to monitor the complete testbed at a very fine granularity level without the negative impact of the computing- and network-resources. 
+The RECS system was chosen due to its heterogeneous platform with very high density and energy efficiency that has a monitoring and controlling mechanism integrated. The built-in and additional sensors allow monitoring the complete testbed at a very fine granularity level without the negative impact of the computing- and network-resources. 
 
 
@@ -457 +457 @@
 \textbf{C-Ray} is a ray-tracing benchmark that stresses floating point performance of a CPU. Our test is configured with the 'scene' file at 16000x9000 resolution.
 
-\textbf{Linpack} benchmark is used to evaluate system floating point performance. It is based on the Gaussian elimination methods that solves a dense N by N system of linear equations.
+\textbf{Linpack} benchmark is used to evaluate system floating point performance. It is based on the Gaussian elimination methods that solve a dense N by N system of linear equations.
 
 \textbf{Tar} it is a widely used data archiving software]. In our tests the task was to create one compressed file of Linux kernel (version 3.4), which is about 2,3 GB size, using bzip2.
@@ -467 +467 @@
 
 Every chosen application / benchmark was executed on each type of node, for all frequencies supported by the CPU and for different levels of parallelization (number of cores). To eliminate the problem with assessing which part of the power consumption comes from which application, in case when more then one application is ran on the node, the queuing system (SLURM) was configured to run jobs in exclusive mode (one job per node). Such configuration is often used for at least dedicated part of HPC resources. The advantage of the exclusive mode scheduling policy consist in that the job gets all the resources of the assigned nodes for optimal parallel performance and applications running on the same node do not influence each other. For every configuration of application, type of node and CPU frequency we measure the average power consumption of the node and the execution time. The aforementioned values  were used to configure the DCWoRMS environment providing energy and time execution models.
-Based on the models obtained for the considered set of resources and applications we evaluated a set of resource management strategies in terms of energy consumption needed to execute three workloads varying in load intensity (10\%, 30\%, 50\%, 70\% ).
+Based on the models obtained for the considered set of resources and applications we evaluated a set of resource management strategies in terms of energy consumption needed to execute three workloads varying in load intensity (10\%, 30\%, 50\%, 70\%).
 To generate a workload we used the DCWoRMS workload generator tool using the following characteristics.
 
@@ -521 +521 @@
 \end{figure}
 
-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. 
+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 primary one in many HPC centers. 
 
 \begin{figure}[h!]
@@ -573 +573 @@
 \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. In this experiment we configured the simulated infrastructure for the lowest possible frequencies of CPUs. 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. The values of the evaluated criteria are as follows: \textbf{workload completion time}: 1 065 356 s and \textbf{total energy usage}: 77,109 kWh. As we can see, for the given load of the system (70\%), the cost of running the workload that require almost twice more time, can not be compensate by the lower power draw.  Moreover, as it can be observed on the charts in Figure~\ref{fig:70dfs} the execution times on the slowest nodes (Atom D510) visibly exceeds the corresponding values on other servers
+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. In this experiment we configured the simulated infrastructure for the lowest possible frequencies of CPUs. 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. The values of the evaluated criteria are as follows: \textbf{workload completion time}: 1 065 356 s and \textbf{total energy usage}: 77,109 kWh. As we can see, for the given load of the system (70\%), the cost of running the workload that requires almost twice more time, can not be compensate by the lower power draw. Moreover, as it can be observed on the charts in Figure~\ref{fig:70dfs} the execution times on the slowest nodes (Atom D510) visibly exceeds the corresponding values on other servers
         
 \begin{figure}[h!]
@@ -628 +628 @@
 \end {table}
 
-One should easily note that gain from switching off unused nodes decreases with the increasing workload density. In general, for the highly loaded system such policy does not find an application due to the cost related to this process and relatively small benefits.
-
-...
+Referring to the Table~\ref{loadEnergy}, one should easily note that gain from switching off unused nodes decreases with the increasing workload density. In general, for the highly loaded system such policy does not find an application due to the cost related to this process and relatively small benefits.
+
+\subsubsection{Summary}
+
 
 \section{DCWoRMS application/use cases}\label{sec:coolemall}