Ignore:
Timestamp:
12/28/12 17:05:03 (12 years ago)
Author:
wojtekp
Message:
 
File:
1 edited

Legend:

Unmodified
Added
Removed
  • papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex

    r715 r716  
    493493 & \multicolumn{4}{c}{C-Ray} & uniform - 20\%\\ 
    494494 & \multicolumn{4}{c}{Tar} & uniform - 20\%\\ 
    495  & \multicolumn{4}{c}{Linpac - 3Gb} & uniform - 10\%\\ 
    496  & \multicolumn{4}{c}{Linpac - tiny} & uniform - 10\%\\ 
     495 & \multicolumn{4}{c}{Linpack - 3Gb} & uniform - 10\%\\ 
     496 & \multicolumn{4}{c}{Linpack - tiny} & uniform - 10\%\\ 
    497497 & \multicolumn{4}{c}{FFT} & uniform - 20\%\\ 
    498498 
     
    506506\subsection{Computational analysis} 
    507507 
    508 The scheduling strategy was evaluated according to two criteria: total energy consumption and total completion time. 
    509 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. 
    510  
    511 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.  
     508In 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). 
     509In the second part of this section en we discusses the corresponding results received for workloads with other density level. 
     510 
     511\subsubsection{Random approach} 
     512 
     513The 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. 
     514Figure~\ref{fig:70r} presents the energy consumption, load of the system and obtained schedule, respectively. 
    512515 
    513516 
     
    518521\end{figure} 
    519522 
    520 \textbf{total energy usage}: 46,883 kWh 
    521 \textbf{mean power consumption}: 316,17 W 
    522 \textbf{workload completion}: 533 820 s 
    523  
    524 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.  
     523In 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.  
    525524 
    526525\begin{figure}[h!] 
     
    530529\end{figure} 
    531530 
    532 \textbf{total energy usage}: 36,705 kWh 
    533 \textbf{mean power consumption}: 247,53 W 
    534 \textbf{workload completion}: 533 820 s 
    535  
    536 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\% 
    537  
    538 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. 
    539  
     531In 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\%.  
     532 
     533\subsubsection{Energy optimization} 
     534 
     535The 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}. 
     536 
     537\begin {table}[h!] 
     538\centering 
     539\begin{tabular}{ll} 
     540\hline 
     541Type & Power usage in idle state [W]  \\ 
     542\hline 
     543 Intel i7 & 11,5 \\ 
     544AMD Fusion & 19 \\ 
     545Atom D510  & 10 \\ 
     546\hline 
     547\end{tabular} 
     548\caption {\label{idlePower} Measured power of testbed nodes in idle state} 
     549\end {table} 
     550 
     551As 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. 
    540552 
    541553\begin{figure}[h!] 
     
    545557\end{figure} 
    546558 
    547 \textbf{total energy usage}: 46,305 kWh 
    548 \textbf{mean power consumption}: 311,94 W 
    549 \textbf{workload completion}: 534 400 s 
    550  
    551  
    552 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. 
    553  
    554  
     559This 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. 
     560 
     561 
     562The 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$. 
     563Contrary to the previous strategy, we expected Intel I7 nodes to be allocated first. Generated Gantt chart is compatible with our expectations. 
    555564 
    556565\begin{figure}[h!] 
     
    560569\end{figure} 
    561570 
    562 \textbf{total energy usage}: 30,568 kWh 
    563 \textbf{mean power consumption}: 206,15 W 
    564 \textbf{workload completion}: 533 820 s 
    565  
    566 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. 
     571Estimated \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. 
     572 
     573\subsubsection{Frequency scaling} 
     574 
     575The 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. 
    567576 
    568577 
     
    574583 
    575584\textbf{total energy usage}: 77,108 kWh 
    576 \textbf{mean power consumption}: 260,57 W 
    577 \textbf{workload completion}: 1 065 356 s 
     585\textbf{workload completion time}: 1 065 356 s 
    578586 
    579587 
    580588.... 
    581589 
     590 
     591\begin {table}[h!] 
     592\centering 
     593\begin{tabular}{l|lllll} 
     594\hline 
     595&  \multicolumn{5}{c}{Strategy}\\ 
     596Load  & R & R + NPM & EO & EO + NPM & DFS\\ 
     597\hline 
     59810\% & 241,337 &        37,811 & 239,667 & 25,571 & 239,278 \\ 
     59930\% &89,853 & 38,059 & 88,823 & 25,595.94       & 90,545 \\ 
     60050\% &59,112 & 36,797 & 58,524 & 26,328 & 76,020 \\ 
     60170\% &46,883 & 36,705 & 46,3062 & 30,568 & 77,109 \\ 
     602\hline 
     603\end{tabular} 
     604\caption {\label{loadEnergy} Energy usage [kWh] for different level of system load} 
     605\end {table} 
     606 
     607\begin {table}[h!] 
     608\centering 
     609\begin{tabular}{l|lllll} 
     610\hline 
     611&  \multicolumn{5}{c}{Strategy}\\ 
     612Load  & R & R + NPM & EO & EO + NPM & DFS\\ 
     613\hline 
     61410\% & 3 605 428 & 3 605 428 & 3 605 428 & 3 605 428 & 3 622 968 \\ 
     61530\% & 1 214 464 & 1 214 464 & 1 215 044 & 1 200 807 & 1 275 093 \\ 
     61650\% &729 066& 729 066 & 731 126& 721 617       & 1 049 485\\ 
     61770\% & 533 820 & 533 820 & 534 400 & 533 820 & 1 065 356\\ 
     618\hline 
     619\end{tabular} 
     620\caption {\label{loadMakespan} Makespan [s] for different level of system load} 
     621\end {table} 
     622 
    582623\section{DCWoRMS application/use cases}\label{sec:coolemall} 
    583624 
     
    586627... 
    587628 
    588 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. 
     629Being 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. 
    589630Hence, SVD Toolkit integrates also workload management and scheduling policies to support complex modeling and optimization of modern data centres. 
    590631 
    591632The 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. 
    592 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. 
     633In 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. 
    593634The 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. 
    594635 
Note: See TracChangeset for help on using the changeset viewer.