Repository ISTITUZIONALE
Energy-aware Software / Ardito, Luca. - (2014). Original Energy-aware Software Publisher: Published DOI:10.6092/polito/porto/2537893 Terms of use: openAccess Publisher copyright
(Article begins on next page)
This article is made available under terms and conditions as specified in the corresponding bibliographic description in the repository
Availability:
This version is available at: 11583/2537893 since: Politecnico di Torino
POLITECNICO DI TORINO
SCUOLA DI DOTTORATO
Dottorato in Ingegneria Informatica e dei Sistemi – XXVI ciclo
Tesi di Dottorato
Energy-aware software
Luca Ardito
Tutore Coordinatore del corso di dottorato
To my Grandmother
“Mina”
Summary
Luca Ardito has focused his PhD on studying how to identify and to reduce the energy consumption caused by software. The project concentrates on the application level, with an experimental approach to discover and modify characteristics that waste energy. We can define five research goals:
• RG1. Is it possible to measure the energy consumption of an ap-plication? Measuring the energy consumption of an electronic device (PC, mobile phone, etc.) is straightforward, but several applications coexist on it, possibly with very different energy needs. Usage profiles for applications are certainly important too. We will consider the most common platforms (Windows, Linux, Mac Osx)1.
• RG2. Could Energy Efficiency be considered as a software non-functional requirement? Research has increasingly focused on improving the Energy Efficiency of hardware, but the literature still lacks in quantifying accurately the energy impact of software. This research goal is strictly related to the following one.
• RG3. Is it possible to profile the energy consumption of a soft-ware application? An empirical experiment could assess quantitatively the energetic impact of software usage by building up common application us-age scenarios and executing them independently to collect power consumption data.
• RG4. Is there a relationship between the way a program is written and its energy consumption? The same application, at the code level, can be written in different ways. Here the question is if the different ways have impact on energy consumption. The code should be considered at two levels: source code (programmer) and object code/byte code (compiler). [88]
1
Reaching this point, I can hardly believe I have achieved my goal. During my mas-ter’s thesis, written between the Department of Computer and Control Engineering of Politecnico di Torino and Telecom Italia Labs, I discovered the world of research. From that moment I decided to apply for the PhD programme at Politecnico di Torino. When I realised that I had been selected for the PhD, it did not seem real, and I saw the time of delivery of the PhD dissertation as far away and not very certain. During these years I learned a lot, and had the opportunity to participate in many conferences around the world (I still clearly remember how I was scared during my first “talk” in Athens!). I came to know the world of research: a very new environment for me. For this reason I would like to thank my supervisor: Professor Maurizio Morisio, who motivated me during these three years, and especially as he gave me the opportunity to deal with many situations that at the time seemed to me to be far above my abilities. Thanks also to Professor Marco Torchiano, who is always ready to help me when I have a problem. And how can we forget all my PhD mates: Federico, Antonio, Giuseppe Rizzo, Matteo, Andrea, Edoardo, Marco, Oscar, Cristhian, Ali, Najeeb, and Giuseppe Procaccianti. We always managed to group ourselves against Procaccianti on any occasion (especially Federico!), in that way making the atmosphere more pleasant and less stressful (especially when we tried to give Procaccianti all our work to do... but probably this is not the right time to reveal these secrets!). A special thanks goes to the team of Telecom Italia Labs composed of Carlo Licciardi, Marco and Luca (great travel companions during the Californian trips) and Lucia. I have never stopped cooperating with them since I started my master’s thesis in 2009: you are among the first to have believed in me, thank you. A special thanks goes to Ingrid, who put up with me during all these years. You had (and you have) great patience to be around me when things were not going exactly as I expected (therefore almost always!). Thank youTatina. I cannot forget to thank the people who lived at No.14: Stefano, Fonta, Filippo, Paolo, and Emiliano. At 14 Via Gioberti, there was always something fun to do! Thanks to my friends Stefano, Alan, Marco, Andrea S., Veronica, Andrea G., Claudia, Diego B., Silvia, Maria, Lucia, Loredana, Diego R., who have encouraged, entertained, supported me through the dark times, celebrated with me through the good, who
have been brilliant and understanding when I needed them to be, I take this op-portunity to thank you. Last but not least I thank my family, Mum Pinuccia, Dad Marco, and Grandparents Beppe, Battista and Ettorina. All you have ever done is the impossible for me and you gave me the opportunity to tackle this path. Without your support (both moral and material), it would never have been possible. I will never cease to give thanks for you.
2.1 Energy Metrics and Benchmarks . . . 10
2.2 Energy Metrics and Benchmarks . . . 17
2.3 CRT energy consumption estimate [86] . . . 18
2.4 LCD energy consumption estimate [86] . . . 18
2.5 Printer energy consumption estimate [86] . . . 19
2.6 Energy consumption of networking devices in the Internet [41] . . . . 19
3.1 Example of SQALE model for Java language, from [62] . . . 40
3.2 Guidelines that can be translated into SQALE requirements . . . 43
3.3 Requirements for Energy Efficiency . . . 45
4.1 Energy Metrics and Benchmarks . . . 53
4.2 Average instant power consumption of selected devices . . . 57
4.3 Result of Wilcoxon test on servers instant power consumptions . . . 57
4.4 Servers’ power consumption profiles - data clustering . . . 62
4.5 Servers’ power consumption comparison between day and night . . . 62
4.6 Cumulative power consumption by profiles . . . 62
4.7 The GQM Model . . . 68
4.8 Software Usage Scenarios Overview . . . 72
4.9 HW/SW Configuration of the test machine . . . 75
4.10 Scenarios Statistics Overview: Old-Generation PC . . . 80
4.11 Scenarios Statistics Overview: New-Generation PC . . . 81
4.12 Hypotheses H1 Test Results . . . 82
4.13 Hypothesis H2 Test Results . . . 83
4.14 Data Distribution Analysis . . . 84
4.15 Spearman’s ρ Coefficient between Power and Resource variables . . . 85
4.16 Spearman’s ρ Coefficient between Power and Resource variables . . . 86
4.17 The GQM Model for our experiments . . . 92
4.18 “Training Tools”: Scenarios Statistics - Galaxy i7500 . . . 97
4.19 “Training Tools”: Scenarios Statistics - Nexus S . . . 97
4.20 “gLCB”: Profile Statistics - Galaxy i7500 . . . 98
4.22 Smartphones power consumption comparison . . . 100
4.23 Smartphones power consumption comparison (no display overhead) . 102 4.24 Potential Energy Code Smells selected for validation. . . 107
4.25 Results of power consumption. . . 111
4.26 Results of execution time. . . 112
4.27 Sensors Description . . . 121
4.28 Sensors Events Description . . . 122
4.29 VERY LOW user profile configuration . . . 123
4.30 LOW user profile configuration . . . 124
4.31 NORMAL user profile configuration . . . 124
4.32 HIGH user profile configuration . . . 125
4.33 AUTO profile behaviour . . . 125
4.34 Battery Duration and Updates per User Profile . . . 130
2.1 The time axis: Energy Life Cycle . . . 7
2.2 The space axis: Nodes and Infrastructure . . . 9
2.3 Comparison of different energy consumptions . . . 12
2.4 The global footprint by subsector 2002 . . . 13
2.5 The global footprint by subsector 2020 . . . 13
2.6 PC, Servers, and Mobile Phones production vs. Carbon Emissions . . 14
2.7 Electrical Energy consumption of IT devices based on Figure 2.2 . . . 14
2.8 Typical energy consumption of PC components based on [72] . . . 15
2.9 Phases and Energy Costs . . . 20
2.10 CPU Frequency and TDP trend . . . 21
2.11 Typical data centre monthly costs distribution [15] . . . 21
3.1 Framework for Energy-Efficient Software Strategies . . . 33
3.2 Hierarchical quality model structure . . . 38
3.3 Hierarchical representation of the model described in TABLE 3.1 . . . 41
4.1 Instant power consumption over time (Server 1) . . . 58
4.2 Instant power consumption over time (Server 2) . . . 58
4.3 Instant power consumption over time (Server 3) . . . 59
4.4 Probability density function estimation (Server 1) . . . 60
4.5 Probability density function estimation (Server 2) . . . 60
4.6 Probability density function estimation (Server 3) . . . 61
4.7 Qaliber Test Builder screenshot . . . 76
4.8 The PloggMeter device . . . 76
4.9 The WattsUp Pro ES device . . . 77
4.10 Per-scenario Power Consumption average values . . . 82
4.11 Per-scenario Power Consumption increase with respect to Idle . . . . 83
4.12 Box Plots of Scenario Categories . . . 84
4.13 Per-scenario Power Consumption increase with respect to Idle (in %) 87 4.14 Instant Power Consumption (avg values) comparison . . . 100
4.15 Instant Power Consumption (avg values) of gLCB energy profiles . . 101
4.17 Circuit built to measure the power consumption. . . 109
4.18 Sampling current intensity: an example. . . 110
4.19 Context Awareness Platform: from raw data to high-level information 117 4.20 Context Awareness Platform: actors . . . 118
4.21 LCB sensors management . . . 119
4.22 A screenshot of gLCB log activity . . . 126
4.23 BatterySwitch . . . 127
4.24 Circuit developed to get instant power consumption values . . . 128
4.25 Discharge battery curves per user profile . . . 130
4.26 Update frequency vs. discharge time . . . 131
4.27 Box Plot of profiles average instant power consumption . . . 132
4.28 Energy Consumption Data Flow . . . 134
Summary v Acknowledgements viii 1 Introduction 1 1.1 Research Goals . . . 1 1.2 Methodology . . . 3 1.3 Thesis Outline . . . 4 2 Background 5 2.1 Taxonomy . . . 7
2.1.1 IT Energy Life Cycle . . . 7
2.1.2 IT Elements and Infrastructure . . . 8
2.2 Energy Benchmarks and Metrics Assignment . . . 8
2.3 Energy Consumption and Carbon Footprint . . . 11
2.3.1 Worldwide space dimension . . . 12
2.3.2 Local space dimension . . . 15
2.3.3 Time dimension . . . 18
2.3.4 Considerations . . . 22
2.4 Energy Efficiency: guidelines . . . 22
2.4.1 Infrastructure . . . 22 2.4.2 Application . . . 23 2.4.3 Operating System . . . 26 2.4.4 Hardware . . . 27 2.4.5 Network . . . 28 2.5 Considerations . . . 28
3 Energy consumption and quality models 31 3.1 Energy Consumption Measures and Profiling . . . 31
3.2 Software Power Profiling Tools . . . 33
3.2.2 ARO . . . 34
3.2.3 Power TOP . . . 35
3.2.4 Intel Energy Checker . . . 36
3.2.5 PowerTutor . . . 36
3.3 Energy as a non-functional requirement . . . 37
3.3.1 SQALE . . . 38
3.3.2 Tailoring SQALE quality model to include Energy efficiency . 42 3.3.3 Considerations and Future Work . . . 48
4 Empirical Studies 51 4.1 Datacentres . . . 52
4.1.1 Context of the analysis . . . 52
4.1.2 Analysis Results . . . 56 4.1.3 Considerations . . . 62 4.2 Desktop PC . . . 64 4.2.1 Background . . . 64 4.2.2 Study Design . . . 67 4.2.3 Results . . . 79 4.2.4 Discussion . . . 87
4.2.5 Considerations and Future Work . . . 88
4.3 Mobile . . . 89
4.3.1 Study Design . . . 91
4.3.2 Goal Description and Research Questions . . . 91
4.3.3 Variable selection . . . 92
4.3.4 Preliminary Data Analysis . . . 97
4.3.5 Discussion . . . 101
4.3.6 Considerations and future work . . . 102
4.4 Energy Code Smells: background and definition . . . 104
4.4.1 Validation of Energy Code Smells . . . 105
4.4.2 Potential Energy Code Smells selection . . . 106
4.4.3 Experiment setup . . . 108 4.4.4 Analysis methodology . . . 110 4.4.5 Results . . . 111 4.4.6 Discussion . . . 112 4.4.7 Considerations . . . 113 4.5 Self- adaptation . . . 114
4.5.1 Context Analysis Layer . . . 116
4.5.2 gLCB . . . 119
4.5.3 Validation Criteria . . . 126
4.5.4 Results . . . 127
Chapter 1
Introduction
Greenhouse gas emissions and Power Consumption are problems of relevant impor-tance. The EU has identified the ICT industry as the most important actor in the 20-20-20 challenge: it is estimated that the ICT sector can reduce global emissions from all sectors of 15% by 2020. However, the environmental impact of ICT is not only positive: ICT was responsible for 10% of energy demand in 2010 and for 2% of global CO2 emissions (expected to grow to 8% in 2020) [103]. The energy impact of ICT was often analysed in the context of embedded systems, where energy efficiency is a key point; so far, little research on collection and analysis of power consumption data, at the application level, exists [22] [63]. As said above, energy consumption is usually analysed at the hardware and low-level software level. Little research is available on the software application level. The project concentrates on the appli-cation level, with an experimental approach to discover and modify characteristics that waste energy.
1.1
Research Goals
This dissertation is written according to the following research goals. It also provides a detailed analysis of the state of the art, which defines a taxonomy to classify papers; all this with the aim of being able to repeat the same work after a few years to compare how the data vary.
RG1. Is it possible to measure the energy consumption of an application?
Measuring the energy consumption of an electronic device (PC, mobile phone, etc.) is straightforward, but several applications coexist on it, possibly with very different energy needs. Usage profiles for applications are certainly important too. The most
common platforms are Windows, Linux, and Mac Osx1. Within an application, we
can identify two layers: the application layer and the platform layer, in turn divided into the Operating system and devices. The first question is if it is meaningful to trace the consumption of applications to layers. If this is not feasible, then energy consumption (and the efforts to reduce it) should consider the platform layer only [23].
RG2. Could Energy Efficiency be considered as a software non-functional requirement?
Research has increasingly focused on improving the Energy Efficiency of hardware, but the literature still lacks in quantifying accurately the energy impact of software. This research goal is strictly related to the following one.
RG3 Is it possible to profile the energy consumption of a software appli-cation?
An empirical experiment could assess quantitatively the energetic impact of soft-ware usage by building up common application usage scenarios (e.g.: Skype call, Web Navigation, Word writing) and executing them independently to collect power consumption data. Based on the use of PCs, the resources are used differently. It is necessary to identify the profile of use of the systems and verify if and how energy consumption varies.
RG4. Is there a relationship between the way a program is written and its energy consumption?
The same application, at the code level, can be written in different ways. Here the question is if the different ways have impact on energy consumption. The code should be considered at two levels: source code (programmer) and object code/byte code (compiler) [88].
• RG4.1. Can we identify energy smells in the source code? A code smell is a characteristic of a source code that is considered negative and that could represent a cue of a fault. Smells can be both at design level and at code level. With energy smell we want to define a particular code or design pattern, which can impact on the energy efficiency of an application.
• RG4.2. Can we refactor energy smells in the source code? Often a smell is linked to a refactoring action, that is proposed to fix the smell and
1
1.2 – Methodology
improve properties of the software module, such as maintainability, compre-hensibility, reliability, performance. If it is possible to identify, automatically or manually, the energy smells, a refactoring action should be defined for each smell found.
• RG4.3. Is it possible to analyse statically the source code of an application in order to classify its energy efficiency? The static code analysis should identify energy inefficient situations of the source code. If so, we can evaluate the energy efficiency of the source code that is analysed.
RG5. Is it possible to use the energy consumption information to trigger self-adaptation?
A software application could automatically modify its behaviour in order to reduce its energy consumption.
1.2
Methodology
The methodology utilised is Empirical Software Engineering. The Empirical Soft-ware Engineering (EMSE) research can be applied using two paradigms: qualitative and quantitative research. Qualitative research studies objects in their natural set-tings, and phenomena are explained by eliciting explanations from people. This approach is for construction of perspective-based results and reflects the question “Why?”. Quantitative research focuses on the quantification of a relationship or a comparison of two or more groups. This type of research answers the question “How?”. The two approaches are complementary and are often mixed or alternated in research. Both approaches provide a set of methodological tools defined by Shull et al. [91] as a set of organising principles around which empirical data is collected and analysed. These tools are called empirical strategies by Wohlin et al. [106], kinds of empirical studies by Juristo et al. [52] and “research methods” by Shull et al. [91]. The first two authors identify three methodological tools (experiments, surveys, case studies), and the latter one adds two more tools (ethnographies and action research). Below are presented the tools as defined by Shull et al. [91].
• Survey: it is used to identify the characteristics of a broad population of individuals. It is conducted through the use of questionnaires, structured in-terviews, or data logging techniques. One important step in survey researches is the identification of a representative subset of the population, since usually it is not possible to poll every member.
• Case study: it investigates a phenomenon within its real-life context, offer-ing in-depth understandoffer-ing of how and why certain phenomena occur, thus
investigating cause / effect relationships (qualitative research). Exploratory case studies are used as initial investigations of some phenomena to derive new hypotheses and build theories, while confirmatory case studies are used to test existing theories.
• Controlled experiment: it is an investigation of a testable hypothesis where one or more independent variables are manipulated to measure their effect on one or more dependent variables. Each combination of values of the independent variables is a treatment. True experiments are not always possible in SE (e.g., full randomisation is often not achievable in real contexts); in that case quasi-experiments can be conducted (for instance, the subjects are not assigned randomly to the treatments).
• Ethnography: this method focuses on the sociological aspects. Ethnogra-phies study a community of people to understand how the members of that community make sense of their social interactions. For software engineering, ethnography can help to understand how technical communities build a cul-ture of practices and communication strategies that enables them to perform technical work collaboratively. A special form of ethnography is participant observation, where the researcher becomes a member of the community being studied for a period of time.
• Action Research: in Action Research, the researchers attempt to solve a real-world problem while simultaneously studying the experience of solving the problem, intervening inside the real contexts to improve the situation.
This work has been carried out by using: Case Study, Controlled Experiment, and Action Research.
1.3
Thesis Outline
The contributions of this PhD program can be summarised in four points: 1. Literature review: described in Chapter 2;
2. Analysis of energy consumption as a non-functional requirement: described in Chapter 3;
3. Characterisation of the energy consumption of software applications and sys-tems with an empirical approach; identification of software characteristics that waste energy: described in Chapter 4;
Chapter 2
Background
The rapid growth and significant development of IT systems has started to cause an increase of worldwide energy consumption [103]. This issue moved technology producers, information systems managers, and researchers to deal with energy con-sumption reduction in terms of:
• Global CO2 footprint;
• Consumption of data centres;
• Reduced battery life of portable devices;
• Economic impact of a new business model, which aims at greening everything. As well described in [59], IT producers are forced to manage the product lifecycle through legislation, but also users are becoming concerned about the environmental implications from the use of IT. This area of research is called GREEN IT, which “refers to environmentally sustainable computing or IT1” and is defined as “The
study and practice of designing, manufacturing, using, and disposing of computers, servers, and associated subsystems such as monitors, printers, storage devices, and networking and communications systems efficiently and effectively with minimal or no impact on the environment” [74]. Murugesan in [74] also expresses the benefits introduced by Green IT: “Green IT benefits the environment by improving energy efficiency, lowering greenhouse gas emissions, using less harmful material, and en-couraging reuse and recycling”. Taking into account the research areas identified in [19] and according to [74], the main topics related to Green IT, are:
• Design for environmental sustainability: “balancing energy and resource sav-ings by ICT and energy and resource consumption of ICT” [76] and “making business operations, buildings, and other systems energy-efficient” [75];
1
• Energy-Efficient Computing: the efficient use of resources in terms of energy-aware algorithms;
• Power Management: a set of HW/SW techniques that optimise the man-agement of power resources in computer systems, portable devices, and data centres.
• Data centre design: eco-friendly devices that improve energy efficiency and energy conservation of data centres (i.e., energy-efficient mechanical and elec-trical systems, green power, use of natural light, etc.);
• Virtualization: “the faithful reproduction of an entire architecture in software, which provides the illusion of a real machine to all software running above it” [56];
• Disposal and recycling management: managing e-waste, and limiting planned obsolescence upgrading devices instead of replacing them;
• Regulatory Compliance: Regulatory requirements and legislative actions tend to force acceptance of a technology or practice in situations where this would not occur. The existence of certain rules on sustainability in IT standards can lead to the adoption of some green IT initiatives [71];
• Green metrics, tools and methodology assessments: software tools for col-lecting or simulating, analysing, modelling, reporting energy consumptions, environmental risk management, environmental impact, and greenhouse gas emissions; platforms for eco-management, emission trading, or ethical invest-ing [74].
Green IT involves many areas and stakeholders, starting from governments, through new business models and R&D, to different technical fields. IT can also be used to monitor energy consumption such as: heating systems in buildings, fuel efficiency in cars or smart grids implementation. So IT is involved in worldwide energy reduction, and in reducing its energy consumption as well. The main contribution of this work is to summarise evidence available in the literature about:
• Measuring techniques for energy consumptions in IT systems;
• IT energy consumption trend according to our taxonomy;
• Methodologies to reduce energy consumption of IT;
The goal is to offer a clearer picture of the state of the art in this field, and to highlight areas where evidence is missing as well [9]. This chapter is organized as follows:
2.1 – Taxonomy
• Section 2.1 proposes our taxonomy.
• Section 2.2 deals with the energy metrics, which are used to characterise more quantitatively what “greenness” means at each layer of the taxonomy.
• Section 2.4 describes some guidelines that can improve energy efficiency in IT systems.
• Section 2.5 gives our conclusions.
2.1
Taxonomy
We define the following taxonomy to organize IT and energy consumption. We consider two orthogonal dimensions, the time axis (or IT energy lifecycle) and the space axis (IT elements and infrastructure).
2.1.1
IT Energy Life Cycle
Inspired by [32] we propose the energy life cycle in Figure 2.1. The activities in the lifecycle are design of the IT product, manufacture, transport (includes packaging and distribution), use, disposal, and possibly recycling. All these activities consume materials and energy, with related emissions.
2.1.2
IT Elements and Infrastructure
On the spatial axis, we consider elements or nodes (e.g. PC, peripheral devices and mobile phones) and their connections (cables, wireless links etc.) to build infrastructures (e.g. PC networks, the Internet, data centres, the cloud). In a node, we define different layers (starting from hardware to application) as defined later (Figure 2.2)
• Network element: this element considers network equipment (e.g. Network Interface Card, router and gateways) and protocols, which means everything is related to connectivity.
• A node element consists of three layers:
– Hardware layer: this layer considers CPUs, GPUs, and storage (memory, disks).
– Operating System layer: this layer considers software programs imple-menting the traditional operating system services (file and memory man-agement, task scheduling, I/O management). The key issue here is power management.
– Application layer: this layer considers software to implement user level services. Key issues considered here are the energy efficiency of algorithms and software architectures.
• Infrastructure element: This element considers many nodes connected by a network to define a larger entity capable of offering higher-level computation services. Entities of this kind are data centres, web farms, and cloud comput-ing.
2.2
Energy Benchmarks and Metrics Assignment
Energy (measured in Joule or Wh) and power (measured in J/s or W) are the metrics, which can be used to characterise consumption of IT and ICT systems. However, they are not specific to IT. In literature, other specific measures have been proposed. We can summarise them into three broad categories:
• Power, in terms of consumed Watts.
2.2 – Energy Benchmarks and Metrics Assignment
Figure 2.2. The space axis: Nodes and Infrastructure
• Productivity, defined, at high level, on a production process, as output/re-source on a time interval (ex. cars produced per worker in a day). In the context of Energy and IT, the output is computational work while the re-source is energy. Computational work needs to be defined at each level of the taxonomy. For instance: in a CPU, an example may be operations performed, in a network bits transmitted, in a web application hits managed.
Table 2.1 reports measures proposed in literature [84], [17] and [39] placing them in our taxonomy and categorising them as efficiency or productivity. Not all layers of the taxonomy are covered, meaning that other efficiency or productivity measures could be defined.
Table 2.1: Energy Metrics and Benchmarks
Layer Category Unit Description Example
Infr Productivity Useful
work/W Green Grid Data-centre Performance Efficiency (DCPE) [38] Aims at measuring “Useful work” de-livered by a data
centre vs. the
power used
Infr Efficiency % Useful
Power (for storage, compu-tation, communica-tion) / Total power Green Grid Data-centre Ef-ficiency(DCE) [38]
Node Productivity MFLOPS/W
or FLOP/J Number of Float-ing point operation computed per watt
The Green 500 list2
ranks high
perfor-mance computers
on MFLOPS/W,
instead of the usual ranking on FLOPS only
App Power W Power used
by an appli-cation on a node Joulemeter [54] is a tool able to estimate instant power consump-tion of PCs and applications 2
2.3 – Energy Consumption and Carbon Footprint
App Productivity Operation /
J Output is intended as sorted records Joule Sort [83], counts sorted
records per Joule,
and is a
bench-mark for sorting
algorithms. It is a variant of Sort
benchmark that
considers records sorted per second
OS Power W Power used
by an OS or an app on a node Softwatt [42] is a tool to estimate power used by OS and applications HW Power W SimplePower 3 Given an tion (or an
instruc-tion set) and a
program, it esti-mates energy
con-sumption on the CPU). Network Efficiency % 100(MI)/M I = energy consumption at idle, M energy at maximum Environmental Performance Index (EPI) [67]
Network Productivity KB/J KB
trans-ferred per
Joule over a channel
Energy-efficiency rating (EER) [21] does the same in Gbps/W
2.3
Energy Consumption and Carbon Footprint
A lot of data has been published on IT-related consumption and emissions. However these data are usually sparse. In this section we summarise them using the taxonomy
3
as a unifying point of view. In 2.3.1 we review data at a global level, then we will focus on the space and time view (2.3.2, 2.3.3), and further on.
IT is responsible for very limited percentages of consumptions and emissions as described in Figure 2.3 (less than 1% consumption of primary energy, around 3% of electrical energy, 2% of carbon emissions). However, an analysis of future trends shows that emissions and consumption tend to increase. At this level much work should be done to stabilise and possibly reduce these trends, in order to provide a sustainable IT future. The analysis performed before considers the whole of IT. In the following table, we analyse the problem considering the spatial and time dimensions, as introduced by the taxonomy.
Figure 2.3. Comparison of different energy consumptions
2.3.1
Worldwide space dimension
Focusing on the IT sector, a key question is which IT components are responsible for these trends. We start from individual components (or nodes such as PCs, fixed and mobile, and data centres) and we conclude with networks.
Node view (PCs, Laptops, Mobile Devices) and Data Centres
According to [103] we report some numbers about the number of different class of devices and their consumption from 2002 to 2020. The number of worldwide PCs is expected to grow from 592 million (2002) to more than 4 billion (2020) and, regarding energy consumption, laptops will overtake desktop computers by 2020. In 2002, emissions of PCs and monitors were 200 MtCO2e, growing to 600 MtCO2e by 2020. The number of servers in 2002 was 18 million and there will be a sharp increase of this figure up to 122 million in 2020. In 2002 data centre emissions were approximately equal to 76 MtCO2e and this value should more than triple by 2020 to 259 MtCO2e. In 2002 there were 1.1 billion mobile devices. This is expected to grow to 4.8 billion in 2020. Telecommunications emissions rise from 150 MtCO2e in 2002 to about 350 MtCO2e in 2020. Figure 2.4 represents the carbon emission in
2.3 – Energy Consumption and Carbon Footprint
2002 [103], and Figure 2.5 reports an estimate, based on [103] of carbon emissions by IT by 2020.
Figure 2.4. The global footprint by subsector 2002
Figure 2.5. The global footprint by subsector 2020
The majority (57 percent) will come from PCs, peripherals, and printers, while data centres account for 25% only. Figure 2.6 compares the growth of devices produced and the growth of carbon emissions [103].
From the analysis above it is clear that PCs and mobile devices are the key factors in consumption in the future. Another study [48] stated that data centres in 2009 consumed about 330 TWh worldwide, and authors in [94] estimated the electrical energy consumption of PCs, laptops, and mobile phones in 2009:
• PCs: 163.2 TWh
• Laptops: 46.2 TWh
• Mobile Phones: 44.6 TWh
These data are calculated in terms of electrical energy consumed and cannot be compared with data in Figure 2.4 because of different units, years, and data aggre-gations.
Figure 2.6. PC, Servers, and Mobile Phones production vs. Carbon Emissions
Network view
The number of Internet users has continuously increased, and the energy consump-tion of the Internet has grown accordingly. Network equipment such as hubs, switches and routers for the Internet consumed energy of about 6.05 TWh/year in 2010 as shown in Figure 2.7 and it is expected to grow by 1 TWh or more per year.
2.3 – Energy Consumption and Carbon Footprint
In addition, the network equipment that connects to the Internet in home and office networks transmits packets via Ethernet links. The estimated energy con-sumption of Network Interface Cards (NICs) and other network devices, which use Ethernet links in the US, was approximately 5.3 TWh/yr in 2005 [77]. Moreover, the default link rate of the Ethernet and the network edge devices is rapidly increasing from 10 Mbps to 1 Gbps or more, and the number of network devices is also increas-ing [16]. To sum up, based upon our taxonomy, most of the energy consumption is concentrated within data centres and nodes. Network devices have a less important role but not negligible because of the magnitudes involved.
2.3.2
Local space dimension
Within a Node
In Figure 2.8 we analyse consumption inside a node [72].
Figure 2.8. Typical energy consumption of PC components based on [72]
from the hardware perspective, is seen as a different trend of the instant power consumed by the device. There are several (and canonical) ways to gather energy consumption data from a hardware device and we cite four examples. In 1998 au-thors of [87] stated that the current drawn by a processor could be measured using an oscilloscope with a shunt resistor, connected in series with the supply voltage pin of the microprocessor. It is also possible to perform a direct (current) measure by util-ising an ammeter with a high frequency signal to obtain a stable value [97]. In [58] the authors connected a multimeter to a laptop power supplier. They also plugged the laptop supplier into a universal power supply (UPS) to filter out voltage fluctu-ations. Their multimeter sampled the current 11-12 times a second. Otherwise it is possible to use smart meters; some commercially available products are Plogg Me-ter4, Kill-a-Watt / Tweet-a-Watt5, and SmartLink6. They aim more at monitoring,
controlling, and automating the attached device. It is very difficult to find reliable values about CPU power consumptions. Usually manufacturers publish the “Ther-mal design power” (TDP). This value does not match the maximum CPU power consumption but it refers to the maximum amount of power that the cooling system in a computer has to dissipate and the result is expressed in Watts. These values are not comparable between CPUs produced by different manufacturers. AMD intro-duced a new metric (called ACP) to measure the CPU power consumption [7]. ACP is obtained by measurements taken on specially instrumented components in partic-ular conditions (temperature, workloads, configurations). In [51] authors analysed the problem of estimating system power consumption. They stated that for each task, it is possible to measure the number of clock cycles executed per unit time and generate a model that can predict the watt consumed: P(System) Power(Taski) + P(bias’) Where bias’ equals every other component and Power(Taski) = F * number of FP Cycles + I * number of Int Cycles + M *number of Memory Cycles. Au-thors in [47] studied deep server hard drives (3.5) energy consumption, both from a mechanical and electronic perspective. Based on their studies, drive platters spin constantly, they stop only in standby mode; read/write heads are only powered dur-ing the readdur-ing and writdur-ing phase. The arm actuator is only powered when there is the need to seek across locations on a platter. Printed circuit board electronics are instead always powered. Based on ATA/ATAPI-5 specification and the Advanced Configuration and Power Interface (ACPI), modern hard drives support four power management states: active, idle, standby, and sleep (it is not possible to recover from this state without a system reset). In standby mode, mechanical energy savings may
4http://www.bytesnap.co.uk/bytesnap-design-case-studies-the-plogg-smart-energy-meter/
Last Visited: 11 Apr 2013
5
http://www.ladyada.net/make/tweetawatt/Last Visited: 11 Apr 2013
6
2.3 – Energy Consumption and Carbon Footprint
range from 92 % to 99% and electronic components energy saving may span from 35% to 95%. In idle mode mechanical components can consume from 25% to 75% of the total energy consumption. During the read/write phase the energy consump-tion is dependent on the Logical Block Number (LBN). Data density increases at higher LBNs and more time is required to recover the data (due to constant angular velocity of the spindle), read bandwidths decreases and read energy consumption increases. But write bandwidths remains fairly constant because write requests are not influenced by the varying data density on the platters, hence bandwidth and energy consumption do not vary on the basis of LBN. In general, reading consumes more energy than writing for blocks larger than 2KB, and writing is more energy intensive than reading for blocks smaller than 2KB.
Disk Model Cap. Read Write Read Write Idle Efficiency
Unit GB MiB/s MiB/s W W W MiB/j
SSD Intel X-25E 32 226 198 1.7 2.7 0.6 103 Intel X-25M 80 225 79 1.0 2.5 0.6 128 Samsung PB22-J 256 201 180 1.1 2.8 0.6 124 Super Talent FfM56GX25H 256 235 163 1.6 2.9 0.5 102 HDD Samsung HD502HI 500 106 108 6.6 6.6 3.7 16 Samsung HM500JI 500 87 87 2.3 2.3 / 28 W.D. WD7500KEV 750 82 82 2.0 2.0 / 41
Table 2.2: Energy Metrics and Benchmarks
The energy consumed during seeking is minimal, but restricting disk accesses between low and central LBNs could help to save energy in long usage periods. Solid-state drives have different power consumption profiles and efficiency as shown in Table 2.2. Authors in [86] analysed energy consumption of office and telecommu-nications equipment in commercial buildings. They divided monitors and printers into categories. Table 2.3 and Table 2.4 show the energy consumption of moni-tors divided into two categories: CRT and LCD. Over the years monimoni-tors show an increase of performance and a decrease of energy consumption.
Type -CRT
Active Standby Suspend Off
14-15” 61 53 19 3
17” 90 26 9.2 4.3
19” 104 31 13 4
21” 135 43 14 4.7
Table 2.3: CRT energy consumption estimate [86]
Type
-LCD
Active Standby Suspend Off
13” 2.5 0.7 0.2 0.1 14” 6.7 1.9 0.7 0.3 15” 11.7 3.4 1.2 0.6 17” 16.7 4.8 1.7 0.8 18” 25 7.2 2.5 1.2 20” 31.7 9.2 3.2 1.6 21” 36 10.4 3.6 1.8
Table 2.4: LCD energy consumption estimate [86]
Within Network, Data Centres and Infrastructure
Authors in [41] examined the energy consumption of networking devices in the In-ternet, based upon data collected by the U.S. Department of Commerce. Data are available in Table 2.6.
Based upon these findings, the impact given by a reduction in consumption in this field can be relevant.
2.3.3
Time dimension
PC
Let us now analyse how these consumptions are distributed over the lifecycle of IT devices (manufacturing and transport, usage, disposal). According to [105] the energy to manufacture a PC accounts to 4250 MJ, the energy spent in usage (con-sidering an average usage time of 3 years) is 1500 MJ, and the overall energetic cost (including transport and purchase) is about 7900 MJ. Manufacturing is the most energy-hungry phase, and consequently the author suggests concentrating efforts on reusing devices to extend their average usage time.
In detail the distribution of energy consumption [73] (Figure 2.9) is as follows:
2.3 – Energy Consumption and Carbon Footprint
Device Active Standby Suspend Off
Impact Printer 36.5 16.8 N/A 1 Inkjet Printer 42.576 13.377 N/A 2.878 Laser Printer 231 28 16 1.9 Laser Printer Small Desktop 130 75 10 N/A Laser Printer Desktop 215 100 35 N/A Laser Printer Small Office 320 160 70 N/A Laser Printer Large Office 550 275 125 N/A
Table 2.5: Printer energy consumption estimate [86]
Device Approximate Number De-ployed Total AEC TW-h Hubs 93.5 Million 1.6 TW-h LAN Switch 95000 3.2 TW-h WAN Switch 50000 0.15 TW-h Router 3257 1.1 TW-h Total 6.05 TW-h
Table 2.6: Energy consumption of networking devices in the Internet [41]
• Transport: about 950 MJ (12%)
• Purchase/Use: about 1500 MJ (19%)
• Other 1200 MJ (15%)
Figure 2.9. Phases and Energy Costs
Computer has risen by 7% in comparison to 2002. This value increased from about 6420 MJ in 2002 to about 6900 MJ in 2007. About the usage phase, modern PCs consume more energy at full-load than the old ones, while in a low-power mode they take less energy than the old computers. Therefore the total energy used depends strongly on the usage scenario. Considering a home scenario, the total energy used by an average 2007 PC per year is almost the same as it was in 2002. The reduction is mainly due to CRT monitors (between 65 W-145 W when active, and 9-14 W in standby) substituted by LCD monitors (25 W when active, 2 W in standby). The increase is due to a possible increase in consumption of other components of a personal computer (graphics cards, memories, etc.) Thus, the overall (manufacturing + usage) energy consumption of PCs has increased over the last 10 years. According to the Wikipedia definition 7, despite not being an official source, we can draw a trend about the frequency and TDP behaviour of AMD CPUs since 1996 as described in Figure 2.10.
Without taking into account punctual values we can see that over these 15 years both frequency and TDP raised respectively 7 and 3 times. We must point out that nowadays CPUs have multiple cores so TDP and Power Consumption are not the right metrics to measure CPUs energy efficiency.
Data Center, and Infrastructure
According to [15], the major challenge in energy reduction talking about “Cloud Computing” is the relation among system components and an optimal balance be-tween performance, QoS, energy consumption, and self-aware runtime adaptation.
7http://en.wikipedia.org/wiki/List_of_CPU_power_dissipation Last Visited: 11 Apr
2.3 – Energy Consumption and Carbon Footprint
Figure 2.10. CPU Frequency and TDP trend
Amazon [44] calculated that the cost and operation of servers amount to 53% of their total budget, while energy-related costs reach 42% of the total. Figure 15 shows a typical monthly cost distribution in a data centre.
Figure 2.11. Typical data centre monthly costs distribution [15]
According to [57], the electricity used in global data centers in 2010 accounted for between 1.1% and 1.5% of total electricity use. This means that data centers are using less energy than predicted by Environmental Protection Agency in 2007.
2.3.4
Considerations
As a conclusion, an analysis of the trends in IT energy consumption and emissions shows that the IT sector is responsible for a minority of them. However, the trend is increasing, due to the large increase in the number of individual IT devices (PCs and mobile phones), and the increase in energy used to manufacture them and, in using them. It is a responsibility of the IT sector to research ways to become sustainable, and to further reduce emissions and consumption, especially at the level of individual devices.
2.4
Energy Efficiency: guidelines
As shown in Section 2.2, the literature proposes many tools to measure Energy Ef-ficiency of IT devices and data centres. There are many works aimed at reducing the consumption of PCs in enterprise environments [5] [6], or to manage the use of green energy in datacentres [36] [34] [35] [90] [92], or to optimize the consumption of idle server [70]. The next point is how to obtain Energy Efficiency also by software, thus considering the OS and application layers and not only the hardware layer. We have surveyed the literature and we have found guidelines from Intel and Siemens [53] [95] [61] and also from Academy [40]. Most of the guidelines suggested in the literature are not strictly code-related, but they are mainly high-level recommen-dations for programmers and software designers (e.g. to implement lazy loading of libraries). However, it is worth mentioning that such guidelines, despite being intu-itive and acknowledged as effective by software industry specialists, did not receive any empirical validation. For this reason, an empirical validation that quantitatively assesses their impact on Energy Efficiency is needed. We summarise these guidelines below, according to the taxonomy proposed in Section 2.1.
2.4.1
Infrastructure
1. Consider Cloud Platforms for energy-efficient Internet applications: Cloud platforms use virtualization. This should improve energy efficiency of the internet application [61].
Pros:
• Reduced costs.
• Hardware reduction.
• Less Power Consumption.
2.4 – Energy Efficiency: guidelines
• Single point of failure.
• Lower performances.
2. Load balancing: Distributing workload evenly across two or more computers, network links, CPUs, hard drives, or other resources.[40] reduces the CPU temperature
Pros:
• Reducing the use of a mobile device can increase its average battery lifetime.
Cons:
• Load balancing can be difficult to accomplish.
3. Provide information for system management tools to support over-all optimisation: The use of power meters and energy-aware applications provides information relating to the infrastructure energy consumption. This data should be used as an input to support the energy optimization [53].
Pros:
• Instant Power consumption is available as a Context Information [12].
Cons:
• This solution requires dedicated hardware.
• The instant power consumption information must flow from the hardware layer through the application layer. It is necessary that all the layers are prepared to handle this information.
2.4.2
Application
1. Design Efficient UI: Efficient UIs can let the user complete a task quickly. An inefficient UI can increase the application complexity, and consequently the energy consumption [40].
Pros:
• An efficient UI may improve the energy consumption of the entire ap-plication by simplifying the interaction with the user, and reducing the time required to perform a specific operation
Cons:
• It requires an empirical validation of the changes.
2. Use Event-Based Programming: Event-based programming avoids a waste of resources involved in doing unnecessary operations. If polling cannot be avoided, it is advised to select a fair time interval [40] [53] [61].
Pros:
• The application is put to sleep when not used.
Cons:
• The application may need to be redesigned.
• It is not always implementable.
3. Use low-level programming and avoid use of byte-code: With low-level programming languages, developers have more details of the system which she/he is developing, than when using high-level programming languages. When possible, it is advised to develop the more computationally intensive parts of the application at a low-level. Programming languages to increase performances and energy efficiency. The virtual machine interpretation of byte code can make the application energy inefficient [40] [61].
Pros:
• The developer has a greater control of the underlying hardware by devel-oping at a lower level of abstraction.
Cons:
• Can be expensive in terms of costs and development time.
• Not always possible.
4. Batch I/O: Buffering I/O operations increases energy efficiency; the OS can power down I/O devices when not used.[40] [53] [61]
Pros:
• Known technique already used for generic optimisations.
Cons:
• Not always possible. It depends on the application context.
5. Code Migration: To increase energy efficiency in devices where computation can be energy consuming, it may be worth moving the task to another energy-efficient environment and gathering results when available.[40]
2.4 – Energy Efficiency: guidelines
• It simplifies the “client-side” code.
Cons:
• It is needed to consider the overheads due to the use of another system, which performs complex operations.
6. Reduce data redundancy: Storage and transportation of redundant data lowers energy efficiency.[40]
Pros:
• To be applied during the design phase.
Cons:
• A later change to an existing implementation can cause the modification of a large part of the application.
7. Reduce QoS/Scale dynamically: The application has to be able to change its behaviour in case of low-power situations.[40] [53] [61]
Pros:
• The creation of user profiles can save energy [12]
Cons:
• It needs metrics.
• The QoS reduction is not always possible.
8. Use Power/energy profiling tools: This kind of application models the energy behaviour of the system in which it is run. This model should help the developer to optimise the application energy usage [53].
Pros:
• With these tools it is possible to create energy consumption models, which help to predict the energy consumption in different situations.
Cons:
2.4.3
Operating System
1. Implement Power Management APIs: The Operating System can export power management APIs to enable applications to manage energy efficiency at lower levels.[53] [61]
Pros:
• APIs are easily used by the application layer.
Cons:
• Needs OS modification.
2. Optimal use peripherals: The use of a correct power management feature exploits properties and characteristic of peripherals[40]
Pros:
• The OS can use the peripherals in different operating modes.
Cons:
• Manufacturers have to create drivers that allow the OS to use the device in different operating modes.
3. Use Compiler Optimisation: The Compiler can optimise the source code according to specific platform architecture.[61] [40]
Pros:
• Low developing costs.
Cons:
• Not all the architectures can get the same optimisations.
4. Use only required services and background processes: Unused appli-cations waste memory, resources and energy. [61]
Pros:
• It is possible to free resources used by unnecessary idle processes.
Cons:
2.4 – Energy Efficiency: guidelines
2.4.4
Hardware
1. Power down peripherals: Peripherals can be storage, I/O, or network de-vices, GPS modules, etc. When not in use they should be set to a low power state or shut down. [40]
Pros:
• The upper layers improve their performance in terms of energy consump-tion transparently.
Cons:
• It is needed to limit the overheads caused by the transition between ON and OFF.
2. Use specific-purpose hardware: A general-purpose hardware can be over-sized for the specific problem. Overover-sized hardware can be translated in energy inefficiency. [53]
Pros:
• Maximum optimisation of energy consumption for the current device.
Cons:
• High costs.
3. Dynamic Power Management Capabilities: Exploit features such as ACPI, processor and idle management, configurable high performance vs. low power components, to manage energy consumption. [53]
Pros:
• It provides to higher layers different configurations to save energy.
Cons:
• It is needed to redesign devices.
4. Power/ Energy metering support: Hardware metering support is often needed by profiling tools to get a reliable estimation of device power consump-tion. [53]
Pros:
• Provides information about the instant energy consumption of the device to the upper layers.
Cons:
• High costs.
2.4.5
Network
1. Efficient data traffic: Sending less data over the network can reduce energy consumption because the network interface is left in idle for more time [40].
Pros:
• This action can also improve the application performances.
Cons:
• In order to send less traffic, the application architecture could be deeply modified.
• It is necessary to take into account the additional computation needed to implement data compression, proxying, etc.
2. Energy impact of communication protocols: An energy-efficient com-munication protocol can reduce the amount of information exchanged.[53]
Pros:
• If a protocol is designed to reduce the amount of data exchanged to es-tablish a communication, its correct implementation can give advantages in terms of energy consumption.
Cons:
• It is needed to modify/extend the existing protocols.
2.5
Considerations
Green IT is becoming a popular topic, but no specific surveys are available yet. In this paper we reported a survey of the literature about Energy Consumption & IT systems, starting from the viewpoint of Green IT. The survey has been performed searching for the following keywords: “Green IT”, “ICT Energy Consumption Re-duction”, “Energy Efficiency”, “Energy Measurement”, “Power management”, “En-ergy Consumption Analysis” in the following databases: IeeeXplore, ACM digital library, IET Electronic Library and, more generally, Google Scholar. In order to organise the large number of papers found we have defined a taxonomy, based on two axes, the time axis (with activities such as design, manufacture, transport, use,
2.5 – Considerations
dismiss and possibly recycle) and the space axis (with physical components of vary-ing sizes, from larger to smaller: the clouds, data centers, computvary-ing nodes such as PCs, smartphones and mobile phones, applications, OS and hardware). In 2007 IT electrical energy consumption in the usage phase is reported to be 830 TWh or 0,5 % of the total. In percentage this is a minimal amount; however, in absolute terms it is relevant. Besides, estimates of IT consumption in the future show a fast-growing trend. While we do believe that these figures are a good starting point, it should be noted that the accuracy of data reported is questionable. For sure consumption data is in many cases referred to several years ago (2007, 2009 for IT consumption) and their precision is not reported. As regards to this, a lot of work should be done to define and standardise the way consumption data is collected and reported. A first observation on the space axis is that there is no agreement on how to consider smart phones and mobile phones in general. Sometimes papers do not include them (strict IT and Green IT), sometimes they do (ICT and Green ICT), and sometimes the point remains fuzzy. Overall our point of view is that, considering the convergence of mobile phones into Internet nodes, they should be included. Besides, nowadays the production (and therefore the related consumption) of mobile phones is much larger than that one of computers. Most of the literature is about the space axis, and mainly about the usage phase. However, considering PCs at least, a study [72] shows that the main contribution (about 50%) of energy consumption of a PC is due to the design/manufacture phase while the usage phase contribution represents only 20% of the total. The energy consumption of the usage phase, which currently does not reach 1% of the total, can be considered the one in which it is possible to intervene in a more distributed way. Small and distributed energy reductions can lead to large reductions worldwide. For this reason, an intervention on energy consumption reduction from a software point of view is to be considered interesting. We did not find similar studies on mobile phones or data centres. However, if the trend is confirmed, efforts to reduce energy consumption should concentrate on the manufacturing phase and/or on increasing the duration of the usage phase. Again considering the space axis, in 2009 data centres are the main users of energy (330 TWh) followed by (PCs, smartphones, tablets) (254 TWh) and network equipment (6TWh). From these figures is clear that data centers and PCs/smartphones should be the focus for energy consumption reduction during the usage phase. After this data collection and analysis phase, we have focused on methods and techniques to reduce energy consumption. In this regard we need precise ways to measure if con-sumption is actually reduced. So before all we have summarised the measures that can be used. Besides the obvious ones (energy and power) we have surveyed what has been proposed, and placed it into our taxonomy. Basically all measures pro-posed by different authors can be classified as measures of efficiency or productivity, applied to a node of the taxonomy in the usage phase. For instance efficiency for a data centre is the ratio between energy for computation and total energy used
(including conditioning). Finally, we have surveyed for techniques (or guidelines) to reduce consumption, and organized them in our taxonomy. What is available is a good starting point, but in many cases the guidelines are quite high level, so their effect on consumption is hard to express in quantitative terms. In summary, future work by the Green IT community should be devoted to:
• Collect more precisely data about consumption, standardising the data collec-tion process;
• Collect and analyse in more depth consumption in the non-usage phase;
• Develop more extended and more detailed guidelines for energy consumption reduction;
• Validate and characterise quantitatively the effect of these guidelines.
The next chapter discusses Energy Consumption Measures and it will also in-vestigate whether Energy Efficiency is eligible to be included in a software quality model.
Chapter 3
Energy consumption and quality
models
3.1
Energy Consumption Measures and Profiling
This Chapter deals with RG1 and RG2 by analysing how to measure the energy consumption of a software application, and proposing to consider energy efficiency as a software non-functional requirement. As described in Section 2.1.2, energy (measured in Joule or Wh) and power (measured in J/s or W) are the metrics, which can be used to characterise consumption of IT and ICT systems. However, they are not specific to IT. In literature, other specific measures have been proposed. We can summarise them into three broad categories:
• Power, in terms of consumed Watts.
• Efficiency, as the ratio of useful energy and total energy used
• Productivity, defined, at high level, on a production process, as output/re-source on a time interval (ex. cars produced per worker in a day). In the context of Energy and IT, the output is computational work while the re-source is energy. Computational work needs to be defined at each level of the taxonomy. For instance: in a CPU, an example may be operations performed, in a network bits transmitted, in a web application hits managed.
More details are introduced in Table 2.1.
In any programmable device, although the ultimate responsibility of energy con-sumption is always with the hardware, the way the energy is consumed is dictated by the software. Consequently, it is necessary to draw a theoretical model of the energy consumption, which depends both on hardware specifications and the way in
which they are used by software artifacts. Theabstractmodel underlying the power consumption can be summarised as:
P ower=Idle+ ∑
c∈Components
Hwc·Swc
The total power consumption P ower of an IT device – when turned on – is composed by an Idle part that is present even when the device is sitting idle. The additional consumption depends on the individual hardware components maximum consumption Hwc which is modulated by what the software forces it to do, Swc.
Depending on the software requests the hardware component may run at full throttle or remain idle.
This theoretical software power model supports higher – software level – strate-gies for increasing software energy efficiency. As a matter of fact, it gives developers a way to elaborate a strategy by analysing the causes of energy consumption and also to validate the efficacy of the formulated strategies by measuring their impact and effect. In this chapter, a framework for energy-efficient software strategies will be introduced. The framework is represented in Figure 3.1.
The Refactoring strategy is shown on the left side. It focuses on minimizing soft-ware instructions and code patterns (Energy Code Smells) that may cause higher energy usage. This is achievable at design time, following code level guidelines, and at implementation time, detecting the Energy Code Smells. The Self-Adaptation strategy, shown on the right side of the figure, has the main goal of creating an energy-aware application that is able to choose among different configurations, with respect to different scenarios and contexts, that we call “Energy Profiles” (see Sec-tion 4.5). The two strategies are not meant to be mutually exclusive: they can be applied together in the same development process. In addition, other technological, human or process strategies can be plugged in whenever their impact is measurable and linkable to a software application and its power consumption, through modelling and profiling. Both strategies should be applied iteratively, by verifying the energy efficiency improvements, through power profiling tools, and consequently adapted. They also should be applied carefully, keeping in mind the software mission and its main functionalities, the required quality of service, and the interests of the stake-holders. For example, applying Self-Adaptation to reduce the network usage might improve energy efficiency, but it might also violate Service Level Agreements on response time or availability. Therefore, the stakeholders’ network around the soft-ware should be drawn in order to understand who might be affected by adopting such strategies.
The bottom part of the figure shows the “Response” level, meant to identify opportunities for energy optimisation and/or to assess the energy savings gained by applying our strategies. Resource usage information, such as memory accesses,
3.2 – Software Power Profiling Tools
Figure 3.1. Framework for Energy-Efficient Software Strategies
device usage, CPU mode and such, is collected from the hardware. This information is used as input for software profiling tools, that analyse software applications during execution and provide on-line power consumption estimation values with different granularity. Software power models represent a crucial component of our framework, because they enable the formulation and validation of the strategies. The software power consumption models are described in more detail in the following section, along with their implementation inside software energy profiling tools (see Section 3.2: Software Power Profiling Tools).
3.2
Software Power Profiling Tools
This section will introduce some useful tools that developers may use in order to profile the power consumption of their application. According to the framework presented in Figure 3.1 these tools are included in the “Software Profiling Tools”
block; the developer, after implementing one (or both) strategy (Refactoring and/or Self-Adaptation) can verify the energy efficiency improvements, through such power profiling tools.
3.2.1
Joulemeter
Developed by Microsoft Corp.1, Joulemeter is a software tool available for Windows platforms, which provides a power consumption estimation for PCs. It needs an initial calibration phase, which is done using battery data (on laptops) or using an external power meter (on desktops). Currently, only one meter is supported: the WattsUp Pro meter. There is also an option for manually inserting calibration values, namely idle power consumption, peak CPU consumption (for high and low frequencies) and monitor consumption. After calibration, Joulemeter provides power consumption estimation in real time, with components breakdown (CPU, monitor, disk). It is also possible to specify an application to get the estimation of a single application. The estimation error is within 3-5% of the actual value [54].
• Pros:
– Ease of use
– Per-application estimation
– Good accuracy
• Cons:
– Needs initial calibration
– Only supports a specific model of power meter
– Windows-only
3.2.2
ARO
Application Resource Optimizer (ARO) is a diagnostic tool for analysing mobile web applications performance, developed by AT&T. It is composed of two modules: the Data Collector and the Data Analyzer. With the Data collector it is possible to log data from a device: the collector must be started and then the target ap-plication is run. It is also possible to record a video in order to better understand the consequences caused by the user activity. The Data Analyzer processes the
1
3.2 – Software Power Profiling Tools
data acquired by the Data Collector and provides the following features: Visibil-ity into radio resource and energy utilisation, benchmarking of resource efficiencies, automatic diagnosis of application inefficiencies
• Pros:
– easy to use
– provides focused hints to improve the energy efficiency of the analysed application
• Cons:
– works only on rooted android devices and windows 8 devices
– does not provide real-time monitoring
3.2.3
Power TOP
PowerTOP2 is a tool designed to monitor software power consumption in Linux-based systemsby Intel Corp. in 2007PowerTOP mainly focuses on monitoring CPU states and showing to the user which software processes are responsible for setting the CPU into high power states. In this way, the tool helps in diagnosing power consumption issues and identifying energy-inefficient software. More recent versions of PowerTOP include monitoring of the activity of devices and peripherals (e.g., USB storage, WiFi modules, GPU) and support for power-management configura-tion. PowerTOP is mainly designed for battery-powered devices, where it requires a calibration phase to analyse battery discharge behavior. It uses the ACPI inter-face to collect information on how much power is effectively consumed, and it also provides an estimation of how many hours of battery are left.
• Pros:
– Per-application estimation
– Power management support
– Provides information about devices and peripherals
• Cons:
– Needs initial calibration
– Effective power consumption estimation only available on battery-powered devices
– Linux-only
2
3.2.4
Intel Energy Checker
Intel Energy Checker3 is an SDK developed by Intel Corp., designed for application developers who want to build energy-efficient or energy-aware software. It is avail-able for the most common platforms The SDK provides a simple API, in C language, that developers can use to instrument their code. The instrumentation is done by adding counters that can help to identify the ”useful work” done by the application: these counters need to be defined according to the specific application domain (e.g. a mail application can record the number of received emails)The second step is to interface the application with energy meters, in order to collect energy consumption information. The SDK provides drivers and libraries to communicate with different models of hardware energy meters. Then, it is possible for the developer to visualise and correlate the usage metrics with power consumption data in order to analyse the energy efficiency of its application, or to implement energy-aware policies. The SDK also provides an ecosystem of tools and utilities that assist developers in embedding the components of Intel Energy Checker into their applications.
• Pros:
– Multi-platform compatibility
– Fully customisable productivity metrics
– Supports different models of power meters
• Cons:
– Configuration of devices and components can be time-consuming
– Low-level APIs (Wrapping of C libraries might be required)
– Only relies on external power meters for power consumption monitoring (no estimation)
3.2.5
PowerTutor
PowerTutor is a mobile application for Android devices, which displays the power consumed by their major hardware components, including CPU, displays as well as Wi-Fi, Audio, GPS, Sensors and cellular interfaces within 5% of actual values. It builds power consumption models by controlling the device power management. PowerTutor includes a set of parameters for each
