1. Energy Efficient Resource Management for high-performance computing platforms AUBURN UNIVERSITY
See also: defense_Ziliang.ppt
Department of Computer Science and Software Engineering
Ziliang Zong and Xiao Qin

2. Outline Introduction & Motivation
General Architecture for High-Performance Computing Platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
Conclusions
This is the outline of my presentation. The first part is the introduction and motivation of my research. The general architecture for high-performance computing platforms will be discussed in the second part. The next three parts will cover my primary research, which are the energy-efficient scheduling for clusters, grids and energy-efficient storage systems respectively. Finally, I will conclude my research.
11/12/2018

3. Introduction
High performance computing platforms have been widely deployed for intensive data processing and data storage. The impact of high performance computing platforms could be found in almost every domain: financial services, scientific computing, bioinformatics, computational chemistry, and weather forecast.
11/12/2018

4. Introduction
This slide shows a typical high-performance computing platform, which was built by Google in the Oregon state. There is no doubt that they have significantly changed our lives and we all benefit from the great services provided by these super computing platforms . However, these giant machines consume a huge amount of energy.
11/12/2018

5. Motivation
EPA Report to Congress on Server and Data Center Energy Efficiency, 2007
This figure comes from the report of Environmental Protection Agency submitted to the congress last year. Based on their report, the total power usage of servers and data centers in United States is 61.4 billion kwh in This is more than doubled the energy usage for the same purpose in If we look at the trend, from 2000 to 2006, the energy consumed by servers and data centers rapidly increased from 28.2 billion kwh all the way up to billion kwh.
11/12/2018

6. Motivation
EPA Report to Congress on Server and Data Center Energy Efficiency, 2007
Even worse, the EPA predicts that the power usage of servers and data centers will be doubled again within 5 years if the historical trends are followed. Even we follow the current efficiency trends, the power usage will exceed 100 billion kwh in This is a huge amount of energy.
11/12/2018

7. Reliability&Security
Motivation
Energy Efficiency
Performance
Reliability&Security
However, most pervious research primarily focus on the performance, security and reliability issues of high-performance computing platforms. The energy consumption issue was ignored. Now the energy problem has become so serious and I believe it is time for us to highlight the energy efficiency research of high-performance computing platforms.
11/12/2018

8. Outline Introduction & Motivation
General Architecture for High-Performance Computing Platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
Conclusions
In order to have a big picture of building energy-efficient high-performance computing platforms, we propose a general architecture and discuss the possibility of saving energy within each layer of this architecture.
11/12/2018

9. Architecture
In our architecture, we have four layers: application layer, middleware layer, resource layer, network layer. In each layer, we can incorporate energy-aware techniques. For example, in the application layer, we can reduce the unnecessary access to hardware when writing the code. In the middleware layer, we can schedule parallel tasks in more energy-efficient ways. In the resource and network layers, we can do energy-aware resource management.
11/12/2018

10. Architecture
This slide shows some typical hardware in the resource and network layers like CPU, main board, storage disk, network adapter, switch and router.
11/12/2018

11. High-Performance Computing Platforms
Design Issues
Performance
Energy Efficiency
Reliability
Security
High-Performance Computing Platforms
One thing I would like to emphasize here is that any energy-oriented research should not scarify other important characters like performance, reliability or security. Although there must be some tradeoff once we introduce energy-aware techniques, we do not want to see significant degradation in other characters. In other words, we would like to make our research compatible with existing techniques. For my research, I mainly focus on the tradeoff between performance and energy.
11/12/2018

12. Outline Introduction & Motivation
General Architecture for High-Performance Computing Platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
Conclusions
One of the primary contributions of my research is to design two energy-efficient scheduling algorithms for clusters. Next, we will talk about it in detail.
11/12/2018

13. Energy-Aware Scheduling for Clusters
Before we talk about the algorithms, let’s see the cluster systems first. In a cluster, we have the master node and slave nodes. The master node is responsible to schedule tasks and allocate them to slave nodes for parallel execution. All slave nodes are connected by high speed interconnections and they communicate with each other through message passing.
11/12/2018

14. Parallel Applications
The parallel tasks running on clusters are represented using Directed Acyclic Graph , or DAG for short. Usually, a dag has one entry task and one or multiple exit tasks. Dag shows the task number and the execution time of each task. It also shows the dependence and communication time among tasks. Explain a little bit…
11/12/2018

15. Motivational Example Linear Schedule Time: 39s 8 1 2 3 4 6 5 10 15 T18 T3 23 T2 33 T4 39
No Duplication Schedule (NDS)
Time: 32s T1 8 T3 23 T2 6 24 14 2 26 T4 32
Weakness 1: Do not consider energy conservation in memory
Weakness 2: Energy can’t be conserved even then network interconnects are idle
In order to improve performance, we use duplication strategy. This slide shows why duplication can improve performance. Here we have 4 tasks represented by the DAG in the left side. If we use linear scheduling, all four tasks will be allocated in 1 CPU and the execution time will be 39s. However, we noticed that we can schedule task 2 to the 2nd CPU so that we do not need to wait the completion of task 3. In that way, the total time will shortened to 32s. We also noticed that 6s are wasted in the 2nd CPU because task 2 has to wait the message from task 1. If duplicate task 1 in the 2nd CPU, we can further shorted the schedule length to 29s. Obviously, the duplication could improve performance.
Task Duplication Schedule (TDS)
Time: 29s
An Example of duplication T1 8 T2 18 2 T3 23 T4 29 20
11/12/2018

16. Motivational Example (cont.)
Linear Schedule
Time:39s Energy: 234J
(10,60)
(8,48) 1 2 3 4
(6,6)
(5,5)
(15,90)
(2,2)
(4,4)
(6,36) T1 8 T3 23 T2 33 T4 39
No Duplication Schedule (MCP)
Time: 32s Energy: 242J T1 8 T3 23 T2 6 24 14 2 26 T4 32
However, if we calculate the energy, we will find that duplication may consume more power. For example, if we set the energy consumption for CPU and network 6w and 1w, the total energy consumption of duplication will be 42J more than NDS and 50J more than linear schedule. That is mainly because task 1 are executed twice. Here I would like to mention that I will use NDS(MCP) to represent no duplication schedule and use TDS to represent task duplication schedule. You will see a lot of them in the simulation results.
Task Duplication Schedule (TDS)
Time: 29s Energy: 284J
An Example of duplication T1 8 T2 18 2 T3 23 T4 29 20
CPU_Energy=6W
Network_Energy=1W
11/12/2018

17. Motivational Example (cont.)
The energy cost of duplicating T1:
CPU side: 48J Network side: -6J Total: 42J
The performance benefit of duplicating T1: 6s
Energy-performance tradeoff: 42/6 = 7
(10,60)
(8,48) 1 2 3 4
(6,6)
(5,5)
(15,90)
(2,2)
(4,4)
(6,36)
EAD
Time: 32s Energy: 242J T1 8 T3 23 T2 6 24 14 2 26 T4 32
So we have to consider the tradeoff between performance and power consumption. We propose two algorithms to consider the tradeoff. One is called energy-aware duplication or EAD for short. The other one is called performance-energy balanced duplication or PEBD for short. In EAD, we only calculate the energy cost for duplicating a task. For example, if we duplicate T1, we will pay the 48J energy cost in the CPU side because we have to execute T1 twice . At the same time, we can save 6J energy in the network side because we do not need send message from T1 to T2. So the total cost will be 42J. In PEBD, we also calculate the performance benefit. If we duplicate T1, we can shorten schedule length 6s in maxim. So the ration between energy and performance will be 7. If we set duplication threshold to be 10, EAD will not duplicate while PEBD will duplicate.
PEBD
Time: 29s Energy: 284J
If Threshold = 10
Duplicate T1?
EAD: NO
PEBD: Yes T1 8 T2 18 2 T3 23 T4 29 20
11/12/2018

18. Basic Steps of Energy-Aware Scheduling
Algorithm Implementation:
Step 1: DAG Generation
Task Description:
Task Set {T1, T2, …, T9, T10 }
T1 is the entry task;
T10 is the exit task;
T2, T3 and T4 can not start until T1 finished;
T5 and T6 can not start until T2 finished;
T7 can not start until both T3 and T4 finished;
T8 can not start until both T5 and T6 finished;
T9 can not start until both T6 and T7 finished;
T10 can not start until both T8 and T9 finished;
Now let’s look at how to implement the algorithms using a concrete example. Step1, we will generate the DAD based on the task description, which should be provided by users.
11/12/2018

19. Basic Steps of Energy-Aware Scheduling
Algorithm Implementation:
Total Execution time from current task to the exit task
Earliest Start Time
Earliest Completion Time
Latest Allowable Start Time
Latest Allowable Completion Time
Favorite Predecessor
Step 2: Parameters Calculation
Task
Level
EST
ECT
LAST
LACT FP 1 40 3 -- 2 28 6 4 7 37 35 5 16 17 25 33 27 8 15 23 18 9 13 32 10
Next, we are going to calculate the important parameters based on the equations shown in Chapter4. The level means…
11/12/2018

20. Basic Steps of Energy-Aware Scheduling
Algorithm Implementation:
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Step 3: Scheduling
Task
Level
EST
ECT
LAST
LACT FP 1 40 3 -- 2 28 6 4 7 37 35 5 16 17 25 33 27 8 15 23 18 9 13 32 10
Once we have these parameters, we can obtain the original task list by sorting the level in an ascending order. We will start from the first unscheduled task in the list, which is 10, and follow the favorite predecessor to the entry task. All tasks on this path will form a critical path. Here the first critical path will be 10->9->7->3->1; Then, these tasks will be marked as scheduled. In the next iteration, the algorithm will pick up the next unscheduled task as the start task and form the second critical path. Then, the third one and the fourth one. The algorithm will not terminated until all tasks have been scheduled.
11/12/2018

21. Basic Steps of Energy-Aware Scheduling
Algorithm Implementation:
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Original Task List: {10, 9, 8, 5, 6, 2, 7, 4, 3, 1}
Step 4: Duplication Decision
Decision 1: Duplicate T1?
Decision 2: Duplicate T2?
Duplicate T1?
The algorithms also have to make the duplication decision. Explain…
Decision 3: Duplicate T1?
11/12/2018

22. The EAD and PEBD Algorithms
Generate the DAG of given task sets
Find all the critical paths in DAG
Generate scheduling queue based on the level (ascending)
select the task (has not been scheduled yet) with the lowest level as starting task
For each task which is in the
same critical path with starting task, check
if it is already scheduled
allocate it to the same processor with the tasks in the same critical path
Yes No
meet entry task
Save time if duplicate
this task?
Calculate energy increase
and time decrease
Ratio= energy increase/ time decrease
Ratio<=Threshold?
Duplicate this task and select the next task in the same critical path
more_energy<=Threshold?
PEBD
EAD
This diagram summarize the steps we just talked about. I will just skip it.
11/12/2018

23. Energy Dissipation in Processors
Now we are going to discuss the simulation results. We implement our own simulator using C language under Linux system. The CPU power consumption parameters come from the xbitlabs. We simulate 4 different CPUs, 3 of them are AMD and one is Intel.
11/12/2018

24. Parallel Scientific Applications
This slide shows the structure of two small task set. The left one is Fast Fourier Transform and the right one is Gaussian Elimination.
Fast Fourier Transform
Gaussian Elimination
11/12/2018

25. Large-Scale Parallel Applications
The slide shows the DAG structure of two real-world applications. The left one is Robot Control and the right one is Sparse Matrix Solver.
Robot Control
Sparse Matrix Solver
11/12/2018

26. Impact of CPU Power Dissipation
Impact of CPU Types:
19.4%
3.7%
CPU Type
Power (busy)
Power (idle)
Gap
104w
15w
89w
75w
14w
61w
47w
11w
36w
44w
26w
18w
Observation: CPUs with large gap between CPU_busy and CPU_idle can obtain greater energy savings
This slide shows the impact of CPU types. Recall that I simulate 4 different CPUs, which are represented in 4 different colors. We found that the CPU with blue color can save more energy compares with other 3 CPUs. For example, we can save 19.4% energy using blue CPU while we only can save 3.7% for the purple CPU. The indication behind is that these 4 CPUs have different gaps between CPU_busy and CPU_idle. This table summarize the difference. The gap for the blue CPU is 89w but the gap for the purple CPU is only 18w. So our observation is…
Energy consumption for different processors (Gaussian, CCR=0.4)
Energy consumption for different processors (FFT, CCR=0.4)
11/12/2018

27. Impact of Interconnect Power Dissipation
Impact of Interconnection Types:
16.7%
13.3% 5%
3.1%
This slide shows the impact of interconnections. The left one is the simulation results for Myrinet and the right one is the simulation results for the Infiniband. We can save 16.7% and 13.3% energy when CCR is 0.1 and 0.5 respectively using Myrinet. However, the number drops down to 5% and 3.1% for Infiniband. We found that the only difference between these two simulation sets are the network power consumption rate. The Myrinet is 33.6w and the Infiniband is 65w. So our observation is that…
Energy consumption (Robot Control, Myrinet)
Energy consumption (Robot Control, Infiniband)
Interconnection
Power
Myrinet
33.6w
Infiniband
65w
Observation: The energy saving of EAD and PEBD is degraded if the interconnection has high power consumption rate.
11/12/2018

28. Parallelism Degrees Impact of Application Parallelism: 17% 15.8% 6.9%
5.4%
We also observe the impact of application parallelism. The left figure shows the experimental results for Robot Control and the right one shows the results for Sparse. We noticed that we can save 17% and 15.8% energy for robot but only save 6.9% and 5.4% energy for sparse when CCR is the same. That is because the parallelism of robot is less than sparse. So our observation is…
Energy consumption of Robert Control(Myrinet)
Energy consumption of Sparse Matrix (Myrinet)
Application
Parallelism
Robot Control
Sparse Matrix Solver
Observation: Robert Control has more task dependencies thus there exists more possibility for EAD and PEBD to consume energy by judiciously duplicating tasks.
11/12/2018

29. Communication-Computation Ratio
Impact of CCR:
Processor type:
Athlon W
Interconnection:
Myrinet
Simualated Application:
Robot Control
CCR:
(0.1, 0.5, 1, 5, 10)
Observation:
The overall energy consumption of EAD and PEBD are less than MCP and TDS.
EAD and PEBD are very sensitive to CCR
MCP provides the greatest energy savings if CCR is less than 1
MCP consumes much more energy when CCR is large
This slide shows our observation to the impact of CCR. Read...
Energy consumption under different CCRs
CCR: Communication-Computation Rate
11/12/2018

30. Performance Impact to Schedule Length:
Schedule length of Gaussian Elimination
This group of simulation results show the impact to performance. The left one is for Gaussian and the right one is for Sparse. This table summarize that the overall performance degradation of EAD and PEBD is 5.7% and 2.2% compared with TDS for Gaussian. For Sparse, the number is 2.92% and 2.02%. Our observation is …
Schedule length of Sparse Matrix Solver
Application
EAD Performance Degradation (: TDS)
PEBD Performance Degradation (: TDS)
Gaussian Elimination
5.7%
2.2%
Sparse Matrix Solver
2.92%
2.02%
Observation: it is worth trading a marginal degradation in schedule length for a significant energy savings for cluster systems.
11/12/2018

31. Outline Introduction & Motivation
General Architecture for High-Performance Computing Platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
Conclusions
Now let’s talk about the energy-efficient scheduling for Grids. The scheduling for Grids are more complicated compared with the scheduling for clusters in both the system’s view and the task’s view. That is due to the heterogeneity of Grids.
11/12/2018

32. Energy-Aware Scheduling for Grids
In Cluster systems, we suppose the software and hardware are identical. But in Grid systems, we may have different operating systems, different CPUs, different interconnections, etc. So we have to carefully consider the heterogeneity when we design the algorithm.
11/12/2018

33. Motivational Example
For example, we designed a mapping matrix to represent the execution time of tasks in different processors. As you can see, for the same task T1, the execution time are 6.7, 3.9, 2.0 respectively. If a task could not be executed in a processor, we will put a infinite sign.
11/12/2018

34. Motivational Example (cont.)B C D C1
3050J
3700J
2008J
3000J C2
1000J
900J
1560J
1200J C3
180J
194J
136J
75J C4
207J
226J
251J
243J
Energy calculation for tentative schedule C1 C2 C3 C4
11/12/2018

35. Experimental Settings
Simulation Environments
Parameters
Value (Fixed) - (Varied)
Different trees to be examined
Gaussian elimination, Fast Fourier Transform
Execution time of Gaussian Elimination
{5, 4, 1, 1, 1, 1, 10, 2, 3, 3, 3, 7, 8, 6, 6, 20, 30, 30 }-(random)
Execution time of Fast Fourier Transform
{15, 10, 10, 8, 8, 1, 1, 20, 20, 40, 40, 5, 5, 3, 3 }-(random)
Computing node type
AMD Athlon 64 X with 85W TDP (Type 1)
AMD Athlon 64 X with 65W TDP (Type 2)
AMD Athlon 64 X with 35W TDP (Type 3)
Intel Core 2 Duo E6300 processor (Type 4)
CCR set
Between 0.1 and 10
Computing node heterogeneity
Environment1:
# of Type 1: 4
# of Type 2: 4
# of Type 3: 4
# of Type 4: 4
Environment2:
# of Type 1: 6
# of Type 2: 2
# of Type 3: 2
# of Type 4: 6
Environment3:
# of Type 1: 5
# of Type 2: 3
# of Type 3: 3
# of Type 4: 5
Environment4:
# of Type 1: 7
# of Type 2: 1
# of Type 3: 1
# of Type 4: 7
Network energy consumption rate
20W, 33.6W, 60W
11/12/2018

36. Communication-Computation Ratio
We compared our HEADUS algorithm with other 4 algorithms and found that HEADUS can obtain the best overall energy savings in all of the 4 different environments.
CCR sensitivity for Gaussian Elimination
11/12/2018

37. Computational nodes heterogeneity experiments
CPU Type E1 E2 E3 E4 4 6 5 7 2 3 1
Observation: CPUs with large gap between CPU_busy and CPU_idle can obtain greater energy savings
We also observed that HEADUS can same more energy under environment 2 and 4.
Computational nodes heterogeneity experiments
11/12/2018

38. Outline Introduction & Motivation
General Architecture for High-Performance Computing Platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
Conclusions
Storage systems are one of the biggest energy consumers in high performance computing platforms. Therefore, we proposed a buffer disk based architecture for building energy efficient storage systems. We call this architecture BUD.
11/12/2018

39. Dynamic Power Management
Active
Idle
Standby
Power states of disks
Usually, a disk has three states, active, idle and sleep. Each state has different energy consumption rate. As you can guess, disks in active state will consume more energy than disks in idle state. Similarly, disks in sleep state have lower energy consumption rate than disks in idle state.
11/12/2018

40. Hard Disk Parameters Parameters IBM 36Z15 Ultrastar (high perf.)
IBM 73LZX Ultrastar
(low perf.)
Number of platters 4 2
Rotations per minute
15000
10000
Average seek time
3.4 ms
4.9 ms
Average rotation time
2 ms
3 ms
Transfer rate
55 MB/sec
53 MB/sec
Power (active)
13.5 W
9.5 W
Power (idle)
10.2 W
6.0 W
Power (standby)
2.5W
1.4W
Energy (spin down)
13.0 J
10.0 J
Time (spin down)
1.5 s
1.7 s
Energy (spin up)
135.0 J
97.9 J
Time (spin up)
10.9 s
10.1 s
This table may give you a more concrete idea of energy consumption rate in different states. For example, for IBM 36Z15 disk, the energy consumption rate in active, idle and sleep state is 13.5W, 10.2W and 2.5W respectively. As you can see, disks in sleep state consume much less energy compared with idle and active states. The basic idea of BUD is simple and straightforward. We want to keep as many disks in sleep state and improve the utilization of disks working in active state. How to do that?
11/12/2018

41. Motivational Example buffer disk buffer disk buffer disk
Requests Queue
In the traditional disk arrays, requests are served directly by data disks. To maximize the performance, the traditional disk arrays tend to keep the disks in active state, even they do not produce any useful work. This will waste a lot of energy. Actually, some disks has very low utilization rate in real world traces, probably less than 20% or even 10%, we can save a lot of energy if we turn them into sleep state. Please note that the golden disks are active disks and gray disks are sleeping disks. For other disks whose utilization rate is relatively high, around 50% - 70%, we still have the opportunity to sleep them. However, the utilization of some disks might be extremely high because they stored very hot or popular blocks. It is almost impossible to sleep them. Our idea is to add one more layer, called the buffer disk layer, on the top of the data disk layer. The requests will be served by buffer disks first rather than by data disks directly. We can cache all those hot blocks to the buffer disks and sleep as many data disks as possible.
11/12/2018

42. Motivational Example buffer disk buffer disk buffer disk
Requests Queue
buffer disk
buffer disk
buffer disk
Cont…
11/12/2018

43. Buffer-Disk Architecture
A general framework
Large number of data disks
Small number of buffer disks
RAM Buffer
m buffer disks
n data disks
Buffer Disk Controller
Data Partitioning
Security Model
Load Balancing
Power Management
Prefetching
Disk Requests
Energy-Related Reliability Model
This slide shows a general framework of BUD. BUD consists of four major components: a RAM buffer, m buffer disks, n data disks, and a buffer-disk controller. The controller is the key component which contains reliability model, security model, power management and load balancing. Currently my research focuses on the load balancing and power management part. In BUD, the number of buffer disks should be much less than the number of data disks in order to save energy. BUD strives to serve all requests using limited number of buffer disks, thereby keeping a large number of data disks in low-power states. This can provide significant opportunities for energy conservation. However, the buffer disk may easily be overloaded and become the performance bottleneck. This may get worse if we cannot achieve good load balancing among buffer disks.
11/12/2018

44. Sequential Mapping Sequential Mapping
Let’s see an example of unbalanced workload in buffer disks. In this example, requests accessing different data blocks are represented in different colors. For example, request 1(white) will access data block 1 (white) existing in data disk 1, and request 6 (green) will access data block 6 (green) existing in data disk 6. We use sequential mapping strategy to cache data from data disks to buffer disks. That means, buffer disk 1 can only cache data coming from data disks 1 and 2, similary, buffer disk 2 can only cache data of data disks 3 and 4. Buffer disk 3 can only cache data of data disks 5 and 6. Initially, no data blocks are cached in buffer disks. When request 1 comes, it will be cached to buffer disk 1……explain in detail. Now you can see that buffer disk 1 will be allocated 9 tasks while buffer disks 2 and 3 only served 3 requests. Very likely, buffer disk 1 will become the performance bottleneck.
Sequential Mapping
11/12/2018

45. Round-Robin Mapping Round-Robin Mapping
If we use a round-robin mapping strategy, that means, blocks will be cached to buffer disks in a round robin way, for example, explain…. Finally, buffer disks 1, 2, 3 will be allocated 7, 5 and 3 requests respectively. This is slightly better than sequential mapping but buffer disks are still not well balanced.
Round-Robin Mapping
11/12/2018

46. Heat-Based Load Balancing
We proposed a heat-based load balancing algorithm which aims to get the result like this picture. Each buffer disk is equally loaded with 5 requests.
Heat-Based Load Balancing
11/12/2018

47. Load Balancing Algorithm
Requests
Access Frequency: times a data block is repeatedly accessed within a specific time unit.
Heat weight: the ratio of requested data size and standard data size (e.g. 1MB)
Heat: the product of access frequency and heat weight
Temperature: the accumulated heat of all data blocks residing in a buffer disk
A Window
Sort by Heat
Find Coolest Buffer
Here is our algorithm. We use the word heat to measure how hot or how popular a block is. The heat is the product of access frequency and heat weight. Access frequency represents the times a data block is repeatedly accessed within a specific time unit. The heat weight is the ratio of requested data size and standard data size (e.g. 1MB). Heat weight is used to adjust the impact of data size. A block with large data size will have higher heat weight because the system will spend more time to serve the request. Temperature is the accumulated heat of all data blocks residing in a buffer disk, which can be used to measure how busy a buffer disk is. The algorithm will first form a window from the requests cached in the RAM. Next, it will calculate the heat of each block and sort the heat in a descending order. After that, it will find the buffer disk with lowest temperature and allocate the hottest block to the coolest buffer. Once a block is allocated, the temperature of this buffer disk will be immediately updated. In the next iteration, the algorithm will find the second hottest block and allocate it to the updated coolest buffer disk. The iteration will not terminate until all blocks in the window are allocated.
Update Temperature
11/12/2018

48. Energy Consumption Results
Energy consumption for large reads
5000
2000
10000
20000
Large Reads: average 84.4% improvement (64MB)
Small Reads: average 78.77% improvement (64KB)
5000
2000
10000
20000
The first experimental result shows that the BUD architecture can significantly conserve energy compared with the disks arrays without buffer disks. For example, we have average 84.4% improvement for large reads and 78.77% improvement for small reads.
Energy consumption for small reads
11/12/2018

49. Load Balancing Comparison
We also studied the load balancing efficiency of different mapping strategies. This result shows that our heat-based algorithm can achieve the best load balancing because the temperatures of three buffer disks are almost the same. The round robin mapping works better than sequential mapping.
Load balancing comparison for three mapping strategies
11/12/2018

50. Response time trace before caching (large reads)
Impact On Performance
In order to study the impact on performance, we traced the response time of 20,000 large requests. The x axis is the # of tasks and the y axis is the response time. The blue area plots the real response time and the embedded black line shows the trend of response time. From this figure, we can see the obvious delay in the initial stage due to the overhead of copying blocks from data disks to buffer disks. However, once the initial caching stage is done, the response time drops immediately to an acceptable level.
Response time trace before caching (large reads)
11/12/2018

51. Response time trace after caching (large reads)
Impact On Performance
We executed 5000 requests after the initial caching stage and the response time of BUD is almost the same with no buffer disk arrays, which is we would like to see.
Response time trace after caching (large reads)
11/12/2018

52. Impact On Performance Response time trace after caching (small reads)
I did the exact same simulation for small reads. This figure shows the response time before caching. We do not see a peak as appeared for the large reads. That is because the size of the requests is small so that we can avoid the accumulating delays.
Response time trace after caching (small reads)
11/12/2018

53. Impact On Performance Response time trace after caching (small reads)
The response time are significantly improved after caching.
Response time trace after caching (small reads)
11/12/2018

54. Impact On Performance Average Response Time Before caching (64MB):
After caching (64MB):
1.219s
NO-Buffer(64MB)
1.216s
Before caching (64KB):
0.767s
After caching (64KB):
0.01s
NO-Buffer(64KB)
Large requests
We compared the average response time of BUD and No buffer disks and find out that the performance will be affected in the initial stage when few hot blocks are cached in buffer disks. However, once the system runs a while and most hot blocks are cached in the buffer disks, the response time is very close to no buffer disk arrays. For example, the average response time before caching for small reads is 0.767s while it drops to 0.1s after caching.
Small requests
11/12/2018

55. Outline Introduction & Motivation
General Architecture for High-Performance Computing Platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
Conclusions
Now I would like to concludes my research.
11/12/2018

56. Conclusions Architecture for high-performance computing platforms
Energy-Efficient Scheduling for Clusters
Energy-Efficient Scheduling for Grids
Energy-Efficient Storage Systems
11/12/2018

57. Publication
Z.-L. Zong, A. Manzanares, K. Bellam and X. Qin, "Two Improved Energy-Aware Duplication Strategies for Homogeneous Clusters", IEEE Transactions on Computers. Submitted Apr. 2007; revised Aug (under 2nd round review)
X. Qin, M. Alghamdi, M. Nijim, Z.-L. Zong, X.-J. Ruan, K. Bellam, and A. A. Manzanares, "Improving Security of Real-Time Wireless Networks Through Packet Scheduling", IEEE Transactions on Wireless Communications. Submitted Feb. 2007; revised Sept. 2007; accepted Oct
Z.-L. Zong, M. Nijim, and X. Qin, "Energy-Efficient Scheduling for Parallel Applications on Mobile Clusters", Cluster Computing: The Journal of Networks, Software Tools and Applications. Submitted May 2006; revised Jan. 2007; accepted March
M. Nijim, Z.-L. Zong, and X. Qin, "StReD : A Quality of Security Framework for Storage Resources in Data Grids", Future Generation Computer Systems: The Int'l Journal of Grid Computing. Submitted April 2006; revised Sept. 2006; accepted Dec
Z.-L. Zong, K. Bellam, X. Qin, Y.M. Yang, "A Simulation Framework for Energy Efficient Data Grids", Winter Simulation Conference 07, Washington, D.C. U.S. December 9-12, 2007.
Z.-L. Zong, X. Qin, M. Nijim, X.-J. Ruan, K. Bellam, and M. Alghamdi, "Energy-Efficient Scheduling for Parallel Applications Running on Heterogeneous Clusters", Proc. International Conference on Parallel Processing, Xi'an, China, September (Acceptance Rate: 25%).
Z.-L. Zong, A. Manzanares, B. Stinar, and X. Qin, "Energy-Efficient Duplication Strategies for Scheduling Precedence Constrained Parallel Tasks on Clusters", Proc. International Conference on Cluster Computing (Cluster'06), Sept Best Paper Award Nomination; IEEE TCSC Student Travel Award
11/12/2018

58. Publication
Z.-L. Zong, M.E. Briggs, N.W. O'Connor, X. Qin, M. Alghamdi, and Y.-M. Yang, "Design and Performance Analysis of Energy- Efficient Parallel Storage Systems", the Commodity Cluster Symposium 2007 (CCS2007), Annapolis, Maryland, July 2007.
Z.-L. Zong, M.E. Briggs, N.W. Connor, and X. Qin, "An Energy-Efficient Framework for Large-Scale Parallel Storage Systems", Proc. IEEE International Parallel & Distributed Processing Symposium Workshop, March, 2007.
Z.-L. Zong, M. Nijim, M. Alghamdi, X. Qin, "HAGEES: A High Availability Guaranteed Energy-Efficient Scheduling Strategy for High-Performance Clusters", High Availability and Performance Computing Workshop (HAPCW2006), Oct
K. Bellam, Z.-L. Zong, M. Alghamdi, M. Nijim, X. Qin, "Integrating Fault Recovery and Quality of Security in Real-time Systems", Proc. IEEE International Symposium on Ubisafe Computing, Niagara Falls, Ontario, Canada, May Nokia Student Travel Award
X. Qin, M. Alghamdi, Z.-L. Zong, M. Nijim, "Scheduling of Periodic Packets in Energy-Aware Wireless Networks", Proc. the 26th IEEE International Performance Computing and Communications Conference, Apr (Acceptance Rate: 37%)
X.-J. Ruan, X. Qin, M. Nijim, Z.-L. Zong, and K. Bellam, "An Energy-Efficient Scheduling Algorithm Using Dynamic Voltage Scaling for Parallel Applications on Clusters," Proc. 16th IEEE Int'l Conference on Computer Communications and Networks (ICCCN), Honolulu, Hawaii, Aug (Acceptance Rate: 29%)
K. Bellam, K. Vudata, X. Qin, M. Nijim, Z.-L. Zong, and X.-J. Ruan, "Integrating Security and Reliability in Real-Time Systems using Non-Uniform Checkpoints", Proc. 16th International Conference on Computer Communications and Networks (ICCCN 2007), Aug (Acceptance Rate: 29%).
M. Nijim, T. Xie, Z.-L. Zong, X. Qin, "An Adaptive Strategy for Secure Distributed Disk Systems", NASA/IEEE Conference on Mass Storage Systems and Technologies, May 2006.
11/12/2018

59. Questions
11/12/2018