Changeset 715 for papers/SMPaT-2012_DCWoRMS

Timestamp:

12/28/12 09:18:29 (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) (11 diffs)

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

@@ -72 +72 @@
 \newlabel{sec:experiments}{{5}{19}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Testbed description}{19}}
-\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces  CoolEmAll testbed}}{19}}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces  RECS system configuration}}{19}}
 \newlabel{testBed}{{1}{19}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Evaluated applications}{20}}

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

@@ -1 +1 @@
 # Fdb version 2
-["pdflatex"] 1356624973 "elsarticle-DCWoRMS.tex" "elsarticle-DCWoRMS.pdf" "elsarticle-DCWoRMS" 
+["pdflatex"] 1356682580 "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" 1356624975 6549 5bcb9e6ecbbff1bbc0b7632a9afe5a0c ""
-  "elsarticle-DCWoRMS.spl" 1356624973 0 d41d8cd98f00b204e9800998ecf8427e ""
-  "elsarticle-DCWoRMS.tex" 1356624968 61658 ac57cf61190c72ff0b603bc840e62714 ""
+  "elsarticle-DCWoRMS.aux" 1356682582 6557 747cbb517bc749f6757901046991ff0a ""
+  "elsarticle-DCWoRMS.spl" 1356682580 0 d41d8cd98f00b204e9800998ecf8427e ""
+  "elsarticle-DCWoRMS.tex" 1356682576 61620 cec13b82c9efcd249d3e27e2ea804af9 ""
   "elsarticle.cls" 1352447924 26095 ad44f4892f75e6e05dca57a3581f78d1 ""
   "fig/70dfs.png" 1356617710 212573 e013d714dd1377384ed7793222210051 ""

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

@@ -118 +118 @@
 
 In the recent years, the issue of computing infrastructures energy-efficiency has gained great attention. In this paper we present a Data Center Workload and Resource Management Simulator (DCWoRMS) which enables modeling and simulations of computing infrastructures to estimate their performance, energy consumption, and energy-efficiency metrics for diverse workloads and management policies.
-We discuss methods of power usage modeling available in the simulator. To this end, we compare results of simulations to measurements from the real servers. 
-To demonstrate DCWoRMS capabilities we evaluate impact of several resource management policies on overall energy-efficiency of specific workloads on heterogeneous resources.
+We discuss methods of power usage modeling available in the simulator. To this end, we compare the results of simulations to measurements from the real servers. 
+To demonstrate DCWoRMS capabilities we evaluate the impact of several resource management policies on overall energy-efficiency of specific workloads on heterogeneous resources.
 
 \end{abstract}
@@ -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. The experiments were first performed on the CoolEmAll testbed to collect all necessary data and then repeated using DCWoRMS tool. Based on the obtained results we studied the impact of popular energy-aware resource management policies on the energy consumption. 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 contains description of the used system, tested application and the results of simulation experiments conducted for the evaluated strategies.
 
 \subsection{Testbed description}
-
 
 To obtain values of power consumption that could be later used in DCWoRMS environment to build the model and to evaluate resource management policies we ran a set of applications / benchmarks on the physical testbed. For experimental purposes we choose the high-density Resource Efficient Cluster Server (RECS) system. The single RECS unit consists of 18 single CPU modules, each of them can be treated as an individual node of PC class. Configuration of our RECS unit is presented in Table~\ref{testBed}. 
@@ -443 +442 @@
 \hline
 \end{tabular}
-\caption {\label{testBed} CoolEmAll testbed}
+\caption {\label{testBed} RECS system configuration}
 \end {table}
 
@@ -456 +455 @@
 \textbf{Abinit} is a widely-used application for computational physics simulating systems made of electrons and nuclei to be calculated within density functional theory.
 
-\textbf{C-Ray} is a ray-tracing benchmark that stresses floating point performance of a CPU. The test is configured with the 'scene' file at 16000x9000 resolution.
+\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{Tar} it is a widely used data archiving software [tar]. In the tests the task was to create one compressed file of Linux kernel, which is about 2,3GB size, using bzip2.
-
-\textbf{FFTE} benchmark measures the floating-point arithmetic rate of double precision complex one-dimensional Discrete Fourier Transforms of 1-, 2-, and 3-dimensional sequences of length $2^{p} * 3^{q} * 5^{r}$. In our tests only one core was used to run the application
-
+\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.
+
+\textbf{FFTE} benchmark measures the floating-point arithmetic rate of double precision complex one-dimensional Discrete Fourier Transforms of 1-, 2-, and 3-dimensional sequences of length $2^{p} * 3^{q} * 5^{r}$. In our tests only one core was used to run the application.
 
 
 \subsection{Methodology}
 
-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.
+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\% ).
-To generate a workload we benefited from the DCWoRMS workload generator tool using the following characteristics.
+To generate a workload we used the DCWoRMS workload generator tool using the following characteristics.
 
 \begin {table}[ tp]
@@ -495 +493 @@
  & \multicolumn{4}{c}{C-Ray} & uniform - 20\%\\
  & \multicolumn{4}{c}{Tar} & uniform - 20\%\\
- & \multicolumn{4}{c}{Linpack} & uniform - 20\%\\
+ & \multicolumn{4}{c}{Linpac - 3Gb} & uniform - 10\%\\
+ & \multicolumn{4}{c}{Linpac - tiny} & uniform - 10\%\\
  & \multicolumn{4}{c}{FFT} & uniform - 20\%\\
 
@@ -503 +502 @@
 \end {table}
 
-Execution time of each application is based on the measurements collected within our testbed.
 In all cases we assumed that  tasks are scheduled and served in order of their arrival (FIFO strategy with easy backfilling strategy). 
 
 \subsection{Computational analysis}
 
-In the following section presents 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 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. 
+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. 
 
 
@@ -518 +518 @@
 \end{figure}
 
-\textbf{total energy usage [kWh]} : 46,883
-\textbf{mean power consumption [W]} : 316,17
-\textbf{workload completion [s]} : 533 820
+\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. 
@@ -530 +530 @@
 \end{figure}
 
-\textbf{total energy usage [kWh]} : 36,705
-\textbf{mean power consumption [W]} : 247,53
-\textbf{workload completion [s]} : 533 820
+\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\%
@@ -545 +545 @@
 \end{figure}
 
-\textbf{total energy usage [kWh]} : 46,305
-\textbf{mean power consumption [W]} : 311,94
-\textbf{workload completion [s]} : 534 400
+\textbf{total energy usage}: 46,305 kWh
+\textbf{mean power consumption}: 311,94 W
+\textbf{workload completion}: 534 400 s
 
 
@@ -560 +560 @@
 \end{figure}
 
-\textbf{total energy usage [kWh]} : 30,568
-\textbf{mean power consumption [W]} : 206,15
-\textbf{workload completion [s]} : 533 820
+\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.
@@ -573 +573 @@
 \end{figure}
 
-\textbf{total energy usage [kWh]} : 77,108
-\textbf{mean power consumption [W]} : 260,57
-\textbf{workload completion [s]} : 1 065 356
+\textbf{total energy usage}: 77,108 kWh
+\textbf{mean power consumption}: 260,57 W
+\textbf{workload completion}: 1 065 356 s