GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance. Chapter 7:

Transcription

1 GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance Chapter : Guide for assessing GHG emissions related to software DRAFT January 0

2 Table of Contents GHG Protocol ICT Sector Guidance Chapter : Software Guide for assessing GHG emissions related to software.... Introduction..... What is in this chapter..... The audience for this chapter..... Examples: When to use and when not to use this chapter..... Importance of Assessment of Software.... Part A: Life cycle assessment of software..... Material Acquisition and Pre-processing..... Production..... Distribution and Storage..... Use..... End of Life.... Part B: Calculating the energy consumption of using software on a device..... Objective of Part B..... Business Goals for measuring the energy consumption of software Scope..... Reporting of results..... Methodologies.... Defining Hardware Scope.... OS Measurement..... Goals..... Scope..... OS preparation..... Benchmarking..... Secondary Data.... Application Measurement..... Goals Scope Application preparation..... Benchmarking..... Utilization and OS data..... Transaction allocation.... Virtual Machine Power Assessment..... Background and Aims of Virtual Machine Power Consumption..... Scope and Goal..... Overview of VM assessment methods..... Method : Virtual Machine Manager Power Monitoring Method : Virtual Machine Power Calculation Method : Isolated Virtual Machine Calculation.... Case Studies..... Electronic Software Distribution..... Office Productivity Cloud Services..... Quantifying the GHG impact of Microsoft Windows OS..... Designing Power Efficient Software..... Microsoft Internet Explorer Measurement.... APPENDIX I - Measurement Methods Direct Measurement Tools Total Device Measurement - Mains Powered Devices..... Total Device Measurement - Battery Powered Devices..... Component Measurement... page

3 [This is a chapter of the GHG Protocol Product Standard ICT Sector Guidance. It is being issued as a draft for public comment, through the GHG Protocol ICT Stakeholder Advisory Group. It has been revised following comments received on the previous draft that was issued in March 0. Following any further comments received on this draft, the document will be revised again and a final version published. The ICT Sector Guidance consists of the following chapters: Introduction; Telecommunications Network Services; Desktop Managed Services; Cloud and Data Center Services; Transport Substitution; Hardware; Software. The Introduction Chapter includes general principles applicable to the GHG assessment of ICT products and a summary of common methods to be used, which all the chapters can refer to. Further details of the ICT Sector Guidance initiative are available at the GHG Protocol website: Sections (such as this) in italics and square brackets are for explanation of the draft and will be removed for the final version of the document.] page

4 Executive Summary: Software Chapter Up to 0% of the energy used by ICT hardware can be attributed to the application software running on it, and the design of software can have a significant impact on the amount of energy used. It is therefore important that software designers carefully consider the energy use of the software, and design software efficiently to reduce the energy use. Examples of where better software design can reduce the energy use are: optimizing the CPU usage; optimizing the disk IO usage; optimizing remote calls such as database calls, and web accesses. This chapter provides overall guidance to calculate the greenhouse gas (GHG) emissions attributable to software. It provides both a high-level approach to calculating the full life cycle (Part A), and a detailed methodology for software engineers and software implementers to measure and assess the energy used by software (Part B). The guidance for the full life cycle approach is intentionally brief, and the focus on the energy use is deliberate as this is the most significant stage in terms of GHG emissions. Part A This part of the chapter provides high-level guidance for calculating the GHG emissions for the full life cycle of software. It provides guidance on the five life cycle stages: material acquisition and preprocessing; production; distribution and storage; use; and end-of-life. It is intended to be applicable generically to different types of software e.g. software applications for a PC or mobile device (which may be downloaded from the internet or installed from physical media) through to complex customised corporate software systems requiring extensive development, configuration and deployment. Part B This part of the chapter provides detailed guidance for measuring the energy consumed by software during its use stage. It covers the following three types of software: operating systems, applications and virtual machines. The operating system and applications section are aimed at consumer level devices, with the virtual machine section focused upon server devices within a data center environment. Each software type is separately described and includes: defining the scope, preparing the software for the measurement, and benchmarking measurements for different cases. For operating systems, the benchmark measurements cover different power states (e.g. off, standby, idle, maximum). For applications, the benchmark measurements cover local and remote device benchmarking, and discusses the issue of performing benchmarks when multiple applications or transactions are running. For virtual machines (VMs), the benchmark measurements cover allocating the total power used by a server device to the virtual machines, based on parameters such as size of VM, number of VMs running, and device resources used by the different VMs. Finally, some external case studies are referenced, which provide examples of measuring the power and GHG emissions associated with software. An appendix to Part B describes methods for measuring the power consumption of a device for both mains powered and battery powered devices, and also describes methods for measuring the energy consumed by individual components (e.g. hard drive, memory, graphics processor). page

5 Introduction.. What is in this chapter This chapter forms part of the ICT Sector Guidance to the Greenhouse Gas Protocol Product Life Cycle Accounting and Reporting Standard ( Product Standard ) and covers assessment of software. This chapter details the methodological guidance, additional to the Product Standard, which should be followed to calculate the GHG emissions impact of software. This chapter covers two separate approaches: Part A: The full life cycle GHG assessment of software as a product This section covers the standard life cycle stages and maps them to a software product. It provides a brief, high-level guidance for the assessment of software. Part A comprises section. of this chapter. Part B: A detailed approach to measuring the energy consumption during the use stage of software. This section provides a methodology to calculate the energy consumption of using software on a device. It provides a variety of methods for the measurement of energy consumption on both consumer and server devices. It covers the following categories of software: Operating Systems (OS), Applications and Virtualization. Part B comprises sections. to. of this chapter... The audience for this chapter There are several expected users of this chapter: Suppliers, Users or other organizations carrying out a GHG assessment of software that require standard terminology, guidance and accounting methods The life cycle assessment section (Part A) is intended for use by a general audience interested in assessing the life cycle GHG emissions of a software product. The detailed section concerned with the use stage only (Part B), is intended for a specialized audience interested in the design or operation of software and its impact on energy use. It is expected that the audience has technical knowledge of software operation or design, such as a software developer, an IT manager or an IT technician. It is also expected that they have access to specific tools for energy measurement... Examples: When to use and when not to use this chapter Some examples of where this accounting method for software should be used: Part A, full life cycle assessment: Assessing the life cycle GHG impact of a software product. Assessing the life cycle impact of software, where the software forms part of a larger ICT service or system. In this case, the method provided here can be used to carry out a screening assessment, and will probably be used in conjunction with other chapters of this guidance. Comparing different delivery mechanisms for software (e.g. electronic software distribution vs. distribution using physical media) Part B, detailed measurement of the use stage: Measurement of the electrical energy consumed by software during a specified operation. Assessing the GHG impact of software based on changes in the design or operation of the software or hardware. Assessing the GHG emissions of the use stage of a software product. page

6 This accounting method for software should not be used for the following: Part B of this chapter should not be used to calculate a software product s generic use stage; it is intended to be used for the measurement and calculation of the unique combined software and hardware energy consumption based upon a specified use case Importance of Assessment of Software Software can account for the majority of the energy consumed by ICT hardware, which can be significantly impacted by the design of the software. It is therefore important that software designers and implementers carefully consider the energy consumption of the software. This chapter provides both a high-level life cycle product approach and a detailed methodology for software engineers to measure and assess the energy consumed by software. However, when carrying out an assessment of wider ICT systems and services, measurement of the energy used by hardware automatically includes the energy used by software, therefore in those cases it is not necessary to separately assess the energy consumed by software. In many cases, the embodied emissions (all stages excluding the use stage) of software will not be significant compared to the overall emissions of the ICT system being assessed, particularly when the embodied emissions due to the development of the software will be amortized over a large number of copies of the software. In these cases, it is therefore not necessary to carry out a detailed life cycle assessment of the software as part of a wider system. An exception would be where bespoke software has very high emissions associated with its development, and these are all allocated to a small number of instances of the software. It is recommended that a screening assessment is carried out to determine if a detailed assessment of the embodied emissions is necessary. page

7 Part A: Life cycle assessment of software Where it is decided to carry out a life cycle assessment of software, the following methodology is recommended. This may be used when assessing software as part of a larger ICT system, but more likely where the software is being assessed in its own right, for example if assessing the development of different types of software, or different software development techniques. The assessment of software within the five life cycle stages is as follows:.. Material Acquisition and Pre-processing Where the software development uses existing software libraries or modules, these should be considered as raw materials to the software development process. If software libraries are used in the development, then these should be assessed separately, if this has not already been done. Especially where such software libraries have been developed by third parties, it may be difficult to obtain primary data relating to the development of the software. Estimation techniques will use a proxy for the size or complexity of the software; this could be an estimate of the man-years development effort, or the size of code (number of lines of code or Mbytes). This could then be compared with a similar software module, where an assessment has been carried out... Production This stage equates to the software development and testing process, (where development includes: requirements definition, specification and design). The main source of emissions is related to the activities of the developers. These will include: Heating, lighting, air-conditioning used for buildings occupied by developers and testers Energy used by equipment used for development and testing Consumables used during the development and testing process (e.g. paper and other office supplies) Business travel related to the development and testing process It may be possible to separate out the activities dedicated to the development of one software product (e.g. when a software product has its own dedicated development team occupying their own separate office building). However, it is more likely that different development teams will share resources, and that an individual developer may work on multiple software development projects. In this case it will be necessary to allocate the emissions between the different activities. An appropriate method for allocation in this case is based on the number of person-years development for each software product, and calculating an emission factor per employee to allocate to the software development and testing. Some specialized software may require special testing facilities, or on-site or in-situ testing. The emissions related to operating these facilities and any transport or travel to the testing site should be included. In alignment with the Product Standard, upstream emissions of capital goods (e.g. buildings, machinery) may be excluded. (Note that in this case the computers used to develop the software would be considered as capital goods). Where software has multiple revisions and versions, then each major version of the software should be considered as a new product, and the total emissions due to the development and testing of that version are then amortized over the total number of software copies (number of licenses) expected to be distributed over the life of that version of the software. This follows the same approach as the financial accounting approach, where the decision to develop a new version of a software product is taken based on the investment required to develop the new version against the expected future revenue from the license sales of the new version. (The costs of developing previous versions are considered already sunk and have been set off against existing revenues). It is important to clearly define the scope of the software being assessed, in terms of which versions are covered typically a major version will have an expected life (in years or number of licenses) and will include an expected number of minor versions. page

8 Distribution and Storage The distribution and storage stage relates to service delivery and will include the following (depending on the scope of the software): Deployment (distribution or delivery of the software) (see paragraph below for more detail) Initial Configuration Installation Initial Training User Acceptance Testing (UAT) For complex corporate software (e.g. ERP systems) there is a significant level of activity in this stage; whereas for shrink-wrapped software packages, this stage might only include the physical distribution (or delivery) of the software. Distribution of software Distribution of software may be either by electronic distribution (e.g. via downloads over the internet), or by physical media (e.g. DVD). Or it may be a combination of the two: ) some copies by electronic distribution and some by physical media; or ) distributed by physical media to a central corporate location, then distributed electronically to individual users within the corporation. Where a combination is used then a relevant weighted average should be used. For electronic distribution the following should be included: Storage and hosting of the software by servers (including mirror servers, where relevant) Network use for transferring and downloading the software Use of end-user computer for downloading of the software For distribution by physical media the following should be included: Raw materials and production of the media (DVD or CD) Case and packaging for the media Physical documentation delivered with the software Transport of the media (including storage and retail if relevant).. Use Energy consumed by the software during its use. Assessing the energy used by software is covered in general terms in the Hardware chapter, and in detail in Part B of this chapter... End of Life For software distributed by physical media, the emissions associated with the end of life of the media should be considered. page

9 Part B: Calculating the energy consumption of using software on a device This part of the chapter covers methods to calculate the energy consumption during the use stage of software on a computerized device such as laptop, server, desktop PC or smart phone. Note that Part B of this chapter covers only the use stage of software, and does not cover the full life cycle of software. Please refer to Part A for a description of the life cycle assessment of software. Part B covers methods that are intended for a technically savvy audience such as a software developer, IT manager or IT technician. However, many topics tackled in this part of the chapter contain both an advanced and basic level methodology. Therefore a technically aware sustainability leader can carry out many of the basic level methods and achieve a fundamental understanding of the impact of software, although it may contain higher levels of uncertainty... Objective of Part B This Part B of the chapter aims to provide a methodology to calculate the energy consumption of using software on a device in order to calculate the related GHG emissions. The outcome of following a method in Part B will be an energy consumption value that is suitable for conversion to a GHG impact using appropriate emission factors. The main categories of software covered in Part B are Operating Systems (OS), Applications and Virtualization. The structure of Part B aims to mimic the layered approach of software operating environments. Therefore Part B first covers methodologies to calculate the power consumption of the OS. Once the OS is measured and understood, the application software energy consumption for a defined task can be measured. Finally, the virtualization section is aimed at data center server environments. A device s power consumption is often described by either an idle, maximum or average value. However, these definitions are often an inaccurate reflection of the actual power consumption of a device when performing specific tasks. Part B of the chapter aims to calculate a more refined power consumption value by reflecting software utilization and design features through power measurement. The result of this assessment will not be independent of the device it was performed on and should only be communicated as a software and hardware combination. Software use and design will directly affect the power consumption of a device where power management capabilities are available. Computer devices are commonly built from different components such as a Central Processing Unit (CPU), Memory and input and output devices. Each component is designed to process information at variable rates according to supply and demand, defined as the utilization rate. The utilization rate is commonly directly correlated to power consumption. Therefore each component will consume different amounts of power according to the task being undertaken which is controlled by software. As a basic example, a laptop device with advanced power management features can be defined by its idle power consumption value of 0 watts or a maximum of 0 watts. The 0 watt gap can be described as the utilization range for software to take advantage of. Where a device has no power management capability, for example a network router, the power consumption is constant and thus can be described without having to test against a task load. 0 page

10 Device Operating System Applications 0 w 0 w Software Utilisation 0 w 0 w Idle (OS) utilisation Figure : The levels of detail covered within Part B of this chapter. The device is controlled via the OS which can run various applications Figure : An illustration of a device s utilization by software. In this theoretical example the software has a potential to use as much at 0 watts or as little at 0 watts. This highlights the importance to understand and measure software use Business Goals for measuring the energy consumption of software Measuring the energy consumption of software will commonly be performed when undertaking a detailed analysis of overall energy consumption. Understanding the impact of a process or task that uses software can lead to the creation of new ways of working or the creation of opportunities to find efficiencies by utilizing software in a different manner. Measuring software energy can also aid software developers in focusing development efforts on more power efficient software. Computer devices are complex and can run multiple associated processes at the same time. In order to identify the power consumption of an overall service or task, it becomes necessary to identify and measure only those tasks that are relevant to the analysis. This therefore requires an audit and analysis of the software being run in order to attribute the power consumption to a defined task. The following examples describe possible reasons that software assessment may be undertaken: Operating Systems (OS) OS: OSs control devices and the way they process information in different ways and thus the energy consumption can vary between OS types and versions. Many OSs feature sub versions designed for specific types of device that can effect power consumption. Example Aim: What is the power consumption of an embedded version of an OS on a specific device? OS Power Management: Power management software is often built into an OS or purchased as a third party application. Power management can be utilized to control power consumption of individual hardware components or be applied across an estate of devices and thus create device power efficiency. Example Aim: What is the power consumption impact of using OS Y and a CPU with features Z, where the OS has built in throttling support for CPUs with features Z? page 0

11 Example Aim: What is the power consumption impact over my 0,000 PCs of using monitor X that can be dimmed using OS Y? Applications Applications: Applications are executed with an OS, however the manner in which they request and process data will also affect the power consumption of a device. Depending upon the type of application and the task being performed, a device s power consumption can vary. Ensuring that an application is running at optimal power consumption for the task being undertaken can therefore reduce the overall power consumption. Example Aim: Software Y is only used to edit text in my organization, however it was designed to edit graphics. What is the energy consumption of using a simpler text editor for the defined task? Example Aim: How much energy does device x use to process 000 transactions from customer y? Where device x processes transactions from many different customers at the same time. Example Aim: I want to find out how much power on average my app consumes on a mobile device to perform tasks x,y,z. Remote Software: Using remote applications to process data via services such as cloud is increasingly common. Remote software will reduce the user devices power consumption, but increase the processing devices power consumption and efficiency. To understand the GHG emissions related to using remote software involves an analysis of application software use on a user, network and server device. Example Aim: How do I calculate the power consumed on a remote server when I perform transaction y using a Cloud Service on my device? Example Aim: How do I attribute a portion of server power to a virtualized webserver? Hardware Control Software: Hardware can be designed for a specific type of OS or be controlled and used in a certain way by an application. For example a specific CPU may contain a software controllable instruction set that allows a throttling of power consumption. Although no methodology is included to measure specific impacts of hardware control software, it can be measured using an overall OS and application measurement method. Example Aim: What is the energy consumption impact of turning off hardware features that my software can control? Virtualized Systems Virtualization: Software can create multiple OS instances on one device via virtualization management software. Virtual Machines (VM) are created within virtualization management software and thus can create an environmental saving in the form of reduced hardware use and power consumption (this not covered in this chapter). Virtualization however has the effect of maximizing single devices resources and thus power consumption will increase. VMs are normally operated in data centers on hosts which provide several services. In order to account for the energy consumption of a particular service it is therefore necessary to identify the power consumption of the overall host server and identify the portion that is attributable to the VM. Example Aim: How much energy is used by the VM that supplies service Z? Example Aim: How do I attribute a proportion of server power to a downloading process that serves customers in the UK? page

12 Scope Software is defined here as either applications or procedures required by a computer in order to achieve a specific task. This Part B of the chapter covers two main areas, the first is to determine the power consumption of software required to complete a defined task. The second is to understand how to measure and attribute a server s power to a defined task. Three main areas of software included within the scope of Part B are: OS: The software needed to run the hardware and applications. The methodologies laid out allow you to calculate the power used by the OS which acts as the baseline from which to calculate the impact of applications. Applications: The optional application(s) used in order to achieve a defined task. This also includes OS integrated applications. Virtualization: Software used to create multiple OS instances within one physical device. The presented methodology covers the assessment of the total power consumption of a single VM running on a host computer. The section on operating systems and applications respectively provide guidance for the allocation of power consumption to applications running inside the VM. In order to calculate the power consumption of software, these three software types must be taken into account and accounted for. The OS power consumption should always be known as this acts as the baseline. These methodologies attempt to cover all hardware devices, which for example include Desktop PCs, Laptop PCs, Tablets, Mobile Devices and Servers. In the case that software impacts on the hardware device are known to be negligible during its operation, for example the use of embedded software to control a monitor, then this impact will not be analyzed by these methodologies. The impact of these types of software should be taken into account via the hardware power consumption at defined power states. The scope of this part B of the chapter does not take into account the processes used to create, distribute or remove the software from a device. Part B is only considering the energy consumed due to the use of software, and does not include the embodied emissions of the device that the software is running on. The methodology assesses the run-time power consumption, excluding all impact resulting from software or hardware production or end-of-life activities. Functional Unit Completing a definable task (human or machine driven) via the use of software, where the task can be defined by its input, processing and output commands. For example this unit could be used to assess the energy consumption of using a word processing program for hour. Completing a definable task (human or machine driven) via the use of software on a virtual machine which is running on a virtualized device. Where the task can be defined by its input, processing and output commands... Reporting of results Any reporting of assessment results should include a description of the applied assessment methodology, the input data and a qualification of uncertainty inherent in the input data. The Product Standard guidelines for reporting should be followed where appropriate. Specific assessment reporting is referred to in each of the various methods in this part of the chapter... Methodologies Sections. and. describe methods to measure the power consumption of an OS and an application or set of applications according to a specified device. Section. describes methodologies to calculate the impact of virtualized devices and in particular the power consumption per virtual machine. The approach separates the OS and application energy consumption for a defined task and thus two separate energy page

13 consumptions are calculated when analyzing a device. This enables a baseline (the OS idle power consumption) to be formed from which application power consumption can be understood. For virtualized devices, power consumption is calculated per virtual machine. Select Measurement Method (Section.) Set Hardware Scope (Section.) Perform OS power consumption assessment (Section.) Perform Application only power consumption assessment (Section.) OS and Applicaiton kwh consumption No Start Virtualised Device Figure : The basic steps involved within Part B of this chapter Yes Perform Virtual Machine assessment (Section.) Virtual Machine kwh consumption Each methodology section contains an advanced and basic level of analysis dependent upon precision required and the scale of investigation being performed. Completing an advanced level analysis will contain a higher level of precision, reducing uncertainty. However advanced methods usually require in depth monitoring, technical information and skills and more time. The guidance in this Part B of the chapter is laid out into the following sections. Section. Defining Hardware Scope describes how to define a device for the measurement and benchmarking tests Section. OS Measurement describes how to setup and perform benchmark tests or use secondary data to assess software energy impacts for Operating System (OS) software Section. Application Measurement describes how to setup and perform benchmark tests or use secondary data to assess software energy impacts for Application software Section. Virtual Machine Power Assessment lays out a number of methods to assess the power consumption of a Virtual Machine (VM) and to attribute software impacts appropriately Section. Case Studies provides references to some external case studies relating to the assessment of software Section. APPENDIX I - Measurement Methods describes power measurement approaches that range from using secondary data to device component measurement Throughout this chapter process decision maps are used to aid in choosing an appropriate methodology based upon technology, detail and skill level. The diagram features the symbols laid out in Figure. A series of questions and actions are laid out along with corresponding chapter section references. The color of each action node provides some indication on uncertainty associated with the method. Green indicates lower uncertainty, and yellow and red indicates medium and high uncertainty. Start Decision Action Process Figure : Symbols used throughout this chapter page

14 0. Defining Hardware Scope For any type of software power measurement it is recommended that a typical device is defined. This device could include a graphical display unit, user input device and any other typical peripheral used for every day usual use of the device. For example, the OS can affect the power consumption of a screen via power management or turn on or off hardware to control Bluetooth devices within the computer. Nontypically connected external devices such as USB dongles should not be connected to the typical device. It is also acceptable to only include the device without extra components within measurements; however, this must be clearly defined and stated. For the case of a server system, hardware definition can be more complex, refer to section. Virtual Machine Power Assessment for methods to define a server. If the device used utilizes remote hardware to complete an analyzed task, such as a networked storage device, this must be taken into account. To achieve this, primary analysis of the remote device is preferred, i.e. measurement of both the local and remote device at the same time. However if this data is not available, with justification, hardware ratios may be added to the overall device power consumption. Refer to the Hardware Chapter for more information on ratios. When performing benchmarks for the goal of assessing the impacts of different configurations of the same software, the typical device being used should remain constant. The device should be fully documented with the initial test scenario. When performing different configurations of the same software, it is recommended that only one feature is changed between tests to ensure for accountability OS Measurement This section will enable you to describe the power consumption of an OS according to a specified device. The result of this section will allow you to assess different OS types and configurations and create a baseline from which to analyze the impact of running applications. Methods to analyze the effectiveness of OS power management and to assess power consumption when a device is under maximum load (or stress) are also defined. In this section two methods to assess OS power consumption, benchmarking and secondary data, are described. The first is both the preferred and advanced method and involves undertaking a benchmarking process. Benchmarking is the process of measuring power consumption according to a set of predefined test variables. Alternatively, the second and basic method involves the use of secondary data sources. Performing a benchmarking process reflects the least uncertainty as specific devices and device configurations will be used. Benchmarking may not be appropriate where the device is not available or the device cannot be configured appropriately. It is important to note that this section should not be used to compare the energy efficiency of different forms of OS that contain different levels of functionality and software options. page

15 Start Set OS measurement Goals Device Available? No Use Secondary Data (Section..) Yes No Set Scope and Prepare OS (Section.. &..) Benchmarking Appropriate? Yes Idle or Power State Benchmarking? Idle Ensure Idle State Idle Benchmarks (Section..) 0 Power State Set Scope of Power State measurement Figure : OS Measurement selection process Power State Benchmarks (Section..) The following sections detail potential goals of measuring OS power consumption. Also included are processes for how to prepare and carry out benchmarks with an OS. When running a benchmark, power consumption measurement should be carried out using the methods set out in Section. APPENDIX I - Measurement Methods... Goals The following common goals could be achieved by performing an OS measurement. Create an OS energy consumption baseline from which to measure impact of applications. Required for the application measurement methodology. Create an OS energy consumption baseline for a server device. Where the OS is running the virtual machine management software. Analyze the power consumption of configuring features of the same OS. For example configuring Linux with two different graphical Window Managers. Create an OS energy consumption baseline for different power modes. For example, off, standby and idle modes. page

16 Scope The scope of OS measurement is limited to the power consumed at one defined level of activity (i.e. idle, sleep etc.). OS specific tasks, such as connecting to a wireless internet or starting up and shutting down, can be analyzed using the application measurement method set out in section. Application Measurement. When measuring the energy consumption of an OS the scope of hardware to be measured needs to be defined and documented carefully (see section. Defining Hardware Scope ). The OS software to be analyzed should be defined and documented before carrying out any tests. The aim of this section is to analyze a device s typical OS configuration, therefore the OS being analyzed should be configured to an everyday scenario (see Section.. OS Preparation for more information). Extra application software such as virus checking, internal organization tools and office productivity should not be installed. This includes any OS modification that adds features non-typical to the OSs normal operation; these modifications should be analyzed as applications. An OS task and service listing should be recorded and listed before and after each benchmarking test period. This will account for any extra configurations or issues that may be encountered. In the case that the OS being used cannot be used without extra application software running, this listing will enable a full record of the software being run at the time of the test... OS preparation The device should have a fresh install of the OS that will be used for the analysis thus the exact OS version must be noted. Relevant updates and device drivers should be installed where relevant, but auto update should be disabled. Typical use OS settings such as user profiles, security credentials, graphical interface and network access must be configured and documented accordingly. For example software settings to control transparency such as Windows Aero settings or Linux Window Manager will affect the OS power consumption. Power management settings should be configured and documented, such as display brightness, driver versions and codecs, where relevant to the scenario. Be aware of any pre-set scheduled tasks that may automatically start during testing. If typical, network adapters should be active; however there should be no transfer of data occurring. Windows Case Study In the case of Microsoft Windows the following advice is provided when preparing the OS for a benchmarking session. Windows adjusts its performance over time based on observed usage patterns therefore it is recommended to run the benchmarking tests (see next section) at least once before carrying out or averaging tests. After a new installation Windows needs time (up to days) to let idle tasks run in the background. This time can be lowered by calling the ProcessIdleTask API from Advapi.dll to force idle tasks to run. Please refer to Microsoft s document entitled Mobile Battery Life Solutions for Windows for further information and techniques to configure the system appropriately... Benchmarking This section provides basic steps to perform benchmarks when measuring the energy consumption of an OS. Any benchmarking procedure should be documented before and during tests. Documentation includes noting the task objectives, the time of day, environmental conditions and task times. A method to record tests and provide evidence should be used, for example a clock, thermometer and video camera. Before any benchmark is carried out, the OS preparation steps described in Section.. OS Preparation should be followed. After the preparation is complete, an image of the typical OS should be recorded so that it can be reused or distributed to other test devices. page

17 Idle Benchmarks An Idle benchmark should be carried out for studies that are not analyzing the impact of power management settings. OS power management settings that turn hardware off after a set time (idle timeouts) should be disabled, such as dim screen, screen off, hard disk off. For Windows systems refer to the powercfg.exe command line tool for ways to turn on and off power management settings. To begin, start up the device and confirm that the OS is in an idle state (see OS preparation). Verify that no graphical or user interface tasks are or will be activated. Setup and check that the measurement instrumentation is enabled and ready to record results (see Measurement Methods). An OS task and service listing should be recorded and listed before and after each test period to account for any extra configurations or issues that may be encountered. The Idle benchmark can now be carried out. Idle power should be measured for a period of 0 minutes and repeated at least three times. The average power consumption should be noted for each test (e.g. watts). The power measurements should be analyzed for in-test high variations (+-%). If either in-test power variation or high variations between tests are recorded, the OS should be checked for non-idle processes that are being automatically run in the background. For each test period the energy consumption (kwh) should be recorded. This is commonly calculated by the measurement device (Wh or J). In the case this is not recorded, energy consumption can be calculated using the average power consumption against the tests time period. For example if the average power consumption for the test period of 0 minutes (or / th of an hour) is watts, then the energy consumption is *(/) =. Wh or 0.00 kwh. Power State Benchmarks Where the impact of power management is to be assessed, the various power states that power management can put the device into should be measured. The states that can be assessed should be predefined and documented (Please refer to the ACPI power state standards that can be found here ). Power states that can be measured include: Off Power consumption when the device is connected to a power source, but turned off. Standby or Sleep Power when the device is in a standby or sleep mode. Idle See Idle Benchmarks. Idle after time X. Many power management settings will affect power consumption after a set time has been reached. This state thus refers to a combination of component device power states as determined by the power management setup. Therefore to assess the impact of these settings, allow the device to idle with power management settings and assess the impact of a power management setting after a defined and documented time period. More advanced methods are available to switch power states on and off (such as pwrconfig.exe in Windows). Maximum (see Maximum Benchmarks section below). Once the power states have been defined, benchmarking can be carried out by carrying out the following steps: To begin, start up the device and confirm that the OS is in the desired power state. Verify that no graphical or user interface tasks are or will be activated. Setup and check that the measurement instrumentation is enabled and ready to record results (see Measurement Methods). page

18 An OS task and service listing should be recorded and listed before and after each test period to account for any extra configurations or issues that may be encountered. The power state benchmarks can now be carried out. Each power state should be measured for a period of 0 minutes and repeated at least three times. The average power consumption should be noted for each test (For example watts). The power measurements should be analyzed for intest high variations (+-%). If either in-test power variation or high variations between tests are recorded, the OS should be checked for non-idle processes that are being automatically run in the background. For each test period the energy consumption (kwh) should be recorded. This is commonly calculated by the measurement device (Wh or J). In the case this is not recorded, energy consumption can be calculated using the average power consumption against the tests time period. For example if the average power consumption for the test period of 0 minutes (or / th of an hour) is watts, then the energy consumption is *(/) =. Wh or 0.00 kwh. Maximum Benchmarks Maximum device power can be measured using industry specific benchmarks or can be inferred from idle power measurements or from the device s power supply information. Maximum power consumption can be achieved by performing stress testing benchmarks on a device s components. This can be achieved by running software on a device to stress specific components such as CPU, Storage, memory, GPU etc Many benchmarking tools exist and selecting the correct tool will depend upon the device and OS being used. For example Energy Star recommends the use of Linpack and SPECviewperf as industry standard testing. Linpack can be used on most devices including smart phones. A variety of software exists for this purpose and selected software should be detailed and justified according to the devices hardware componentry. In the case that secondary data contains only idle power and not maximum power (such as Energy Star), maximum power can be inferred in one of two ways. Firstly, a common estimate is to double the idle power value. This method is not recommended and should be regarded as a last resort. The second method is achieved by applying a system power utilization factor to the maximum rated value of the power supply unit being used by the device. Information on the power supply unit is common place to any device and can be found in the device specifications. This method is highly uncertain and relies upon the power supply being selected appropriately for the hardware being used. Commonly cited factors for PC devices revolve around Secondary Data Secondary data can be utilized where benchmarking tests and/or direct device measurement is not possible. The data required should be the average power consumption of a device at a specific power state. Where possible the source and measurement methodology of the secondary data should be understood and contain synergies with methodologies laid out in Part B of this chapter. For example, Energy Star run a certification program which involves manufacturers testing their hardware in Idle, Sleep, and Standby (off) power modes. The foundations of the Energy Star tests come from the IEC methodology (see section. APPENDIX I - Measurement Methods ) and thus is a relevant data source to use. The Energy Star database of power consumption for desktops, laptops and servers is available online. Secondary data is useful where measurement cannot be undertaken; however, if the specific device and configuration are not used then results for energy consumption are less precise. Uncertainty arises as hardware components are increasingly customizable, particularly for servers. Although some secondary data sources such as Energy Star data list the OS used for each test, OS specifications can be highly variable which presents further uncertainty. page

19 0 0. Application Measurement This section will enable the power consumption of an application or application set (more than one application) to be measured for a specified device and task. A method to allocate application power consumption per application transaction or process is also described in cases where quick and simplistic results are required. Before completing an application measurement a primary or secondary OS power consumption measurement (Section. OS Measurement ) is required, this acts as a baseline from which to measure the applications power impact. Application energy consumption can be reported as a single application or as a set of applications. The advantage of measuring a set of applications is the reflection of a more realistic use case of software. When reporting a set of applications, power consumption must not be reported as one application. This section describes two methods of calculating power consumption of an application or set of applications and a method to allocate power per application transaction or process; The first method to calculate power consumption of an application or application set is described in Section.. Benchmarking and requires direct access a device. This method measures device power consumption whilst performing a benchmarking process and applying a variety of calculation methods to obtain a per application power consumption. Secondly, where device access is limited, Section.. Utilization and OS data describes a scaling method that uses an application utilization value against OS power consumption values to calculate application power consumption. The OS consumption and application utilization values can either be a secondary or primary measurement. Section.. Transaction allocation describes methods to calculate a per transaction or process application power consumption. This method can be utilized in cases where an application performs multiple transactions or processes, but only the power consumption of a certain set of transactions is required. For example a CRM application can serve many customer transactions but only a single or subset of those customer transactions may be required. page

20 Start Set Application or Application Set measurement Goals Device Available? No Utilisation and OS Secondary Data (Section..) Yes No Virtualised Device? Set Scope & Prepare Application for testing (Section.. &..) Can software utilisation measurements be performed? Transaction allocation (Section..) No No Yes Yes Yes Gather primary or secondary OS power consumption data Can power measurement be performed? Measure application utilisation (Section..) Utilisation and OS Primary Data (Section..) Multiple Transactions per application? Yes Follow steps in Section. Benchmark Application or Application Set (Section..) Application Set or Single Application? Single Power Subtraction (Section..) 0 0 Figure : Application Measurement selection process Multiple Multiple Applications Utilisation (Section..) The following sections detail potential goals of measuring application power consumption. Also included are processes for how to prepare and carry out benchmarks with for an application task. When running a benchmark, power consumption measurement should be carried out using the methods set out in Section. APPENDIX I - Measurement Methods... Goals Assess a specific task being fulfilled within an application. Assess a set of applications (Application Set) typical power consumption for a specified task. Assess a specific task being fulfilled in a variety of applications, including remote and local devices. Analyze two different configurations or use profiles of the same application to achieve the same task... Scope The methods described in this section enable the energy consumption resulting from performing a defined task within one or a set of software applications to be described. Therefore this section can be used to assess specific tasks within one or more software applications across one or more OSs and devices. This section focuses primarily upon the action of a task being carried out; therefore, a task performed with a native OS application can also be measured using this methodology (e.g. Starting up and logging into a device). As with all software measurements, the test device s hardware should be clearly defined and documented (see Section. Defining Hardware Scope ). page 0

21 The goal and scope of the task to be analyzed must be clearly defined and documented. This should be done per application and thus may include multiple entries where the task uses an application set (more than one application). The documentation must include the task description, the processing location of the task and the task s data processing and the route of data transmission (if relevant). The task being analyzed should be fully defined in terms of the use of the application. For example if an application is typically already open when the task is being completed and is not shut down after the task, the power consumption to open and close that application should not be included in the task assessment (e.g. a web service transaction). In the case that the task requires the specific opening and closing of the application then the overall power consumption should include opening and closing operations (e.g. a word processing task). A common case for analysis may involve a task that occurs on both a local and remote system, such as web browsing and cloud services. In this case, the goal of the task must be clearly defined and documented to ensure all task systems are accounted for. The boundary of measurement should also be considered, for example when analyzing the energy consumption of an online transaction it is likely that a remote system (e.g. server) also consumes power. It is recommended that the boundary of tasks that contain multiple data processing locations takes into account the energy consumption of the local machine, the networking equipment used and the device where the remote processing occurs. Remote processing devices are servers which are difficult to directly assess. Where a server is not available methods set out in section. Virtual Machine Power Assessment can be used to allocate power to the analyzed task. For guidance on network power assessment, refer to the Telecoms Network Services Chapter. For guidance on what to include in a cloud service assessment, refer to the Cloud and Data Center Services Chapter. Boundaries are crucial to this section as another common case may analyze just the application used to interface with the remote applications. For example the web browser used to watch an online movie could be assessed for overall energy efficiency. Extra hardware used for the task being analyzed should also be included (see Section. Defining Hardware Scope ). For example, a task may involve the intensive use of a separate storage device. This device should be included within the power measurement analysis as a separate device and accounted for in the overall power consumption... Application preparation Preparing applications for direct assessment will be highly dependent upon the application type and the nature of the task being analyzed. The following basic steps should be applied to prepare an application for assessment. Not all steps are relevant for all methods. Implement a new install of the application or application set onto a defined OS setup (see section. OS Measurement, for how to configure the OS). Activate and connect relevant application hardware services (e.g. Wi-Fi connected to the internet for the task of assessing an internet browser). Application settings should be configured to a typical use scenario and documented. In this case typical should be the everyday use of the software. In the case that different configurations of the same software are to be analyzed, the typical scenario will act as the baseline from which to test from. Where relevant, run the application and ensure that any OS to application exchange and initial, one time only setup is completed (unless this is what is to be analyzed). Document the input and output processes for the task being analyzed. An OS task and service listing should be recorded and listed before and after each benchmarking test period. This will account for any extra configurations or issues that may be encountered. page

22 If the goal of the analysis is to analyze a task, define a task profile document. This should include defining the task being undertaken, the required steps to complete it and the timings of each. This should also include the application or application set required. If the goal of the analysis is to analyze an average application use, define the average use of an application for the scenario in an application profile document. Average use definition should entail data collection and documentation on the average use of a program including, the time it is used for and the tasks completed with the application. This could be achieved via a statistical analysis of device use, task use or via a survey of user behavior. Be aware of secondary applications being utilized by the primary application. This can be analyzed by reviewing the task manager or from within the source code of the application itself. If secondary applications are utilized, the results should be reported as an application set rather than one application only, or be separated out. OS settings that turn hardware off after a set time (idle timeouts) should be disabled, such as dim screen, screen off, hard disk off. For Windows systems refer to the powercfg.exe command line tool for ways to turn on and off power management settings. Application power settings should be left on... Benchmarking This section provides basic steps to perform application benchmarking. Any benchmarking process should be documented before and during tests. Documentation includes noting the task objectives, the time of day, environmental conditions and task time. A method to record tests and provide evidence is required, for example a clock, thermometer and video camera. Before any benchmark is carried out, the application preparation steps described in.. Application Preparation should be followed. The basic process for a benchmarking process is to measure energy consumption of an application or application set and compare it the idle level of the OS it is measured upon. The subtraction of the OS idle consumption from the benchmarks energy consumption is the applications energy consumption. Measuring and benchmarking an applications and tasks energy consumption is difficult to accomplish as multiple applications (some non-task specific) can be running or be required on a device at one time. There are two ways to combat this issue that are explained in the following sections and briefly discussed below; The first is to ensure that only the application or application set being analyzed is running and perform a benchmark on this (i.e. no non-task specific applications running). This however implies that applications are completely rigid in their device resource use and creates linearity to a device s power consumption. In most cases this is not true as the OS and application combination can change resource use according to the availability of free device resource, thus creating efficiencies. However for smaller or simplistic tasks such as web browsing or word processing this method is acceptable and produces device specific results. Secondly one may encounter the case that either linear power consumption is not expected where multiple applications are required for the analyzed task, or the device cannot be removed of all nontask specific applications. For these circumstances power consumption can be inferred from device resource utilization. In this section we take into account CPU use only, however the method presented can be expanded to use other device components. Where multiple transactions are occurring within an application or application set, section.. Transaction allocation can be used to separate non-task specific transactions. Local Device Benchmarking. The following steps are split between local device and remote device benchmarking. In this case a local device is one that can be physically accessed and measured and is not virtualized. Start-up the page

23 device and confirm that the OS is in an idle state. See Section.. Benchmarking to accomplish this.. Setup and check that the measurement instrumentation is enabled and ready to record results (see Section. APPENDIX I - Measurement Methods ).. The application or set of applications required for the task should be defined and ready to be used.. In the case that other non-task specific applications are open and cannot be closed, a full list of the applications should be made.. Applications that process multiple processes or transactions should be defined in terms of the number of processes or transactions being performed during the benchmark. It is acceptable and recommended that such applications are tested under typical use. This may result in the test including non-task specific transactions which can be removed in Section.. Transaction allocation. Ideally a monitoring system will be used to measure transactions over the period of the benchmark.. A per application CPU utilization % use may also need to be recorded. This data should be recorded at least every second for the period of the benchmark and averaged. This data will be used in one of two ways: a. If direct power measurement is being undertaken this data will be used to determine the approximate power that should be allocated to the non-task specific applications. This is not required if a single application or application set power consumption is being analyzed. See the Multiple Applications Allocation Utilization section below for detailed information on utilization recording. b. If a utilization benchmark only is being carried out (Section.., Utilization and OS Data ), this will be used to determine the approximate power that should be allocated to an application where direct power management has not been carried out.. An OS task and service listing should be recorded and listed before and after each test period to account for any extra applications that are being utilized by the task that may be unknown.. If the goal of the benchmark is to assess the power consumption of opening and running an application or application set, the application should be ready to open. It is vital to understand the tasks application scope, as in this case the power consumption of opening and closing the application should be taken into account.. If a task within an application is to be measured, and the application is normally open to complete the task, open the application and setup files and settings according to the task specification. 0. Measure and record the device s power consumption and task time whilst performing the steps defined in the task or application profile document (specified in Section.. Application Preparation ). Measurements should be repeated and measured at least three times. The average power consumption should be noted for each test. The power measurements should be analyzed for in-test high variations (+-%). If either in-test power variation or high variations between tests are recorded, the OS should be checked for any other processes are being run which should be stopped or accounted for. An OS task and service listing should be recorded before and after each test period to account for any issues.. When testing, mimic as closely to a real scenario the time taken to complete and the devices used to perform the task. A scripted test run is acceptable if the script can mimic the time taken and the devices used by a human to complete the task.. For each test period the overall device energy consumption (kwh) should be recorded. This is commonly calculated by the measurement device (Wh or J) for the period of the test. In the case this is not recorded, energy consumption can be calculated using the average power consumption page

24 0 0 0 against the tests time period. For example if the average power consumption for the test period of minutes is 0 watts, then the energy consumption is 0*(/0) =.00 Wh or 0.0 kwh.. The energy consumption recorded is a combination of OS and application energy. Two options to calculate application or application set are now available: a. If one application or an application set is being analyzed use the power subtraction method (see below) to calculate the final energy consumption. b. If the scenario contains multiple applications that cannot be closed down and the CPU use has been recorded, use the Multiple Applications Allocation - Utilization method (see below) to calculate final energy consumption.. In the case that multiple transactions were occurring that were not directly related to the task being analyzed, or where a per transaction analysis is required, Section.. Transaction allocation can be utilized after the application or application set energy consumption has been calculated (step ). Remote Device Benchmarking A remote device can be benchmarked as a local device where one has access to the device and the device is not virtualized. Where access to the device cannot be gained, follow steps in.. Utilization and OS data. Where the device is virtualized, such as a virtual machine webserver or remote data processing server, the steps laid out within section. Virtual Machine Power Assessment can be used to calculate the appropriate power consumption. Also described is a method to calculate the average power consumption of a server device where little or no information is known about the server. The power consumption of the networking equipment should be taken into account where a remote device is utilized. This can be calculated using the guidance in the Telecoms Network Services Chapter. Power subtraction The overall energy consumption recorded through the benchmark process is a combination of the OS and applications. This method can be used to separate OS from application or application set. The power subtraction calculation can be used to determine the energy consumption of an application or set of applications where no other non-task specific applications were running and the Idle power state power consumption of the OS being used has been defined (refer to section., OS Measurement, to calculate this). The following equation should be used to separate overall energy consumption from the application or application set and OS: 0 Where is the energy consumption of the application or application set, is the average energy consumption of the benchmarking process and is the average energy consumption of the OS at idle levels as measured in section. OS Measurement according to the measurement time of the benchmarking process. For example if a test had resulted in three total energy consumption values of 0.0, 0.0 and 0.0 kwh then. If the OS testing had measured the idle power of an OS at watts and the application benchmark lasted minutes then,. Therefore,. Multiple Applications Allocation - Utilization This method is used where an energy consumption measurement (benchmark) of a set of applications has been undertaken but individual applications need to be separated out. In this case the objective should be to separate out the energy consumption of all applications. To accomplish this, per application or process page

25 0 0 CPU utilization values are required (see step in the Local Device Benchmarking part of Section.. Benchmarking ). The following example uses only a CPU utilization measurement. However, where the device is more complex or the application or task is known to use other hardware components more than the CPU, an investigation into the power consumption of the components within the hardware should be undertaken (see section.. Component Measurement for methods to measure component power consumption). For software resource monitoring using Windows based devices, please refer to Microsoft s document entitled Mobile Battery Life Solutions for Windows. An example of the type of data documented from a utilization record is provided below and was taken from setting up a process specific processor time % use within Microsoft Windows s Performance Monitor tool. The average value should fully reflect the benchmark time period. Application Process Name : EXCEL.exe Duration Mins : :0 Average % Processor Time : 0% Application Process Name : wmplayer.exe Duration Mins : :0 Average % Processor Time : % To calculate an individual application s energy consumption using the resource data, begin by calculating the application set s energy consumption which includes all applications. This can be achieved by following the steps presented in the Power subtraction part of Section.. Benchmarking. This calculation separates the applications from the OS s energy consumption. For the above example, to assess Application s energy consumption, initially calculate the total processor utilization across all applications (e.g. 0 + = %). Next calculate the required applications overall % of the measured processor utilization (e.g. for Application, 0/ = %). The utilization factor for application is thus % which can be used in the following equation to calculate proportional energy consumption for application. 0 For example if, Application and s energy consumption would be (0.0*0.) and (0.0*0.) respectively... Utilization and OS data Where a device specific energy consumption measurement cannot be made using the benchmarking method, the energy consumption of an application (or a set of applications) may be allocated using knowledge of the OS idle and maximum power consumption together with an application utilization factor. Each of these variables can use either primary or secondary data and thus represents the most flexible method, although conversely represents the highest uncertainty. This section describes methods to calculate each of these variables. page

26 0 0 0 Idle and Maximum Power The average idle and maximum power consumption of a device can be obtained via direct measurement or by using secondary data (e.g. W and W). Please see Section., OS Measurement, for methods to obtain direct or secondary data on the idle and maximum power consumption of a device. Utilization Utilization values can be defined in this case as the measure of a device s resource being consumed by an application. These values can be obtained from a direct benchmarking measurement. This section s definition of utilization should not be confused with that given in the Multiple Applications Allocation - Utilization part of Section.. Benchmarking, which calculates utilization differently. Alternatively some software developers publish average utilization factors for applications which can also be utilized. To measure utilization of an application or application set, a utilization only benchmarking process should be carried out. Performing a utilization benchmark does not require external measuring equipment but does require commonly available software utilization measurements. To complete this refer to steps,,,,.,,, and 0 in the Local Device Benchmarking part of Section.. Benchmarking (Other steps are for direct power measurements only). The following example uses only a CPU utilization measurement. However, where the device is more complex or the application or task is known to use other hardware components more than the CPU, an investigation into the power consumption of the components within the hardware must be undertaken (see section.. Component Measurement for methods to measure component power consumption). For software resource monitoring using Windows based devices, please refer to Microsoft s document entitled Mobile Battery Life Solutions for Windows. An example of the type of data documented from a utilization record is provided below and was taken from setting up a process specific processor time % use within Microsoft Windows s Performance Monitor tool. The average value should fully reflect the benchmark time period. Example of the type of data documented from a utilisation record Application Process Name : EXCEL.exe Duration Mins : :0 Average % Processor Time : 0% Application Process Name : wmplayer.exe Duration Mins : :0 Average % Processor Time : % For example, to assess Application s energy consumption, the utilization factor would be 0%. One could also bind multiple applications into one application set which for the above example would equate to a utilization factor of %. This factor can be used in the following equation to calculate proportional energy consumption: 0 For example, if the OS power consumption for Idle and Maximum had been defined as w and w then for the duration of the utilization benchmark (:0 Mins),, for Application and, and respectively. page

27 Transaction allocation This section describes an allocation method that will allow a simplified per application process or transaction energy consumption to be derived. This method s results should be described as the efficiency of a process or transaction according to use of the software and devices, not a defined energy consumption. This method can be utilized in the case of a remote device such as a server that cannot be directly accessed and/or in the case that limited information is available. In this case it is acceptable to report in terms of a combined OS and Application power consumption; however this must be clearly communicated and justified. This is the case for servers as server OSs are commonly a very small portion of overall power consumption. An application or set of applications can perform multiple processes or transactions concurrently that may not be directly related to the task being analyzed. Minimizing the number of processes per application when performing measurements of power is desirable and decreases result uncertainty, however this may imply processes or transactions are independent of each other and do not share resource (i.e. create efficiency), which may not be true. Some applications are specifically designed to be most efficient when highly loaded with processes. Therefore in the case where the number of processes per application cannot or should not be reduced, the transaction based allocation method can be applied to an application or application set s energy consumption measurement (obtained using methods from either section.. Benchmarking or.., Utilization and OS data ). This method may result in uncertain results where each transaction is not equal in terms of resource use. Measure the energy consumption of the application or application set using methods from either Section.. Benchmarking or.., Utilization and OS data. Assess the number of transactions that are occurring within the application or application set. Where a benchmark is being carried out, the definition of number of transactions falls within the time boundary of the benchmark (e.g. 00 transactions in minutes). Where a benchmark has not been carried out, define transactions within a time boundary. We use the term transactions in this case to account for multiple processes that could be accounted as one transaction, thus making accounting simpler. A transaction will be one or a set of application processes that is unique to a request that can be defined and be accounted for within the application. For example a CRM application serving one external user request could be defined as a transaction. This assessment will be highly dependent upon the task and application being assessed. It is crucial that however the transaction is defined all processes within the application are accounted for. If not included the total application power consumption would not be accounted for. When the total number of transactions have been defined (e.g. 00 transactions in minutes) those that are required for analysis should be calculated in % terms of the total. For example 0 transactions out of 00 equates to 0% of the total transactions. To allocate energy consumption to the relevant transactions multiply the percentage of task relevant transactions by the relevant application or application set energy consumption kwh value. For example where the application energy consumption was 0.0 kwh and 0% of transactions were task relevant, the task relevant energy consumption is 0.0*0.0 = 0.0 kwh. a. Specific power consumption for the relevant tasks can also be obtained. E.g. where the transaction benchmark time was minutes (0.0*000)/(/0) = watts. Energy consumption per transaction can also be calculated. This can be achieved by dividing the total energy consumption measured for the application or application set by the number of transactions. For example for 00 transactions in minutes where the application energy consumption was 0.0 kwh would equate to 0.0/00 = kwh per transaction a. Specific power consumption per transaction can also be obtained. E.g. where the transaction benchmark time was minutes (0.000*000)/(/0) = 0. watts. page

28 0. Virtual Machine Power Assessment This section describes methods to assess the power consumption of a virtualized device. Four methods are described to allow the allocation of a server device s power to the virtual machines running within. Virtualization is commonly applied to a server system within a data center environment. Therefore this section is aimed at server systems; however, the method can be applied to most types of virtualization software. Various virtualization software systems exist and these guidelines aim to be applicable to all... Background and Aims of Virtual Machine Power Consumption A virtualized device can be described as one that can simultaneously run more than one OS with software managed resources. Commonly a virtualized device will feature a Virtual Machine Manager (VMM) that allows multiple OSs to be managed and executed, each OS is known as a Virtual Machine (VM). Each VM can vary in its use type and resource use and can host a variety of OSs and applications. Many VMs (000 s) can be running simultaneously on one server; therefore, a part of the power consumption of the entire server should be attributed to each VM. Whilst the host device power consumption can be empirically measured, the attribution of power consumption to a particular VM requires calculation. This section describes methods that can be used for various virtualized device contexts. Host VM VM VM VM VMM CPU Memory Disk Network 0 0 Figure : A host device features a VMM with many VMs. The VMM manages resource use by each VM Several assessment methodologies are presented in this section ranging from simple to advanced levels. The described methods take into account the power consumption of the physical host device that the VM is executed on and attributes a portion of power according to the resource use of the VM... Scope and Goal Common goals for VM power assessment are: Assess the power consumption of a task running inside a VM. Assessment of VM power consumption for a defined set of tasks in its own right; for example for management purposes. This section considers VM host devices with one or multiple VMs. The impact of power saving technologies such as VM migration between hosts is not considered within this chapter. Any assessment of VM power is specific to the software executed inside the VM and the host system and thus non-transferable to differently configured host systems... Overview of VM assessment methods Four main methods are described in the following sections that enable the energy of a virtual machine to be calculated. Due to the complexity of virtualized devices, the following section is best followed using the process flow diagram in Figure. Method : Virtual Machine Manager Power Monitoring page

29 0 The first method relies upon in built device power and resource monitoring systems to allocate VM energy consumption. Method : Virtual Machine Power Calculation The second method uses estimation techniques from various device power and resource statistics. This method is spilt between a simplistic (Method a) and more advanced (Method b) approach dependant on data availability. To improve the estimation method dynamic power and resource measurements can be utilized with method b and is required for method. Method : Isolated Virtual Machine Calculation Method focuses upon direct device power and resource testing for a single VM in order to get high quality and detailed results. Methods and also involve a decision between dynamic and static use profiles which is explained below. Method : Transaction Allocation A further method to calculate a single transaction or process within a VM is included, and this has been described as part of the Application Measurement (section.. Transaction allocation ). Start VMM Power Monitoring Yes. VMM Power Monitoring Method No Dynamic (Advanced) Dynamic or Static Use Profile Static (Simple) Static (Intermediate) Measure Power Consumption b. Estimation Method a. Estimation Method Focus on one or many VMs? Many Measure Resource Dynamically Multiple Transactions per application? One Yes.Isolation testing Method Transaction allocation (Section..) Figure : Selection of a method for assessment of a Virtual Machine page

30 Method : Virtual Machine Manager Power Monitoring Increasingly VMMs provide live monitoring of power consumption values per VM based upon software monitors. These systems can replace the need to carry out in depth assessments and can provide good results. However, information regarding the uncertainty associated with these monitoring results is not widely available. Therefore, it is recommended that information regarding correct configuration and areas of uncertainties is requested from the vendor of the virtualization solution. Where VMM monitoring is not available, or too uncertain use the following sections to obtain a per VM power consumption. Dynamic or Static Resource Monitoring When using methods or, a decision between static and dynamic should be made. The static use profile can only be used with method a. Dynamic use profiles can be used with any other method. Resource utilization can be measured dynamically within the virtualized device, or can be a static estimate of average use. The power consumption of the host device depends on the utilization of each VM on the host device resources. Therefore, information about the levels of resource utilization by each VM is required to allocate power consumption to a VM. Dynamic measurement should be preferred due to the high variation that is common in a virtualized device. A more accurate estimation of resource use will result in a less uncertain assessment result. A static use profile is an informed guess or average measured value of likely utilization of a device s resources relative to its capabilities. This represents the simplest and quickest process and data center operators can typically provide such estimates. Hardware vendors may also be able to characterize expected resource utilization depending on utilization of the server hardware components. Transaction based applications will utilize the machine depending on the number of transaction requests. Therefore, static resource values should represent an average or typical transaction or process set. A network service such as a DHCP server will use resources periodically between phases of idle wait. Therefore, utilization values in this case should represent multiple states, for example idle, average and maximum periods. It should be noted that this strongly impacts uncertainty associated with the results. A dynamic use profile can either be a direct monitoring of in-situ device activity or can be based on a benchmarking activity of the likely VM behavior such as application load test cases or network traffic traces. A dynamic profile is essential to performing empirical device power consumption measurements... Method : Virtual Machine Power Calculation This section describes two sub-methods to calculate the power consumption of a VM as a portion of total device power based on the size of the VM relative to other VMs on the system. The device power consumption, device utilization and VM number and size are the main inputs to this section and methods to calculate these are explained. Once an average VM power consumption is calculated, the time of the scenario being analyzed is required to calculate an overall energy usage. The results of this method have a higher uncertainty associated due to the estimation technique used. When reporting assessment results the applied assessment methods need to be documented and a note regarding the uncertainty of the results should be included. Before any testing is carried out, the steps below (which describe how to prepare a virtualized device) should be followed. page 0

31 0 0 Virtualized Device Preparation The following basic steps should be applied to prepare a virtualized device for direct assessment. Not all steps are relevant for all methods. A virtualized device benchmarking profile should be defined and implemented per device. See section OS preparation for steps to complete this. Where possible, implement a new install of the VMM and each VM. Activate and connect relevant VMM and VM hardware services (e.g. connected to the network to access the internet). Where relevant, run the virtualized device and ensure that any VMM to VM and internal VM exchanges and initial, one time only setups are completed (unless this is what is to be analyzed). If detail into each VM is required an OS task and service listing should be recorded and listed before and after each test period. A VMM resource and service listing is also required for some methods, this is explained per method. Setting Virtualized Device Benchmarking & Use Profiles Where testing is to be undertaken, a device wide benchmark profile should be defined and documented. This profile should document the details of the virtualized system, such as what VMM is running and what VM s constitute a typical scenario for the assessment. The power consumption of each VM will vary with the utilization of the host device s resources by processes and applications. This therefore means that when performing an assessment, each VM should be running a typical operational profile of the OS and applications. This use profile determines the resource utilization of the host system. The processes and their resource utilization over time are referred to as a benchmark application task profile. An example benchmark could be running an online web shop system with a specified number of concurrent users. A benchmark can either be a real workload or a synthetic benchmark composed of smaller units of work. Ideally, the typical application profile of a VM will be understood from historical use. An assessment of VM power consumption based on a representative benchmark will reduce uncertainty associated to the results. In some cases instead of developing a custom benchmark it is recommended to use an existing benchmark that closely matches the anticipated VM application. For web applications popular benchmarks are provided by organizations such as TPC, SPEC and SPC. 0 Method a: Single data point power consumption (Secondary Data) This method involves the calculation of the average device power consumption and the size of the VM being analyzed. Average Power Consumption Calculation Where no primary measurement data is available average server power consumption calculation must rely on secondary data. Any reported power consumption depends on the precise server configuration in hardware as well as software. Data is often reported in different ways which are required to be standardized to the average power consumption using the following method page

32 Power GHG Protocol ICT Sector Guidance Chapter : Software 0 When sourcing data one should closely match the device s hardware. Important hardware configuration aspects which impact power consumption are: the number and type of CPUs, the amount and type of installed memory, the number of make of hard disks and network controllers, the mainboard model, the model and number of power supply units. Important software configuration options impacting power consumption are the BIOS configuration and the VM host configuration. The uncertainty associated to host power values depends on the similarity of the host system in regards of those configuration options. Average power consumption can be estimated from single points although this results in increasing uncertainty. A common value published by manufacturers is the Maximum Measured Electricity value (MME) which refers to maximum observed power consumption by a server model and can increasingly often be calculated with online tools for a particular server configuration. These tools commonly allow the specification of individual components. Based on these estimations of maximum power consumption the average power consumption is commonly assumed to be 0% of MME for high-end servers and 0% for volume and mid-range servers. 00 Server Power by Utilisation Old Model New Model Utilisation[%] 0 0 Figure : Correlation between server host resource utilization and power consumption In the case that MME cannot be found, other power consumption types are commonly reported. Four popular types of power consumption that server manufacturers publish are server typical power (TP), server maximum measured electricity (MME), power supply maximum rated input power (MRIP) and power supply output power (OP). The most accurate being MME as it is directly related to the server s individual hardware setup. Where the MME listing is not available, methods for calculating the MME from the three alternative power listings are laid out in Table. Table : Calculation array to calculate the MME from popular manufacturer listed power consumption values. Power Consumption Type Server Maximum Measured Electricity (MME) Calculation Power Supply Maximum Rated Input Power (MRIP) MME = (MRIP * PUV) / SUV Power Supply Output Power (OP) MME = ((OP/PSE)* PUV) / SUV Server Typical Power (TP) MME = TP / SUV SUV = System Utilization Value (0.0 & 0. for Volume and Mid-Range & High End Servers respectively) page

33 PUV = Power Supply Utilization Value (0., 0.0 & 0.0 for Volume, Mid-Range & High End Servers respectively) PSE = Power Supply Efficiency Value (0. for 0% load, for 0% load) Ref : Williams & Tang 0. Calculating VM size The size of the VM is a measure of the share of the total computational power of the server that is being consumed by the VM. The size of a VM for this method is reported in percentage terms, for example VM s, two being % and one at 0%. The size of a VM can change over time for example a VM which provides a service that is used for only a few hours per day would significantly change size. In such a case the average aggregate size over a sufficiently long time period must be estimated. The size of the VM depends on how much of the computational power of the server are allocated to a particular VM instance. An application requires a higher share of computational capacity the smaller the total computation capacity of the server. Finally, the sum of the size of all VMs is equal to since the total typical power consumption of the server must be accounted for., i.e., power of the VM is proportional to the size of the VM and the average server power consumption. VM size can be directly assessed or estimated. If the device is located within a data center environment, the VM size should be known to the data center operatives. Most VMM provide real-time monitoring of resource utilization per VM. These monitoring systems provide the most accurate data on the resources that VMs are using during operation. Method b: Dynamic power consumption calculations This method involves more than one power consumption data point for the device being analyzed and is suited to primary data collection although secondary data can be utilized. Key data required for this method is the device utilization, the size and number of the VM and the dynamic power range for the device. Device Utilization Device Utilization depends directly on the type of service provided by the server and the service demand and can often be estimated by the data center operator. Notably, uncertainty with regards to the utilization of the server will directly result in uncertainty of the average power consumption. A precise correlation of utilization of components to overall system power is specific to the server configuration in hardware and software. For the purpose of this assessment and accepting significant levels of uncertainty CPU load can be used as a proxy for overall device utilization. If possible in a specific context, the weighted influence of other components can be included in this utilization value, provided the assumptions leading to the adoption of such weights are documented. Depending on the specific workload of the server device utilization varies in a range between 0 and 0 percent of the maximum power consumption (see Figure : Correlation between server host resource utilization and power consumption). This variation depends on the utilization of the most energy consuming components, notably, CPU, Memory Bus and Disk and Network I/O. Using primary utilization data from components will improve result precision. Dynamic Power Consumption To calculate the dynamic power consumption range, the device idle and peak power consumption values are required. The idle or base power consumption reflects the device when only the VMM is operating but no VMs are executed on the system. The maximum or peak power consumption reflects the device s maximum power consumption possible which is reached when all components are fully utilized. Figure illustrates the location of base power and peak power consumption. The difference between both values marks page

34 0 the dynamic power range. Given the relatively high uncertainty associated with any estimation methods, it can be justifiably assumed that the servers power consumption increases linearly with increasing CPU load which, however, introduces additional uncertainty. Primary data should be utilized for this method using the methods described in section. APPENDIX I - Measurement Methods. However, secondary data should only be used in case that an assessment of power consumption over a range of utilization values can be found for a specific model. Possible such sources are Energy Star and SPEC_power benchmark results. Single data point estimates should not be used to in turn estimate the idle or maximum utilization power consumption. Power Consumption per VM Once the dynamic range has been determined, the device utilization can be applied to the calculation of average power consumption. Device utilization (%) correlated to a value for power consumption in the interval between idle and maximum power consumption. When calculating the dynamic power consumption relative to base power consumption then the latter must be allocated explicitly to all VMs on the server. A simple procedure is to uniformly allocate to all VMs. The size and number of VMs can be calculated using the methods set out in Method a of this section. Once the above variables have been collected, the VM power consumption can be calculated. For the average power consumption and device utilization combination of variables, the following equation can be utilized: 0 Where is the power consumption of the VM being analyzed, is the dynamic power range of the device, is the utilisation of the VM, is the size of the VM being analyzed and is the number of VMs running on the server. The following examples illustrate the above methods. Example Table : Description of Example Parameter Value Model IBM x Power by IBM Configurator Idle 0W, Max load 00W Type of application Web Server for web shop Utilization Peak 0 requests/second Number of VMs page

35 Utilisaiton (%) GHG Protocol ICT Sector Guidance Chapter : Software 0 utilisation vs time utilisation Time (hour) Figure 0: Average Utilization in requests per second on the assessed VM From experience with an old server that the web shop ran on it is assumed that the new IBM server used in production will have a peak utilization of roughly 0% of server power and off-peak utilization is 0%. Each VM is approximately the same size, i.e. %. Peak utilization was measured to occur for an average of hours per day. Thus the power consumption during peak utilization is roughly. Example Internal ERP System Server The average details below were obtained from the owner of a company s internal server system. The system runs at this level of hours per day. Table : Description of Example Parameter Value Server Type Fujitsu xx Base Power from web site 00W Max power from web site 00W VMs Average utilization of ERP server at peak ( a.m. - p.m.) Average utilization of ERP server at off-peak VM DNS VM DHCP VM ERP 0% 0% page

36 VM Size estimation: The size estimation is performed by the data center manager from his personal experience. He estimates the size as: DHCP % constant DNS % constant, Additional % during office hours ERP Dominates utilization allocate all resource except DHCP and DNS => % 0 0 Thus the power consumption for the ERP VM at peak can be calculated as: At off-peak, the resulting power consumption is roughly 0 watts which results in an average daily power consumption of 00 watts. Dynamic power and resource measurements To improve the estimation method, dynamic power and resource measurements can be utilized with method b and is required for method. Device power measurement If a dynamic use profile is to be utilized, the device s power consumption should also be dynamically measured for the period of the benchmark. External measurement of server system power (see section. APPENDIX I - Measurement Methods ) can be performed with power monitoring power distribution units or power supply unit on the server. Alternatively, an increasing number of server systems provide power monitoring capability via SNMP or ACPI. If measurement cannot be taken, secondary average power consumption values can be used from sources such as Energy Star or manufacturer online tools. Using these values will decrease result certainty however. Any reported power consumption depends on the precise server configuration in hardware as well as software. Therefore when sourcing data one should source data that closely match the device s hardware. Online manufacturer tools are preferable to standard secondary data sources and should be used were possible as one can commonly specify individual components and create a virtual copy of the machine being analyzed. Dynamic VM resource utilization measurement Dynamic VM resource utilization measurement provides a more accurate assessment of per-vm power consumption. Such an assessment allocates power consumption of the host device to individual VMs based on their share of utilization of the hardware components. This assessment requires measuring the level of utilization of device components by each VM over time and then relating them to the total power consumption of the device. This data can then be used with the equations and methods described in Methods a and b to gain more precise results over time. page

37 0 0 0 A benefit of using dynamic over static values is the ability to measure the variation of power consumption over time. For example a VM could be analyzed per second or a set of VMs could be assessed every minute for the period of hours per component. For server systems the most important components regarding power consumption are the CPU, the memory and communication bus on the mainboard, the hard disk and the network interfaces. Most VMM provide real-time monitoring of resource utilization per VM. These monitoring systems provide the most accurate data on the resources that VMs are using during operation. Where utilization measurements cannot be undertaken, but power consumption can, then Method : Isolated Virtual Machine Calculation, can be utilized instead. These actions are closely related to those applicable to consumer devices in section. APPENDIX I - Measurement Methods for tools to measure device. Also see section. OS Measurement, in particular the Idle Benchmarks and Maximum Benchmarks sub-sections of.. Benchmarking, which contain further guidance... Method : Isolated Virtual Machine Calculation This method describes how a defined benchmarking profile can be used to directly assess the power consumption of a VM. For this method a service application is executed inside a single VM in isolation. It yields accurate results however may incur time and device delays because of the need to perform specific tests. The result of this method calculates the power consumption of a VM where only one VM is being run. This method would be used where a single VM out of many is required to be analyzed in detail. This method requires a dynamic use profile and involves directly measuring host device power. Running the VM in isolation to other VMs allows one to directly allocate all power consumption to that VM. The device s idle power consumption can be measured when no VM is being executed. This idle power is then allocated the VM in proportion to the number of VMs running on the server. The following steps should be followed: Measure host idle or base power when only the VMM is running, i.e., the target VM and all other VMs on the host are suspended. Run the VM with the defined application use profile and measure host power over a time interval that is representative of the average host performance. Calculate the average power measured during the benchmarking process Calculate, where is the power consumption of the VM being analyzed, is the average power consumption during the measurement period when only the VM is running, is the power consumption of the device in an idle state and the number of VMs of the device in deployment. The following example illustrates the above steps: E.g. VMWare web services, Oracle Server Console, Microsoft Hyper-V Console, etc. page

38 Table : Description of example Parameter Value Idle Power (with only VMM running) 0 watts Average device power over the time period specified in the application use profile when the benchmark is carried out. 0 watts Average number of VMs running during average use per device 0 0. Case Studies.. Electronic Software Distribution A methodology and case study regarding the impacts of moving from a physical to digital distribution chain has been completed. The study A Methodology to Model the Energy and Greenhouse Gas Emissions of Electronic Software Distributions can be found here This study utilizes the methodology included in this chapter to calculate the impacts of the digital supply chain... Office Productivity Cloud Services A rigorous and detailed energy consumption analysis of three different cloud based office productivity applications has been performed. This study analyzes the power consumption of the data center, network and user devices used when accessing the cloud service. This study also performs an energy consumption analysis on traditional non-cloud versions of the software to understand the overall impact of cloud services. This study will be officially published in early 0. Further detail can be obtained by contacting [email protected]... Quantifying the GHG impact of Microsoft Windows OS A methodology to calculate the energy consumption of one or an enterprise of PCs has been developed into a useable modeling tool. Energy consumption is modeled according to a variety of variables which include the ability to profile the user base, devices and power management setup. Thus the modeling tool can be used to assess the impacts of potential changes in hardware, power management and OS type. The modeling tool is based upon a Microsoft Windows device environment and thus may not be suitable for all device types. The model was designed by Dan Williams working in conjunction with Microsoft UK and The University of Reading. The model can be found here: Designing Power Efficient Software page

39 Many software developers publish guidelines to design more power efficient software. A good example guide is the Energy Smart Software white paper published by Microsoft. Microsoft have a wealth of resources dedicated to designing energy efficient software that can be found on their various developer websites... Microsoft Internet Explorer Measurement Microsoft performed power monitoring of its Internet Explorer software. The methods used are similar to those set out in this chapter and thus can be used as a valid case study to follow. page

40 0. APPENDIX I - Measurement Methods This appendix describes how to measure a device s power consumption. Two direct and two indirect methods are described. The first direct method, total device measurement, is simpler and less complex, but provides little detail into what part of the system is consuming power and can provide greater uncertainty. Secondly, power measurement per device component is complex and technical but can provide insights into what component is using power and thus allows efficiency to be tailored. If the scenario being analyzed does not permit access to the device being analyzed, secondary data power consumption sources can be used. Secondary data should only be used where the data was measured using a comparable OS and application set. Secondary data methods are described in each of the OS and application methodology sections. For servers, a commonly used method to estimate power consumption uses online manufacturer calculators - see the virtualization section for more details. Software power consumption measurement is also an option where technical access is not available. Software power consumption ranges in terms of accuracy and is commonly estimated. However, some hardware devices have built in power consumption measurement which can remove the complexity of direct measurement methods. The first step in measuring the power consumption of software involves defining the device that measurement will be performed upon. The device used will ultimately determine the range of power consumption due to its hardware components being specified to run at certain power levels. Start Use Secondary Data (Section.. &.) No Device Available? Yes In-built Measurement? No Basic or Advanced? Advanced Yes Basic No Is scenario time dependant? No Can device be powered by Mains only? Yes Yes 0 In-built Measurement Battery Run Down (Section..) Battery Extension (Section..) Total System Measurement (Section..) Figure : Decision tree for selecting an appropriate measurement tool Component Measurement (Section..) 0.. Direct Measurement Tools If one undertakes a methodology that requires direct measurement of power consumption, a device capable of measuring the power of a circuit is needed such as a wattmeter, multimeter or oscilloscope which samples the voltage and current and reports the power consumption (watts) and energy consumption (watt hours). Care must be taken over the environment in which the test is to be performed. Ambient room temperature and humidity levels must be within the normal range for the hardware and test scenario. These variables along with mains voltage supply and test equipment models used must be accurately recorded in the case of a retest. It is strongly recommended that before measurement is undertaken the following guidelines from the International Electrotechnical Commission (IEC) are understood and followed: IEC 0 ed.0 - Measurement of Standby Power. page 0

41 0 0 0 IEC 0-BD ed.0 - Methods of measurement for the power consumption of audio, video and related equipment The power meter device used for power measurement must be capable of performing and recording measurements over a defined time period. For exact meter specifications refer to the IEC documents... Total Device Measurement - Mains Powered Devices This method should be utilized if the device being analyzed is powered via mains electricity only. This method should not be used where a device can be powered form an integrated battery that can skew measurements when charging. If the device contains a battery, remove and if possible power from a mains adapter instead. The power measurement device (as defined in Section..) should be placed between the mains outlet and the power adapter. This placement will ensure that the losses encountered by power supply units etc. do not skew the result. The benchmarking processes defined in later sections should then be carried out and results recorded. In the case of a device with multiple processing systems (such as a rack server) see Section. Virtual Machine Power Assessment... Total Device Measurement - Battery Powered Devices In the case that the device is powered directly from an on board battery, measurement is still possible via one of two methods. The first involves a battery run-down test which whilst simple, can be time consuming and contain high uncertainty levels due to reliance on specific hardware parameters and software measures. The second involves the bespoke creation of a battery extension. This requires technical skills, but provides reliable power consumption information. Battery Run-down The battery run-down test involves measuring how much time the devices battery takes to fully discharge from a state of full charge. This test will only provide an average power consumption value. To carry out this test the following information is required: = Listed Battery Capacity (mah or Wh) = Battery Voltage = Time taken to discharge (hours) Conversion = (eta) = the efficiency of the charge cycle (%). This information can then be used with the following equation to assess the averaged power consumption: Where Example: is the average power consumption of the system in watts. Conversion = (eta) (aka efficiency) = 0% page

42 0 0 0 This method can be skewed by many factors, the main factor being the actual battery capacity which can vary particularly with age. Where possible battery capacity should be measured using appropriate tools (software or hardware) instead of the listed value. It is recommended to use a new battery for these tests. Charging efficiency is also a factor that can skew results and thus also represents uncertainty with this method. As the battery charges the various charging hardware (converter, charge circuitry and battery) will lose some power to mainly heat discharge. Charging efficiency is therefore the difference in the amount of power that is consumed by the device and the power used to charge the device s battery. For example, an efficiency of 0% represents 0% of the total power used to charge a device battery lost as heat. Average values of 0% for laptop devices and 0% 0 for mobile devices can be used. This method requires that the benchmark scenario be run for the entire time to discharge the battery. For a device with a long discharge time or where the task is time dependent, this may become impractical. To overcome this limitation, software that can estimate the capacity of a battery can be used. This type of software can be used to read capacity at the start and end of a task. The difference can be substituted into the above formula along with the time taken to perform the task. This method presents results with higher levels of uncertainty as the capacity of the battery is only estimated via software. Battery Extension The battery extension method involves the bespoke, non-permanent, extension of a device s internal battery via means of an external battery holder and wiring array. This provides a suitable situation from which a power measurement device can be placed. This method requires technical hardware skills and should only be performed by an approved electrical technician on hardware that has been approved for test purposes. The basic premise of this method is to place a measurement device between the device and the device battery thus allowing measurement to occur. The technical details of this method are device specific however the following basic steps can be followed: Create a replacement battery shell that contains relevant electrical contacts and a wiring loom that the measurement device can attach to. Create a new battery holder that contains relevant electrical contacts that the original battery can safely sit in. Ensure that the extension does not interfere with the normal operation of the device or battery. Note that the inclusion of some measurement devices may increase the overall power consumption of the battery, but this may account for less than % of total. In the case of a mobile phone or low powered devices, high quality power measurement probes (<ms per measurement) should be utilized to assess the high frequency components that are utilized. For a case study please see Measuring mobile phone energy consumption for 0. wireless networking by Andrew Rice and Simon Hay. (Pervasive and Mobile Computing (00), pp. -0.) Battery Chargers and Energy Efficiency : Summary of Findings and Recommendation - Natural Resources Defense Council August 00 0 Energy Efficiency of Recharging a Mobile Device 0 page

43 Component Measurement This method can be used with devices that are powered via mains or battery electricity. This method however requires technical hardware skills and should only be performed by an approved electrical technician on hardware that has been approved for test purposes. Component measuring can offer greater hardware insights when measuring the impacts of software. Software, dependent on type and design, will need to use different hardware components, for example a graphics software package will use the GPU of a device more intensively, increasing overall power consumption. This analysis can thus lead to targeted hardware tuning or investments to reduce power consumption. The principle behind component measurement is to attach a power measurement tool to each component of the analyzed device. This allows each component to be measured whilst the software is running on the system. Some devices contain on board component measuring, in this case the component can be thought of as containing a built in power measurement tool and thus simplifies the entire process. Component measurement apparatus are common within large ICT developer organizations. Where an official component measurement apparatus is not available the subsequent basic steps should be followed in order to measure hardware components. The hardware will be disassembled and a registered technician must carry out the procedures. The hardware does not necessarily have to be modified although this is dependent upon hardware design and level of component detail needed. To conduct the test, identify the device components using a device data sheet. Some components such as a hard drive and cooling fan will have exposed wires that measurement devices can be used on. If the component cannot be measured but can be removed a method of subtractive allocation can be used. If the component is soldered or plugged into the device s electrical boards, such as processor or memory, a decision must be made to either extend the component so that measurement can be made possible, or amalgamate the components power consumption together. See Mahesri & Vardhan, Power Consumption Breakdown on a Modern Laptop for methods to allocate CPU, memory and Graphics when amalgamating readings together. For miniaturized devices such as smart phones this method may not be suitable and specialized measurement equipment may be needed. Once assessed separate into the following categories; Directly Measureable: Components that can be measured with a power measurement device. Indirectly Measureable - Non-removable: Components that cannot be measured and are essential to the running of the software system. Indirectly Measureable Removable: Components that cannot be measured but can be removed without stopping the running of the software system. Measure overall system power using a power measurement device, this should be performed on the exit of the power supply unit to account for efficiency losses. Use a power measurement device to calculate the power consumption of each component or grouping of components. Identify the power supply wires using component data sheets. If the subtractive allocation method is to be used to measure removable components measure system power before and after the hardware is connected to the system and allocate the difference to the component being analyzed. The final step when measuring component power consumption is to account for the energy efficiency between the mains supply and the power supply to the component. This may be achieved by applying a known efficiency value from manufacturer specification. If this is not known, then this may be measured by placing an extra power supply measurement device on the mains supply output and comparing it to the component device that supplies power to each individual component (e.g. the power supply unit in a PC). The amount of power used by each component should be divided by the efficiency value (i.e. w/0%) to provide a true power consumption value. page