Changeset 716 for papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex
- Timestamp:
- 12/28/12 17:05:03 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex
r715 r716 493 493 & \multicolumn{4}{c}{C-Ray} & uniform - 20\%\\ 494 494 & \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\%\\ 497 497 & \multicolumn{4}{c}{FFT} & uniform - 20\%\\ 498 498 … … 506 506 \subsection{Computational analysis} 507 507 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. 508 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). 509 In 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 513 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. 514 Figure~\ref{fig:70r} presents the energy consumption, load of the system and obtained schedule, respectively. 512 515 513 516 … … 518 521 \end{figure} 519 522 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. 523 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. 525 524 526 525 \begin{figure}[h!] … … 530 529 \end{figure} 531 530 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 531 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\%. 532 533 \subsubsection{Energy optimization} 534 535 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}. 536 537 \begin {table}[h!] 538 \centering 539 \begin{tabular}{ll} 540 \hline 541 Type & Power usage in idle state [W] \\ 542 \hline 543 Intel i7 & 11,5 \\ 544 AMD Fusion & 19 \\ 545 Atom D510 & 10 \\ 546 \hline 547 \end{tabular} 548 \caption {\label{idlePower} Measured power of testbed nodes in idle state} 549 \end {table} 550 551 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. 540 552 541 553 \begin{figure}[h!] … … 545 557 \end{figure} 546 558 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 559 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. 560 561 562 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$. 563 Contrary to the previous strategy, we expected Intel I7 nodes to be allocated first. Generated Gantt chart is compatible with our expectations. 555 564 556 565 \begin{figure}[h!] … … 560 569 \end{figure} 561 570 562 \textbf{total energy usage}: 30,568 kWh 563 \textbf{mean power consumption}: 206,15 W 564 \ textbf{workload completion}: 533 820 s565 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.571 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. 572 573 \subsubsection{Frequency scaling} 574 575 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. 567 576 568 577 … … 574 583 575 584 \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 578 586 579 587 580 588 .... 581 589 590 591 \begin {table}[h!] 592 \centering 593 \begin{tabular}{l|lllll} 594 \hline 595 & \multicolumn{5}{c}{Strategy}\\ 596 Load & R & R + NPM & EO & EO + NPM & DFS\\ 597 \hline 598 10\% & 241,337 & 37,811 & 239,667 & 25,571 & 239,278 \\ 599 30\% &89,853 & 38,059 & 88,823 & 25,595.94 & 90,545 \\ 600 50\% &59,112 & 36,797 & 58,524 & 26,328 & 76,020 \\ 601 70\% &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}\\ 612 Load & R & R + NPM & EO & EO + NPM & DFS\\ 613 \hline 614 10\% & 3 605 428 & 3 605 428 & 3 605 428 & 3 605 428 & 3 622 968 \\ 615 30\% & 1 214 464 & 1 214 464 & 1 215 044 & 1 200 807 & 1 275 093 \\ 616 50\% &729 066& 729 066 & 731 126& 721 617 & 1 049 485\\ 617 70\% & 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 582 623 \section{DCWoRMS application/use cases}\label{sec:coolemall} 583 624 … … 586 627 ... 587 628 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 Decis sion 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.629 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. 589 630 Hence, SVD Toolkit integrates also workload management and scheduling policies to support complex modeling and optimization of modern data centres. 590 631 591 632 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. 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, D ynamic 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.633 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. 593 634 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. 594 635
Note: See TracChangeset
for help on using the changeset viewer.