Selected Chapters of System Software Engineering

Energy-Aware System SoftwareDepartment of Computer Science 4 — Distributed Systems and Operating SystemsFriedrich-Alexander University Erlangen-Nuremberg

Proceedings

— July 2013 —

TABLE OF CONTENTS

iv Foreword

1 Components for Energy-Efficient Operating SystemsClemens Lang

7 Software Energy ProfilingMichael Fiedler

14 Operating System Energy AccountingAndreas Mosthaf

20 Runtime Environments and Software FrameworksJeremias Isnardy

26 Green Data Center DesignWolfgang Rödle

Foreword

Timo Hönig Christopher Eibel<thoenig@cs.fau.de> <ceibel@cs.fau.de>

Department of Computer Science 4Distributed Systems and Operating Systems

Friedrich-Alexander University Erlangen-Nuremberg

Today, energy saving techniques are relevant for all computing systems: sensornodes, mobile computing systems such as smart phones and tablet computersas well as Cloud Computing infrastructure. All these systems rely on energy-aware system software for various reasons. While the necessity is obvious forbattery-operated systems, other systems are required to satisfy thermal limits,for example. Various approaches for performing work energy-efficiently exist:hardware energy saving features, energy-efficient operating system components,energy profiler and custom runtime environments.

By means of current research papers, this seminar presents different areas ofenergy-aware system software and discusses their approaches. Each of the fivestudents who participated in the seminar chose one topic at the first seminar da-te. Beyond that, an introduction to the field of energy-aware computer systemsand details on how to write a paper and how to give a presentation were givenby the organizers. Furthermore, organizational matters were clarified. Each at-tendee had to write a paper in ACM two-column style with at least six pagesand to give a 40-minute presentation. Each participant was either supervised byTimo Hönig or Christopher Eibel, who both reviewed the papers and presenta-tion slides of their respective supervisees. At each seminar a different talk wasscheduled. One week before each presentation, the corresponding draft versionof the paper was sent to all participants for preparation so that all attendeeswere able to take part in further discussions at the seminar.

All seminar dates that were not reserved by students were filled with pre-sentations held by the supervisors. One appointment was reserved for givingthe students an introduction on how to read and understand research papers.Moreover, the general procedure of conferences and workshops was explained,for example, by giving insight into different types of reviewing processes. Forone seminar, the attendees had to read the paper “The Forgotten ‘Uncore’: Onthe Energy-Efficiency of Heterogeneous Cores”, which was discussed at first. Af-terwards, the digital recording of its original presentation at the USENIX ATCconference in 2012 was presented. The seminar was rounded up with detailsabout the SEEP framework, including a live demonstration and details aboutthe process of writing and submitting the paper to 4th Workshop on Power-Aware Computing and Systems (HotPower) in 2011.

1

Components for Energy-EfficientOperating Systems

Clemens LangFriedrich-Alexander University Erlangen-Nuremberg

clemens.lang@fau.de

ABSTRACTThe proliferation of smartphones and tablet computers hasraised awareness of an important aspect of modern systemdesign: energy usage can no longer be neglected when de-signing systems. Advances in battery technology are laggingbehind other features like clock speed, memory, storage orbandwidth [3], which makes energy consumption a majorissue in today’s systems. Not only portable devices, but alsodata centers profit from energy-aware systems [1, 4].

Operating systems should not ignore energy consumptionbut use hardware-provided power saving features as efficientlyas possible. This document outlines the components used inoperating systems to perform efficient power management.It also attempts to give insight into the complexity of powermanagement and highlights problems.

1. INTRODUCTIONComparing the growth rates of battery capacity to those ofclock frequency and memory yields alarming results: Table 1shows that in the timespan it took to raise clock speeds toa hundredfold, battery life has only increased by a factor often. The comparison of RAM and battery life is even moresteep.

Year Clock Speed RAM Battery Life

1981 1 1 11991 4 512 22001 187.5 65535 42010 12001 262144 10

Table 1: Technology trends of mobile devices: Fea-tures in multiples of their value in 1981, adaptedfrom [3].

In contrast to memory management, which has been astandard component of operating systems for decades, energyconsumption was largely unconsidered in software designbefore 1998 [9]. In general-purpose operating systems, energyefficiency can be increased by adjusting power consumption ofa process at runtime. Predicting or measuring and extrapolat-ing the power usage of a running program is a requirement forgood power management decisions. For obvious reasons, pre-diction should add as little overhead on energy consumptionas possible. Interpreting or analyzing code is thus a methodout of question in online approaches to power management –we need different tools to achieve the necessary precondition.

1in two cores

Furthermore, it is required to gain insight into where and howpower is used in a computer; on a software level, that meansfinding out which behavioral patterns are the most energyinefficient ones. This does, however, not mean that otherenergy consumers in the system can be ignored if we wantto minimize the power consumption of the whole system.

The following section will give a brief overview on whereand how power is used in CPU and memory. Methods toestimate the power usage at runtime without specializedhardware will be highlighted. Section 3 lists mechanismsavailable in common hardware to reduce the power usage.The following section discusses operating systems’ approachesto minimizing energy consumption by using policies and anumber of challenges with software-based power managementmethods, giving insight into the complexity of power man-agement. Section 5 covers implementation details, before thelast section concludes this overview.

2. MEASURING POWER CONSUMPTIONPower in semiconductor chips is consumed when current isflowing due to either leakage (i.e., power dissipation) or dueto loading or unloading of capacitors caused by a transistorswitch [10]. Power dissipation depends on static parameterslike voltage and time. The power usage also consists of adynamic part that is caused by the switching of transistors.Assuming parts of the chip with high switching frequenciesaccount for a significant part of energy consumption definesa region of interest when searching for energy-demandingareas in the system.

Although static power usage might seem irrelevant at first,it can still be beneficial to model it to rule on scheduling andpower management decisions. Since static power consump-tion depends on the voltage, systems using dynamic voltagescaling (DVS) should not neglect it when optimizing energyusage.

To model dynamic power consumption accurately, a pre-cise understanding of where power is used dynamically iscrucial. Regions of interest, among others not being discussedin this article, are the central processing unit (CPU), caches,a memory management unit (MMU), and dynamic randomaccess memory (DRAM).

The CPU’s high switching frequency suggests a consid-erable contribution to power usage. The instructions beingexecuted might influence the dynamic power consumption ofthe processor; this will be discussed in greater detail on thefollowing pages.

Depending on the associativity and the frequency of refer-ences, caches also contribute to dynamic power consumption.

2

One would expect applications heavily using the cache toshow higher energy consumption than others keeping theirdata in CPU registers. Due to the caches inside an MMUlike the translation lookaside buffer (TLB), significant powerusage can also be expected in memory management.

Random access memory is responsible for another consid-erable share of power consumption. On the one hand, thisis caused by the complex mechanisms involved in access-ing DRAM. On the other hand, the period refresh neededfor dynamic RAM is reflected in an increased static powerconsumption. While one expects the static part to be in-dependent of the instructions being run, memory-intensiveapplications could cause higher dynamic energy usage.

Note that this enumeration is not exhaustive. Peripheraldevices, storage, I/O, cooling and network cards further con-tribute to power consumption and may each offer their ownpower saving mechanisms but are not discussed in this article.

To effectively optimize efficiency by reducing dynamicpower consumption, a relation between certain behavioralpatterns of software (like a series of memory accesses, or aCPU-bounded computation) and the power consumption atdifferent power saving settings is required. This data caneither be supplied by the manufacturer or be measured us-ing a set of benchmarks. Note that current consumptionmeasurement equipment is not integrated into off-the-shelfcomputers; the data can thus not be acquired online for thesystem at hand but must be gathered ahead of time. Dueto power consumption being very hardware-specific, we haveto assume the results will not generalize well enough to beuseful for other setups.

Both Weißel et al. and Snowdon et al. measure energyconsumption of the complete system they are trying to op-timize. The former used a shunt resistor to measure thecurrent flowing into their test system, an Intel IQ 80310 PCIboard rated at 3.3 V. The static power consumption wasmeasured while the test board was idle. A commercial ACpower meter between the machine’s power plug and the wallsocket measured power for Snowdon et al. While both testsetups did measure the power consumption at the point wereit should be minimized, detailed statistics for parts of thosesystems (e.g., CPU, memory, I/O) have not been generated.The recent development to integrate chips with each otherusing the package on package approach or by merging thechips completely further increases the difficulty of separatemeasurements. On-chip mechanisms to gauge power consump-tion could solve this problem and simplify per-componentmeasurements.

2.1 Event CountersTo tell different software behaviors apart assuming the soft-ware is unknown ahead of time, event counters can be used.Commonly used for performance analysis, event countersare hardware-provided counters for events, such as cachemisses, cycles, or memory accesses. The number of countableevents depends on the processor and is usually in the rangeof hundreds [5]. However, only a few events can be measuredsimultaneously due to the relatively low number of eventcounters. Typical numbers of available counter registers aresingle-digit to low two-digit numbers, e.g., between 2 and 6for ARM11 and the ARM Cortex series of processors [6].

Since the number of events exceeds the number of availablecounters, a subset of events must be chosen. To determinethe ideal set of events, a series of measurements can be

333 400 466 533 600 660 733execution speed [MHz]

0.75

0.80

0.85

0.90

0.95

1.00

1.05

ener

gy p

erfo

rman

ce r

atio

add reggoto labelcall functionread L1 cacher/w L1 cacheread memoryr/w memory

Figure 1: Energy consumption for several bench-marks relative to the energy consumption at fullclock speed. From [13].

used: running a number of benchmarks with known behaviorat different power saving settings with different subsets ofevent counters selected generates data that can be used tocompute the correlation between counted events and theircorresponding power consumption. The events showing a highcorrelation are good candidates to estimate the energy usageof a process when dedicated energy measurement hardwareis not available.

To target highest efficiency in power usage, the energy per-formance ratio must be minimized. An energy performanceratio of r % at a certain energy saving setting means thetask needs r % of the energy it would have needed at fullclock speed. Research shows CPU-bound tasks run at highefficiencies regardless of clock speed, while memory-intensivesoftware is up to 25 % more efficient at lower executionspeeds in a test setup used by Weißel et al. in 2002. Figure 1shows this: the five benchmarks “add reg”, “goto label”, “callfunction”, “read L1 cache” and “r/w L1 cache” are efficient atall tested clock speeds, while the memory-bound tasks “readmemory” and“r/w memory” have a lower energy performanceratio (i.e., higher efficiency) at lower clock speeds. Weißel et al.attribute the savings to the slow response time of the memoryand the cycles the CPU needs to stall and wait for the resultsof the memory access. Since the gap between memory speedand CPU clock speed has increased even further since 2002,this effect is more relevant than ever before. Lowering theCPU frequency relative to the memory frequency reducesthe number of cycles wasted, thus increasing efficiency. Notethat Weißel et al. only discuss dynamic voltage scaling intheory, but have not measured energy usage with DVS ineffect due to missing hardware support for voltage scaling.

2.2 The Performance Energy Trade-offIt is not sufficient to minimize the energy performance ratioin order to build a power-efficient but fast system. We haveseen in Figure 1 that CPU-bound tasks are almost equallyefficient at any power saving setting while memory-boundtasks are more efficient at lower clock speeds. Consideringonly these results, the best strategy to save power would bealways running at the lowest possible frequency. However,performance and energy usage are closely linked: Figure 2shows the performance of a subset of those benchmarks in

3

333 400 466 533 600 660 733

1

1.2

1.4

1.6

1.8

2

2.2

execution speed in MHz

rela

tive

applica

tion

per

form

ance

add reg

read memory

r/w memory

Figure 2: Normalized application performance at dif-ferent clock speeds. Adapted from [13].

multiples of the execution time at the lowest clock frequency.We can see that the CPU-bound task “add reg” (and theother CPU-bound tasks omitted in this graph) would beslowed down significantly by running at lower clock speeds,leading to a worse user experience in interactive systems.

Since power management decisions also affect the userexperience, it makes sense to allow the user to adjust thepower management behavior. A simple approach to limitthe effects of power saving on user experience is establishingan upper bound on performance loss under power saving.Weißel et al. chose a maximum loss of 10 % in [13], leadingto energy savings of up to 15 % compared to execution atoptimal performance.

3. POWER SAVING MECHANISMSAssuming accurate prediction of the behavior of a task, howcan power actually be saved? Which mechanisms are offeredby today’s hardware to reduce power consumption? Thissection will explain common techniques and discuss powermanagement heuristics proposed in research.

3.1 Dynamic Frequency ScalingModern processors’ clock frequencies can be adjusted atruntime. Since less switching occurs at lower frequencies, lesspower is consumed. For example, Intel processors that cameto market after the Pentium M processor support EnhancedIntel Speedstep R©Technology that will scale the core frequencyby writing to a machine-specific register [5]. Dynamic voltagescaling is a de-facto standard to save energy [13, 8]. Frequencyscaling is often combined with voltage scaling to achieve ahigher impact on power consumption.

3.2 Dynamic Voltage ScalingDynamic voltage scaling (DVS) is a technique where thesupply voltage of the CPU is changed during execution. Sincethe used energy is proportional to the square of the supplyvoltage, i.e.,

E ∝ V 2, (1)

C0

C1 C2 C3

Sleep States

hlt

P LVL2P LVL3Interrupt

Interrupt

Interrupt

Figure 3: C-states as defined by ACPI. Adaptedfrom [2].

lowering the voltage can reduce the energy consumptionsignificantly [10].

Both dynamic frequency scaling and dynamic voltage scal-ing are often combined into dynamic frequency and voltagescaling (DVFS), because most processors only support lowervoltages at lower clock speeds. Both methods involve a switch-ing time that might be non-negligible and thus has to betaken into account when making power saving decisions. Aparticularly slow example is the AMD Opteron 246 processor,where voltage scaling takes up to 2 ms when operating withinthe specifications. This is well outside common switchingtimes in the range of 10 µs to 140 µs Snowdon et al. foundfor other CPUs [11].

3.3 Sleep StatesModern systems provide several sleep states used for powermanagement. The Advanced Configuration and Power Inter-face (ACPI) standard defines such states for different partsof the hardware. For the short-term power management dis-cussed in this article, the power states of the processor aremost relevant. The ACPI specification denotes these statesC0,C1,C2,C3, . . . ,Cn [2]. While in state C0, the processorexecutes instructions. Using the hlt instruction, the proces-sor can be put into the C1 power state, in which it ceasesto execute instructions but maintains execution context andcaches. All higher-numbered states are optional. In C-state 2,processors keep their context and caches (which also impliescontinuation of the cache-coherence protocol) but consumeless energy than in C1. C2 is the first state where wakeupdelays may be non-negligible. In C3 the processor consumeseven less power by handing off cache-coherence to a differententity or flushing its caches completely. Figure 3 illustratesthe available C-states and their transitions. Switching delaysfor these states are available from ACPI to be used by powermanagement policies. Note that switching is only possiblebetween C0 and any other C-state.

Implementations of power management components in op-erating systems should be aware that hardware may supportmore than the states defined by the ACPI standard, such asthe sub-C-states in Intel CPUs [12, 5], possibly leading tofurther opportunities for power saving.

4. POWER MANAGEMENT POLICIESSections 2 and 3 discussed how to measure or estimate (Sec-tion 2) and how to adjust (Section 3) power usage. Thesecomponents are highly hardware-specific and required in or-der to increase energy efficiency. However, they just providethe data and actions required to save energy – they do not

4

eventrates

model policyapplicationcurrent

CPU speed

set newCPU speed

Figure 4: A simple control loop implementing apower management policy. From [13].

save any power on their own. Another component that usesthe input data to select the power saving configuration pro-viding the highest energy efficiency is needed – the so-calledpower management policy.

This article previously discussed the use of event countersto classify the workload (see Section 2.1). These counters spana multidimensional space when used as inputs for the powermanagement policy. For each point in this space, the optimalpower saving configuration can be pre-computed using aseries of benchmarks (see Section 2) using constrained or non-constrained optimization. Different objective functions andconstraints lead to different policies, some of which performbetter than others.

Figure 4 shows a data flow graph where measurement(event rates, current CPU speed), adjustment (set new CPUspeed), and policy (model policy) can be seen.

4.1 The Maximum-Degradation PolicyThe so-called maximum-degradation policy as suggested byWeißel et al. [13] is represented by the optimization problem

minimize P

subject to T ≤ p−1 · Topt (2)

where P is the power consumption, T is the duration of thetask2 with power saving and Topt is the shortest durationthe task would take without power saving. p is an adjustableparameter limiting the maximum performance degradationacceptable in order to save power. Values of p = 0.9 havebeen shown to work well [13].

4.2 The Generalized Energy-Delay PolicyA different approach called generalized energy-delay policy [11]is given by

minimize P 1−α · T 1+α (3)

with P and T as defined in Equation 2 and α ∈ [−1; 1] beinga variable. Modification of α transforms this policy into anumber of policies previously suggested in literature:

• α = 1 yields

minimize T , (4)

which minimizes the execution time and thus maximizesthe performance. Using this policy will implement a power

2which is equal to the inverse performance

saving mechanism that will always use the highest availablefrequencies to finish the task as quickly as possible. Insystems that are not completely utilized, the processor canbe put to sleep for a longer duration compared to runningtasks at lower frequencies. This is called the race-to-haltapproach.

• α = 0 minimizes the energy usage:

minimize P · T =: E (5)

• α = −1 simplifies the optimization problem to

minimize P , (6)

which minimizes the power consumption.

Values for α between zero and one will throttle tasks de-pending on their behavior: memory-bound processes achievehigher energy savings while sacrificing little power and canthus be run at a lower frequency than CPU-bound tasks.Although setting α to a value in [−1; 0] will still throttlethreads depending on the workload, the energy consumptionwill be higher than at α = 0. These values might be useful inenvironments where power consumption needs to be reducedregardless of the energy used for the complete task (e.g., be-cause the power consumption should not exceed a maximumvalue).

4.3 Adjustable PoliciesBoth the maximum-degradation policy and the generalizedenergy-delay policy are parametrized. Using this parameter,the operating system or the end user can adjust the policyto their needs. Requirements for power management dependon the purpose of the machine and might change over time:servers have different requirements than battery-powereddevices, but servers can quickly turn into battery-powereddevices over time, e.g., due to a power failure. Keeping thepolicy parameters adjustable at runtime allows the operatingsystem to react on changed requirements and integrate withother components relevant for power saving.

4.4 Power Management ChallengesWhether energy can be saved by a certain decision dependson a wide range of factors. Modeling and predicting all ofthem as closely as possible is a complicated task. Someof the problems in generating accurate models of powerconsumption are outlined in this section.

4.4.1 Workload PredictionAs shown in Figures 1 and 2 the actual power consumptiondepends on the workload characteristics. Since we can onlysample the behavior with a limited number of event counters,the precision of the prediction might suffer. Matching thebehavioral patterns to the corresponding ideal power savingsetting is error-prone, too: Figure 5 shows two pathologicalcases that require a good analysis of the task’s behavior –the gzip benchmark is most efficient at the highest frequency,whereas the swim graph has its optimal point at a low (butnot the lowest) frequency. It is obvious from this graphthat energy saving decisions without insight into the type ofworkload are impossible.

5

0.9

1

1.1

1.2

1.3

1.4

1.5

1.6

1.7

600 800 1000 1200 1400 1600 1800 0.7

0.8

0.9

1

1.1gz

ip N

orm

alis

ed E

nerg

y

swim

Nor

mal

ised

Ene

rgy

Frequency (MHz)

gzipswim

Figure 5: Normalized energy consumption of twobenchmarks. From [11].

4.4.2 Multiple Variables and Variable Memory Sys-tem Performance

Besides the CPU clock frequency, other frequencies in thesystem, such as the bus and memory frequency, might be ad-justable at runtime. Such systems introduce another variableto be tested when finding the best power saving configuration,which quickly leads to an exploding number of configurationsto be benchmarked ahead of time.

Snowdon et al. also found that memory performance is notcompletely unrelated to CPU clock speed. Some processorfeatures like out of order execution or pre-fetching mightbecome less effective at lower core frequencies. Those effectsare hard to predict, because they are highly hardware-specificand few to no performance counters are available to measurethem. Memory energy consumption additionally depends onthe memory configuration (e.g., in single vs. multi channelconfigurations).

4.4.3 Sleep StatesTasks run at a lower frequency generally take longer to exe-cute. The time delta between running a task at a high andat a low frequency can not be used to put the CPU to asleep state if the system is otherwise idle. While this doesnot matter for heavily loaded machines, it is important forgeneral purpose systems, such as laptops or tablets. Whetheror not it is advisable to run a CPU-bound task at a highclock frequency, depends on the time delta and the powersavings in sleep states the operating system might be ableto put the processor into after task completion.

Consider a task starting at t0 = 0 in two different clockfrequencies fslow and ffast with a power consumption of Pslow

and Pfast, respectively. We assume the task needs c cycles;at a frequency fx the task will finish in

tx =c

fx, x ∈ {slow, fast}. (7)

Without loss of generality, we can assume that fslow < ffastand thus tslow > tfast, since c = const. The energy used thenis

Ex = tx · Px, x ∈ {slow, fast}. (8)

However, the processor does not drop to zero energy usageafter finishing the task – to get accurate results, we need to

1000

1200

1400

1600

1800

2000

2200

2400

2600

600 800 1000 1200 1400 1600 1800

9000

10000

11000

12000

13000

Gzi

p E

nerg

y (J

)

Sw

im E

nerg

y (J

)

Frequency (MHz)

C2 (13.4W) gzipC4 (11.5W) gzip

5W gzip0W gzip

C2 (13.4W) swimC4 (11.5W) swim

5W swim0W swim

Figure 6: Energy consumption of two benchmarkswhen using race-to-sleep for the idle states C2, C4and two hypothetical idle states with 5 and 0 W.From [11].

consider the energy used in the time tslow − tfast where theprocessor is idle. Let us assume Pidle is the power consumptionwhen the processor is idle. This leads us to a decision rule tofind out whether we should run a task at a high frequency:

Efast + (tslow − tfast) · Pidle ≤ Eslow. (9)

Equation 9 shows that power consumption in idle modecan not be neglected when trying to minimize the energy con-sumption in interactive systems. We face a trade-off betweenthe race-to-halt approach and running at a lower frequencyfor a longer time. The gzip benchmark in Figure 6 showsthat with the improvement of idle states in processors, race-to-halt might be a better choice compared to running at lowfrequencies.

4.4.4 Power-supply Efficiency and TemperatureWhen employing dynamic voltage scaling, the power supplymight not work equally efficient at different voltage levels.This imposes another difficulty on operating systems tryingto save power, because reducing the voltage used to drive theCPU might not reduce the power consumption from batteryor wall outlet either. Similarly, the CPU core temperatureplays a role in the system’s power consumption because ofthe power needed for fans and the higher leakage currentcaused by higher core temperatures.

4.4.5 Switching OverheadBoth frequency and voltage switching cause the CPU tobe unavailable while the respective setting is scaled. Thistime is overhead, because energy is still being used, but noinstructions are executed. Excessive switching of frequenciesor voltages might be worse than running at a suboptimalperformance setting for a short period of time. Accurateprediction of the duration of the currently running task isrequired to decide whether the switching overhead will beamortized by subsequent savings. Lu et al. call the decisionboundary for this case the break-even time [7]. Snowdon et al.propose penalizing a frequency switch compared to stayingat the current frequency [11].

6

5. NOTES ON IMPLEMENTATIONSince the behavior of a single process or thread is easier topredict than the workload of the whole operating system(assuming temporal locality), analysis and prediction is usu-ally implemented per-process. This implies modifications ofthe dispatching mechanism. Because task switching is imple-mented in software (either because the hardware does notsupport task switching or because hardware task switching isnot used), event counters will not be reset on task switches.As a consequence, implementations need to read the currentvalues from the configured counters during the task switch.Storing the value enables measuring the event count pertask by calculating the difference between the values at dis-patch and preemption. Depending on the requirements of theimplemented policies and storage space available, differentmethods to store the event counters per process come tomind: How much history should be kept per task, if any? Areall event counts saved, or only the significant ones? Are thelast few bits relevant for the power management decision, orcan they be omitted?

Activities of the operating system are not exempt fromevent counting. This leads to the finding that task switchand performance estimation code is attributed to either pro-cess currently being switched. Depending on the overheadassociated with scheduling decisions, reading the event coun-ters twice might lead to less distorted results. Reading thosemachine-specific registers might come with a non-negligibleoverhead that has to be considered, though. Interrupts willalso be attributed to the currently running task. UnlikeWeißel et al. who seem to ignore this completely, Snowdonet al. later show that the effect does not have a role in themeasurements for all systems they considered [11].

When implementing power management policies, the timeand complexity involved in solving the optimization problemtypically associated with a policy has to be considered. Theoverhead can be reduced using pre-computed lookup tablesor mathematical reformulations, e.g., to avoid floating pointoperations. For example, Equation 3 can be reformulated as

minimize (1− α) logP + (1 + α) log T . (10)

6. CONCLUSIONTo reduce the energy usage and increase energy efficiency,operating systems need to be able to measure or estimatecurrent power consumption, predict a tasks workload andcontrol a series of power saving mechanisms. The compo-nent that decides which measures to activate in order tosave power is called a power management policy. Due to thecomplexity involved in accurately estimating and predictingpower consumption, today’s approaches are heuristic.

Due to lots of hardware-specific settings and sensors, powermanagement benefits from adjustment to the hardware athand. However, this requires significant effort by users orhardware manufacturers. To do this efficiently, vendors needto provide the hardware and have to be able to modifythe operating system. We see a raising number of devices,especially in the mobile market, where this is the case.

From a software developer’s point of view, a task should beas homogeneous as possible to simplify workload predictionin power management policies. Measured in energy efficiency,it might be better to use a thread for a single type of workloadrather than using thread pooling for different tasks.

7. REFERENCES[1] Frank Bellosa. The Case for Event-Driven Energy Ac-

counting. Tech. rep. Erlangen: Friedrich Alexander Uni-versitat, 2001.

[2] Hewlett-Packard Corporation et al. Advanced Configu-ration and Power Interface Specification, Revision 5.0.Dec. 6, 2011.

[3] Timo Honig, Rudiger Kapitza, and Wolfgang Schroder-Preikschat. “Extending Mobile Devices by ExploitingRemote Resources”. In: Proceedings of ACM Euro-pean Conference on Computer Systems (EuroSys 2010),Poster Session. Ed. by ACM SIGOPS. Paris, France,2010.

[4] Timo Honig, Rudiger Kapitza, and Wolfgang Schroder-Preikschat. “ProSEEP: A Proactive Approach to Energy-Aware Programming”. In: Proceedings of the 2012USENIX Annual Technical Conference (ATC 2012),Poster Session. Ed. by USENIX Association. Boston,MA, USA, 2012.

[5] Intel Corporation. Intel R© 64 and IA-32 ArchitecturesSoftware Developer’s Manual, Volume 3B: System Pro-gramming Guide, Part 2. 253669-046US. 2013.

[6] ARM Ltd. Performance Monitor Unit example codefor ARM11 and Cortex-A/R. May 2, 2013. url: http://infocenter.arm.com/help/index.jsp?topic=

/com.arm.doc.faqs/ka4237.html.

[7] Yung-Hsiang Lu and Giovanni De Micheli. “Comparingsystem level power management policies”. In: Design& Test of Computers, IEEE 18.2 (2001), pp. 10–19.

[8] Akihiko Miyoshi et al. “Critical power slope: under-standing the runtime effects of frequency scaling”. In:Proceedings of the 16th international conference onSupercomputing. ACM. 2002, pp. 35–44.

[9] Trevor Pering and Robert Brodersen. “Energy efficientvoltage scheduling for real-time operating systems”. In:Proceedings of the 4th IEEE Real-Time Technology andApplications Symposium RTAS’98, Work in ProgressSession. 1998.

[10] David C Snowdon, Sergio Ruocco, and Gernot Heiser.“Power management and dynamic voltage scaling: Mythsand facts”. In: Proceedings of the 2005 Workshop onPower Aware Real-time Computing, New Jersey, USA.2005.

[11] David C. Snowdon et al. “Koala: a platform for OS-levelpower management”. In: Proceedings of the 4th ACMEuropean conference on Computer systems. EuroSys’09. Nuremberg, Germany: ACM, 2009, pp. 289–302.

[12] Intel Corp. Taylor Kidd. (update) C-states, C-statesand even more C-states. Mar. 27, 2008. url: http://software.intel.com/en-us/blogs/2008/03/27/

update- c- states- c- states- and- even- more- c-

states/.

[13] Andreas Weißel and Frank Bellosa. “Process cruisecontrol: event-driven clock scaling for dynamic powermanagement”. In: Proceedings of the 2002 internationalconference on Compilers, architecture, and synthesisfor embedded systems. ACM. 2002, pp. 238–246.

7

Profiling von Software-Energieverbrauch

Michael FiedlerFriedrich-Alexander-Universität Erlangen-Nürnberg

michael.fiedler@informatik.stud.uni-erlangen.de

KURZZUSAMMENFASSUNGEnergieverbrauch ist ein wichtiger Aspekt beim Entwurfheutiger Hard- und Software. Gerade im Bereich von mobi-len Geraten, bei denen die Laufzeit durch die Batteriekapa-zitat stark beschrankt ist, gleichzeitig aber Anspruche an dieRechenleistung und Datenubertragung zunehmen, kommteiner moglichst geringen Leistungsaufnahme eine wesentli-che Rolle zu. Das Profiling des Energieverbrauchs von Soft-ware, also die Zuordnung von Energieverbrauch zu denje-nigen Programmstrukturen, die auf seine Hohe Einfluss ha-ben, kann Entwickler auf die energiehungrigen Problemstel-len seiner Programme hinweisen, sodass diese gezielt verbes-sert werden konnen. Diese Arbeit gibt hierzu einen Einblickin Konzepte und Probleme aus dem Bereich des Profilingsvon Software-Energieverbrauch. Zusatzlich werden mehrereUmsetzungen von Profilern genauer betrachtet.

1. EINLEITUNGBei heutigen Rechnern spielt neben Geschwindigkeit auchder Energieverbrauch eine wichtige Rolle. Dies ist zum Einendurch eine im Alltagsleben zu beobachtende zunehmendeVerbreitung von mobilen Geraten wie Notebooks, Smart-phones und Tablet-Computern bedingt, bei denen die Gera-telaufzeit durch die verfugbare Batteriekapazitat beschranktist. Auch bei batteriebetriebenen Sensorknoten in Sensor-netzwerken [1] existiert diese Problematik. Daruber hinausist ein moglichst geringer Energieverbrauch auch bei große-ren Rechnern oder Rechenanlagen ein Thema: Hier sind dieSenkung von Stromkosten, der Umweltschutz (beispielswei-se aus Marketing-, Image- oder rechtlichen Grunden) unddas Abfuhren der durch den Energieverbrauch entstehendenWarme anzufuhren. Nicht nur die Hardware, sondern auchdie Software tragt maßgeblich dazu bei, dem Ziel moglichstenergieeffizienter Systeme naher zu kommen – gerade aufder Software-Ebene besteht ein besserer Uberblick uber dasGesamtsystem, der fur Energieverbrauchsoptimierungen ge-nutzt werden kann.

Um energieeffiziente Software zu bauen, benotigen Ent-wickler geeignete Werkzeuge, die sie bei ihrer Aufgabe unter-stutzen. Diese sollen diejenigen Stellen im System mit Ver-besserungsmoglichkeiten bezuglich des Energieverbrauchsaufzeigen, gegebenenfalls vorhandene Fehler in der Ener-gieverwaltung (zum Beispiel sogenannte Wake-Lock-Fehlerin Smartphone-Anwendungen [2]) entdecken und nach An-derungen am Quelltext die Auswirkungen auf den Energie-verbrauch beziffern. Dafur ist es notwendig, den Energiever-brauch anteilig den ihn verursachenden Hard- und Software-Komponenten auf verschiedenen Genauigkeitsebenen (Pro-

zedur/Funktion, Prozess, einzelnes Gerat, Teilsystem desBetriebssystem, . . . ) zuordnen zu konnen – nicht nur, umein bereits umgesetztes System bei seiner Ausfuhrung zubeobachten, sondern auch, um noch nicht im Einsatz befind-liche Systeme wie einzelne Sensorknoten in ihrem Energie-verbrauchsverhalten und damit in ihrer Laufzeit abschatzenzu konnen [1].

Der beschriebenen Aufgabe widmet sich das Profiling vonSoftware-Energieverbrauch mit der Leitfrage “An welcherStelle meiner Software wird wie viel (qualitativ/quantitativ)Energie verbraucht?”. Wahrend im Bereich des Profilings furdie Rechenleistung des Prozessors schon seit vielen JahrenProgramme wie Gprof [3] etabliert sind, ist dies beim Ener-gieverbrauchsverhalten noch nicht der Fall. Diese Ausarbei-tung soll daher einen Einblick in Problemstellungen und Lo-sungsansatze aus Veroffentlichungen zum Thema “Profilingvon Software-Energieverbrauch” bieten.

Die allgemeine Vorgehensweise beim Profiling von Software-Energieverbrauch besteht dabei aus folgende Schritten:

1. Durchlaufen des Programms: Dies kann durch Ausfuh-ren des untersuchten Programms in einer fur Ener-giemessungen instrumentierten realen [4] oder simu-lierten [1] Umgebung durchgefuhrt werden. Auch diezusatzliche Verwendung symbolischer Ausfuhrung [5]fur eine maximale Programmpfaduberdeckung ist da-bei moglich [6].

2. Ermitteln des bei Ausfuhrung benotigten Energiever-brauchs: Dies kann beispielsweise durch eine tatsach-liche Messung mit Hilfe eines Multimeters [4], durchSchatzung basierend auf einem Modell [1] oder unterZuhilfenahme einer Ersatzmetrik und eines fur dieseermittelten Hardware-spezifischen Energieverbrauchs-profils [6] geschehen.

3. Herstellen der Verbindung zwischen dem aktuellenEnergieverbrauch und den Programmstrukturen, diedarauf Einfluss haben: Eine Moglichkeit dafur ist dieAnalyse des Stapelspeichers wahrend der Programm-ausfuhrung [4, 7].

Als problematisch beim dritten Punkt erweist sich da-bei der asynchrone Energieverbrauch [7]. Im Gegensatz zumsynchronen Fall, bei dem der Energieverbrauch zeitgleichmit der Ausfuhrung des ihn verursachenden Programm-bestandteils auftritt (zum Beispiel beim Energieverbrauchdurch das Ausfuhren von Maschinenbefehlen durch den Pro-zessor), tritt asynchroner Energieverbrauch verzogert zum

8

Verursachungszeitpunkt auf (zum Beispiel bei Ein- und Aus-gabeoperationen mit Pufferspeichern, wo der eigentliche Ge-ratezugriff erst nach mehreren Ein- und Ausgabeoperatio-nen stattfindet). Auch dieser zeitlich verzogerte Energiever-brauch muss also im Profiling berucksichtigt werden, umkorrekte Ergebnisse zu erhalten. Insbesondere ist er bei derBetrachtung von Anwendungssoftware fur mobile Gerate zubeachten, wo asynchroner Energieverbrauch eine wichtigeRolle spielt [2].

Diese Arbeit ist wie folgt aufgebaut: In Abschnitt 2 wer-den Entwurfsaspekte von Software-Energieverbrauch-Profilersdiskutiert und eine Ubersicht uber Problemstellungen undmogliche Losungsansatze gegeben. Danach wird in Ab-schnitt 3 auf mehrere Arbeiten zum Profiling genauer einge-gangen. Abschließend folgt eine Zusammenfassung der wich-tigsten Aspekte dieser Arbeit.

2. ENTWURFSASPEKTE FÜR PROFILERIn diesem Abschnitt werden diverse Konzepte betrachtet,mit deren Hilfe Profiler fur Software-Energieverbrauch inder Forschung der letzten Jahre umgesetzt wurden. So un-terscheiden sich die Arbeiten unter Anderem in folgenderHinsicht:

• Messung des Energieverbrauchs: Die Messung kannzum Beispiel per Hardware-Instrumentierung oder perSchatzung mit Hilfe von Ersatzmetriken erfolgen.

• Granularitat : Die Zuordnung des Energieverbrauchskann unter Anderem auf der Ebene von Prozessen odervon Funktionen stattfinden.

• Grad der Programmpfadabdeckung : Wird bei der Er-stellung des Energieverbrauchsprofils nur ein konkretausgefuhrter Programmpfad berucksichtigt oder wirdangestrebt, die Zahl der uberpruften moglichen Pfadezu maximieren?

• Vorgehensweise zur Verknupfung von Enerieverbrauchund Programmstrukturen

• asynchrones Energieverbrauchsverhalten: Wird die Ener-gie nur der jeweils in Ausfuhrung befindlichen Pro-grammstelle zugeordnet, oder werden verzogerte Gera-teaufrufe (zum Beispiel bedingt durch Pufferspeicher-effekte) berucksichtigt? Und wie wird die Zuordnungumgesetzt?

2.1 Messung des EnergieverbrauchsUm eine korrekte Zuordnung zwischen dem Energiever-brauch bei der Ausfuhrung einer Software und den ihn ver-ursachenden Programmstrukturen herstellen zu konnen, isteine standige Verfolgung des Energieverbrauchs notwendig.Da heutige Rechner normalerweise nicht in hinreichendemMaße mit Sensoren ausgestattet sind, uber die per Softwaredie aktuellen Energieverbrauchswerte der einzelnen Gerateausgelesen werden konnen, sind alternative Methoden erfor-derlich.

Eine Messung kann daher entweder durch direkte Instru-mentierung des Rechners geschehen, auf dem das Programmausgefuhrt wird, oder aber man bedient sich eines Modellsbzw. einer Ersatzmetrik, uber die der reale Energieverbrauchindirekt abgeschatzt wird. Der Vorteil der letzteren Variante

ist das Wegfallen des Aufwands dafur, die physische Mess-infrastruktur bei der Ausfuhrung der untersuchten Softwa-re anzubringen. So konnen Gerate auch emuliert werdenoder das Profiling erfolgt wahrend der Programmausfuhrunggleich auf dem untersuchten Rechner.

2.1.1 Direkte Instrumentierung der Hardware mitMessgeräten

Flinn et al. verwenden fur ihr Profiling-Werkzeug Power-Scope [4] ein Digitalmultimeter, mit dem sie den Stromver-brauch des gesamten untersuchten Systems verfolgen. Diedurch Abtastung erzeugten Messwerte werden auf einem se-paraten Rechner gesammelt und spater mit den zeitgleicherhobenen Daten uber die aktuell ausgefuhrte Programm-stelle verbunden (siehe dazu auch Abbildung 4 unten). Einexternes Messgerat wurde hierbei einem in den untersuchtenRechner eingebauten vorgezogen, um eine Beeinflussung derMessergebnisse durch die Messung selbst zu verhindern.

2.1.2 Modellierung des Energieverbrauchs der ein-zelnen Rechnerbestandteile

Als Alternative zu einem Profiling mit direkter Instrumen-tierung des verwendeten Rechners kann der Energiever-brauch auch uber Energieverbrauchsmodelle geschatzt wer-den [1, 8, 2, 7]. Dabei wird zum Beispiel die Leistungsauf-nahme verschiedener Zustande eines Gerats ermittelt. Beider Ausfuhrung des untersuchten Programms wird dannvon den aktuellen Zustanden aller Gerate des Systems aufden momentanen Energieverbrauch geschlossen. Vor ihrerVerwendung konnen diese Modelle auf ihre Anwendbarkeit,Korrektheit und Genauigkeit hin uberpruft werden – hierwiederum mit Hilfe von realen Stromverbrauchsmessungenan einer Referenzhardware. Fur das eigentliche Software-Profiling wird dann das validierte Energieverbrauchsmodellangewandt.

In der Literatur finden sich verschiedene Vorgehenswei-sen, darunter die folgenden:

• Modell fur die Emulation von Hardware und Ausfuh-rungsumgebung : Bei AEON [1] wird fur die Analyseeines Knotens in einem Sensornetzwerk die in den Sen-sorknoten verwendete Hardware emuliert. Zunachstwird ein Modell fur den Energieverbrauch der einzel-nen Gerate in ihren verschiedenen Geratezustanden er-stellt. Anschließend wird die untersuchte Software mitHilfe eines Emulators der Hardware ausgefuhrt. Da-bei kann uber die Zustandswechsel der Gerate und dieim Modell enthaltene Leistungsaufnahme der einzelnenGerate in den jeweiligen Geratezustanden der Energie-verbrauch des Gesamtsystems ermittelt werden.

• Modell fur das Nachverfolgen von Systemaufrufen (engl.system call tracing): Bei Eprof von Pathak et al. [8, 2]hingegen wird ein Modell verwendet, das die bei derProgrammausfuhrung auftretenden Systemaufrufe be-trachtet. Da uber die Systemaufrufe zum Beispiel Ein-und Ausgabeoperationen abgehandelt werden, werdendie Systemaufrufe als Ausloser fur Zustandsubergan-ge der Gerate betrachtet. Uber die im Energiever-brauchsmodell enthaltenen Verbrauchswerte der Ge-ratezustande wird ein Wert fur den Gesamtenergiever-brauch ermittelt.

9

Abbildung 1: Programmpfade und Programmeinhei-ten bei SEEP. Die Große der blauen Knoten derGraphen stellt den Energieverbrauch des jeweiligenProgrammabschnitts schematisch dar. Quelle: [6]

2.2 Granularität der Zuordnung des Energie-verbrauchs zu Programmstrukturen

Um Software-Programmierern einen moglichst guten Uber-blick uber energieaufwandige Bereiche ihres Programms zuermoglichen, betrachten die in dieser Arbeit vorgestelltenProfiling-Konzepte die Programmstruktur-Energieverbrauch-Zuordnung auf der Ebene von Funktionen (und auch Pro-zessen, bei [2] werden zusatzlich Threads und Systemaufru-fe genannt). Auch auf hoheren Abstraktionsebenen wie beider Betrachtung von ganzen Rechnern, Sensornetzwerken [9]oder im Cloud-Computing-Bereich [10] existieren Ansatzezum Profiling. Auf diese wird jedoch in dieser Arbeit nichtweiter eingegangen.

2.3 ProgrammpfadabdeckungDie Ausfuhrung von Software mit bestimmten Aufrufpa-rametern und unter bestimmten Umgebungsbedingungenfuhrt zu einem Programmdurchlauf, der nur einen von vie-len moglichen darstellt (siehe dazu Abbildung 1). Der re-sultierende Ausfuhrungspfad durch das Programm mussdann jedoch nicht reprasentativ fur das Energieverbrauchs-verhalten weiterer moglicher Ausfuhrungspfade sein. Hinzukommt, dass selbst innerhalb eines Ausfuhrungspfads dasEnergieverbrauchsverhalten von der konkreten Eingabe undUmgebung abhangt. Das durch einen einzelnen Profiling-Durchlauf gelieferte Energieverbrauchsprofil kann also nurbedingt Aussagen uber das Gesamtverhalten der untersuch-ten Software liefern. Idealerweise sollte das Profil also einenmoglichst großen und reprasentativen Anteil der Wege durchein Programm berucksichtigen.

Eine Moglichkeit, die Uberdeckung der Ausfuhrungspfa-de zu erhohen, ist die Zuhilfenahme symbolischer Ausfuh-rung [5] von Programmen. Mit Hilfe dieser Technik werdenbei SEEP [6] Eingabewerte fur eine moglichst große Pro-grammpfaduberdeckung gefunden. Anschließend werden furjeden Programmpfad fur mehrere Eingabedaten Programm-einheiten erstellt. Diese werden dann mit dem Profiler un-tersucht und die Ergebnisse konnen fur den Programmpfadzusammengefasst werden.

2.4 Verknüpfung von Energieverbrauch undProgrammstrukturen

Um Energieverbrauchsprofile fur Software zu erstellen, ist eserforderlich, den Zusammenhang zwischen dem Maschinen-code des untersuchten Programms, der im Prozessor ausge-fuhrt wird, und der zugehorigen Programmstruktur auf Pro-

grammiersprachenebene herzustellen. Erst dann kann derwahrend der Ausfuhrung der Maschinenbefehle festgestell-te Energieverbrauch zu denjenigen Programmbestandteilenwie einzelnen Funktionen zugeordnet werden, die fur denProgrammierer interessant sind. Die Zuordnung von Pro-grammzahler zur zugehorigen Funktion ist hierbei uber dieSymboltabelle der ausgefuhrten Programmdatei bzw. derverwendeten Programmbibliotheken moglich. Dazu findensich folgende zwei Moglichkeiten, um vom Programmzahleruber die Symboltabelle der ausgefuhrten Programmdateienbzw. der verwendeten Programmbibliotheken an die zuge-horigen:

• Abtasten der Werte des Programmzahlers: Bei Power-Scope [4] wird regelmaßig der aktuelle Wert des Pro-grammzahlers des Prozessors erfasst, sodass er spateruber die Symboltabelle des ausgefuhrten Programmszu einer Funktion im Programmquelltext zugeordnetwerden kann.

• Nachverfolgen der Funktionsaufrufe: Eprof von Schu-bert et al. [7] und Eprof von Pathak et al. [8, 2] betrach-ten die Programmaufruffolge auf dem Stapelspeicher,bei AEON [1] wird jeder Funktionsaufruf registriert.

2.5 Asynchrones EnergieverbrauchsverhaltenBei der Zuordnung von gemessenem Energieverbrauch zuSoftware-Programmstrukturen sind zwei verschiedene Fallefur den zeitlichen Zusammenhang zwischen der Ausfuhrungeines Programmbefehls bzw. einer Programmstruktur unddem daraus resultierenden Energieverbrauch zu unterschei-den:

1. Der Energieverbrauch findet zeitgleich mit der Ausfuh-rung statt (synchroner Energieverbrauch).

2. Der Energieverbrauch findet zeitlich verzogert zurAusfuhrung oder auf einen langeren Zeitraum verteiltstatt (asynchroner Energieverbrauch).

Im synchronen Fall kann der Energieverbrauch einfachmit den zum Messzeitpunkt ausgefuhrten Maschinenbefehlund damit der zugehorigen Programmeinheit verknupft wer-den – es mussen also zum Beispiel nur der Energieverbrauchund der Programmzahler oder die Reihenfolge der Funkti-onsaufrufe auf dem Stapelspeicher gleichzeitig abgegriffenwerden. Der asynchrone Fall ist komplizierter zu handha-ben. Im Folgenden wird zunachst genauer betrachtet, in wel-chen Fallen Asynchronitat auftritt [2]. Anschließend wirdauf mogliche Vorgehensweisen eingegangen, mit deren Hilfezeitverzogert auftretender Energieverbrauch zu Programm-strukturen zugewiesen werden kann [2].

2.5.1 Ursachen für und Problemstellungen bei asyn-chronem Energieverbrauchsverhalten

Asynchrones Energieverbrauchsverhalten kann verschiedeneUrsachen haben, auf die in diesem Abschnitt eingegangenwird. Neben den verschiedenen Betriebszustanden von Ge-raten und das Beibehalten eines relativ viel Energie benoti-genden Aktivitatsbereitschaftszustands nach einem Gerate-zugriff sind gerade in heutigen Mobiltelefonen auch Wach-zustandssperren (engl. wake locks) sowie Spezialgerate wieGPS-Empfanger von Bedeutung.

10

Abbildung 2: Stromverbrauch eines Mobiltelefonsbeim Senden von 5 Dateneinheiten zu je 10 kB uberdas Mobilfunknetz (3G) mit den Sendebefehlen di-rekt nach dem Verbindungsaufbau. Quelle: [2]

Abbildung 3: Stromverbrauch eines Mobiltelefonsbeim Senden von 5 Dateneinheiten zu je 10 kB uberdas Mobilfunknetz (3G) mit den Sendebefehlen 5 Se-kunden nach dem Verbindungsaufbau. Quelle: [2]

Die in heutigen Rechnern verbauten Gerate haben ver-schiedene Betriebszustande, die dabei helfen, ihren Ener-gieverbrauch gering zu halten. Neben einem Grundzustand,in dem keine bzw. moglichst wenig Energie verbrauchtwird, kann es mehrere Zustande fur Aktivitatsphasen ge-ben [2]. Darunter kann zum Beispiel bei Netzwerkgeratenwie WLAN- und Mobilfunkgeraten ein “Schweifzustand”(engl. tail state) sein, von dem aus schnell in einen Sende-zustand gewechselt werden kann, aber in dem im Vergleichzum Sendezustand weniger Energie verbraucht wird. In die-sem Schweifzustand kann jedoch deutlich mehr Energie alsim Grundzustand benotigt werden. Wird auf das Gerat zu-gegriffen, so muss vom aktuellen Geratezustand in den Sen-dezustand gewechselt werden. Anschließend geht das Geratin den Schweifzustand uber und verweilt dort eine Zeit lang.

Der Schweifzustand erweist sich fur die Zuordnung desaktuellen Energieverbrauchs zu denjenigen Programmein-heiten, die ihn verursachen, als Problem. Im Gegensatz Ge-raten, die ein synchrones Energieverbrauchsverhalten auf-weisen, wie Prozessoren bei der Ausfuhrung von Maschinen-befehlen, wirkt die Gerateaktivitat durch das Verweilen imEnergie verbrauchenden Schweifzustand noch nach: DessenUrsache hat nichts mit der gerade ausgefuhrten Program-manweisung zu tun, sondern mit einem Geratezugriff auseiner anderen Programmanweisung, die irgendwann in derVergangenheit ausgefuhrt wurde.

Eine Illustration der Problematik findet sich in den Abbil-dungen 2 und 3. Sie zeigen den Verlauf des Stromverbrauchseines Mobiltelefons uber das Mobilfunknetzwerk (3G) beimUbertragen von funf Dateneinheiten zu je 10 kB mittels funf

Sendebefehlen. Nach dem Aufbau einer TCP-Verbindungwerden die Daten gesendet. Im ersten Fall (Abbildung 2)folgt der Sendebefehl fur die Datenpakte zeitlich direktauf den Verbindungsaufbau. Im Anschluss an den letztenSendebefehl ist zu beobachten, dass uber mehrere Sekun-den hinweg der Stromverbrauch auf hohem Niveau verweilt(Schweifzustands des Mobilfunkgerats). Erst dann kehrt ermit einem Sprung wieder auf sein Ausgangsniveau zuruck.Gibt es nun zusatzlich eine Verzogerung zwischen dem Ver-bindungsaufbau und dem Senden der Datenpakete (Abbil-dung 3), so verlangert sich die Zeit im Schweifzustand, indem ein im Vergleich zum Grundzustand erhohter Strom-verbrauch auftritt, zusatzlich. Um den Stromverbrauch aufeinzelne Programmbestandteile aufzuteilen, ist daher einepassende Strategie erforderlich, in die die Zustandsuber-gange der einzelnen Gerate einfließen und mit deren Hilfedie verbrauchte Energie auf die beteiligten Funktionsaufrufeaufgeteilt wird. Auf mogliche Vorgehensweisen wird in Ab-schnitt 2.5.2 weiter eingegangen.

Ahnliche Effekte wie der Schweifzustand von Geratenkonnen auch in anderen Fallen auftreten, in denen Gera-te nicht unmittelbar nach dem Ende ihrer Aktivitat auf denenergiesparsamsten Zustand wechseln [2]. In aktuellen Be-triebssystemen fur mobile Gerate gibt es etwa Programmier-schnittstellen, die es Anwendungsentwicklern ermoglichen,eine Wachzustandssperre (engl. wake locks) zu setzen, bis sievon ihnen explizit wieder gelost wird. Profiler, die sich die-ser Wachzustandssperren bewusst sind, konnen daher auchFehler in der Benutzung dieser Programmierschnittstellen(engl. wake lock bugs) aufdecken. Daruber hinaus gibt esGerate wie GPS-Empfanger und Kameras, die nach ihrerAktivierung uber einen langeren Zeitraum in einem akti-ven, energieverbrauchenden Zustand verweilen konnen undin ahnlicher Weise von Profilern berucksichtigt werden soll-ten.

2.5.2 Zuordnungsstrategien bei asynchronem Ener-gieverbrauchsverhalten

Pathak et al. [2] gehen auf mehrere Moglichkeiten ein,asynchronen Energieverbrauch zu den ihn auslosenden Pro-grammeinheiten zuzuordnen:

1. gleichmaßige oder gewichtete Aufteilung auf alle Pro-grammeinheiten

2. Zuweisung zum ersten oder letzten Programmbestand-teil, der das Verweilen auf einem energieverbrauchen-den Geratezustand zur Folge gehabt hatte

Problematisch bei ersten Punkt erweist sich demnach zu-nachst das Festlegen und die Umsetzung der Gewichtung,die das resultierende Energieverbrauchsprofil schwerer ver-standlich machen. Zusatzlich kommt hinzu, dass dem Benut-zer des Profilers durch solche Zuordnungen suggeriert wird,dass das Entfernen einer Programmeinheit mit einer star-ken Gewichtung im ersten Fall bzw. im zweiten Fall derProgrammeinheit, die die gesamten asynchronen Energie-verbrauch zugewiesen bekommen hat, den Energieverbrauchseiner Anwendung entsprechend absenkt. Entgegen dessenwird sich der Energieverbrauch dann jedoch zum Großteilauf andere Programmeinheiten verteilen. Um eine intuitiveVerwendung des Energieverbrauchsprofilers zu ermoglichen,kommen Pathak et al. [2] daher zum Schluss, dass in je-dem Fall ein expliziter Vermerk im Energieverbrauchsprofil

11

Abbildung 4: Uberblick uber PowerScope. (a) Ab-tastung von Werten fur aktuellen Stromverbrauch,Programmzahler und Prozess-ID des untersuchtenRechners. (b) Zusammenfuhren der erhaltenen Wer-te mit der Symboltabelle des untersuchten Pro-gramms zum Energieverbrauchsprofil. Quelle: [4]

notwendig ist, der den Umgang mit asynchronem Energie-verbrauch fur den Benutzer ersichtlich macht, zum Beispieleine Angabe des Energieverbrauchs eines Systemaufrufs miteinem Tupel (Energieverbrauch des eigentlichen Systemauf-rufs, Energieverbrauch des nachfolgenden Schweifzustands).

3. BEISPIELE FÜR UMSETZUNGEN VONENERGIEVERBRAUCH-PROFILERN

In den letzten anderthalb Jahrzehnten wurden Arbeiten ausverschiedenen Forschungsprojekten veroffentlicht, die Um-setzungen von Profilern fur Software-Energieverbrauch zumThema haben. In diesem Abschnitt werden drei der Projektenaher vorgestellt:

• PowerScope (Flinn et al., 1999) [4]: Profiling mittelsAbtastung von Wertpaaren aus dem Programmzahlerim Prozessor und einem Stromverbrauchsmesswert desuntersuchten Rechners

• AEON (Landsiedel et al., 2005) [1]: Profiling mit-tels Energieverbrauchsmodellierung der Geratezustan-de eines Sensorknotens und Ausfuhren auf simulierterHardware

• Eprof (Pathak et al., 2011, 2012) [8, 2]: Profiling mit-tels Nachverfolgen von Funktions- und Systemaufrufenund Modellierung der Geratezustande von Smartpho-nes

Abbildung 5: Uberblick uber AEON. Quelle: [1]

3.1 PowerScopePowerScope [4] fuhrt sein Profiling in zwei Schritten durch:In der ersten Phase (Abbildung 4a) wird eine Abtastung1

von Wertpaaren bestehend aus dem aktuellen Programm-zahler des Prozessors und der aktuellen Prozess-ID aufdem Rechner, auf dem das untersuchte Programm lauft(Profiling-Rechner), durchgefuhrt. Die Abtastung wird da-bei durch ein digitales Multimeter ausgelost, das gleichzei-tig den aktuellen Stromverbrauch des gesamten Profiling-Rechners erfasst und an einen zweiten Rechner (Daten-sammlungsrechner) weiterleitet. Auf dem unteruchten Rech-ner lauft fur das Erfassen der Werte ein angepasstes Be-triebssystem, das zusatzlich fur jeden Prozess den Pfad zurausgefuhrten Programmdatei und bei jedem Laden von Pro-grammbibliotheken auch deren Pfad erfasst.

In der zweiten Phase (Abbildung 4b) werden die er-haltenen Abtastwerte auf dem untersuchten Rechner mitden Symboltabellen der ausgefuhrten Programme und ver-wendeten Programmbibliotheken verknupft und Energiever-brauchswerte aus den Strommesswerten und der Lange derAbtastintervalle berechnet. Als Ergebnis liefert PowerScopeEnergieverbrauchswerte fur ganze Prozesse und Unterbre-chungsroutinen, aufgeschlusselt auf ihre verwendeten Funk-tionen.

1Die Abtastfrequenz kann vom Benutzer eingestellt wer-den, fur Messungen in [4] werden Abtastintervalle von etwa1,6 ms angegeben.

12

Abbildung 6: Uberblick uber die Architektur desEnergieverbrauch-Profilers Eprof von Pathak et al.Quelle: [2]

3.2 AEONDas AEON-Projekt [1] (siehe Abbildung 5) modelliert dasEnergieverbrauchsverhalten der Sensorknotenplattform Mi-ca2 mit dem Betriebssystem TinyOS [11], um Aussagen uberdie Laufzeit von auf der Plattform ausgefuhrten Anwendun-gen treffen zu konnen. Zusatzlich implementiert das ProjektProfiling-Funktionalitat. Bei AEON wird fur jede Hardware-Komponente ein Modell fur die verfugbaren Geratezustandeund den jeweiligen Energieverbrauch in diesen erstellt. DieModelle werden mit Hilfe von Strommessungen kalibriertund validiert. Darauf basierend sind die Modelle im Sen-sorknotenemulator AVRORA [12] implementiert. Fur dasProfiling bzgl. des Energieverbrauchs der CPU werden dieFunktionen im Programmquelltext auf die die Adressen imObjektcode abgebildet und wahrend der Programmausfuh-rung alle Funktionsaufrufe mitgeschnitten.

3.3 Eprof (Pathak et al.)Pathak et al. verfolgen fur ihren Energieverbrauch-ProfilerEprof [8, 2] neben den verwendeten Funktionen zusatzlichnach, welche Systemaufrufe in den untersuchten Smartphone-Programmen aufgerufen werden (engl. system call tracing).Ihr Ziel ist es dabei, das Energieverbrauchsverhalten voll-standiger abzubilden, als es durch eine alleinige direkteVerknupfung von Geratezustanden und der Geratenutzungdurch ein Programm moglich ist (sog. benutzungsbasier-te Modellierung, engl. utilization-based modelling). So wirdzum Beispiel das in Abschnitt 2.5 besprochene asynchroneEnergieverbrauchsverhalten mit berucksichtigt.

Abbildung 6 zeigt das Vorgehen beim Profiling mit Eprof.Fur das Android-Betriebssystem2 werden die untersuch-ten Anwendungen, die verwendete Laufzeitumgebung undder Betriebssystemkern so prapariert, dass zur LaufzeitFunktions- und Systemaufrufe nachverfolgt werden konnen(Bereich Code Instrumentation & Logging in der Abbil-dung). Bei Anwendungen, deren Quelltext nicht verfugbarist, werden dennoch die Aufrufe in der Laufzeitumgebungmit berucksichtigt. Basierend auf diesen erhaltenen Infor-mationen wird in einem zweiten Schritt (Bereich EnergyAccounting in der Abbildung) den ausgefuhrte Programm-strukturen, erhalten uber die aufgerufenen Funktionen, einEnergieverbrauchswert zugeordnet. Der Energieverbrauchwird dabei unter Zuhilfenahme eines Modells fur die ver-

2Eprof wurde neben Android auch fur Windows Mobile um-gesetzt.

schiedenen Gerate in Form eines endlichen Automaten erhal-ten (die Zustandsubergange des Automaten werden durchdie verschiedenen Systemaufrufe ausgelost). Diese erhalte-nen Informationen werden dann dem Nutzer als Ergebnisdargestellt (Bereich Data Presentation in der Abbildung) –zum Einen als Energieverbrauch der einzelnen Programmbe-standteile, zum Anderen als sog. bundle-Reprasentation fureinen detaillierteren Einblick in die asynchron in den Gera-ten fur Ein-/Ausgabe verbrauchte Energie.

4. ZUSAMMENFASSUNGIn dieser Arbeit wurde zunachst auf die grundlegendenSchritte beim Profiling von Software-Energieverbrauch ein-gegangen: Das untersuchte Programm wird durchlaufen undder dabei entstehende Energieverbrauch wird zu denjeni-gen Programmbestandteilen zugeordnet, die fur ihn undseine Hohe ursachlich sind. Danach wurden verschiedeneAspekte, die es beim Entwurf eines Profilers fur Software-Energieverbrauch zu beachten gilt, besprochen. Abschlie-ßend wurden mit PowerScope, AEON und Eprof drei Bei-spiele fur Profiler-Umsetzungen genauer betrachtet.

Obwohl, wie dargelegt wurde, verschiedene Ansatze zumProfiling von Software-Energieverbrauch existieren, hat sichbisher keine Umsetzung fur den Alltagsgebrauch in derSoftware-Entwicklung etabliert. Denkbare Aufgaben fur wei-tere Arbeiten in diesem Bereich konnen daher, neben der zu-satzlichen Betrachtung weiterer Hardware-Komponenten, inder Integration der verschiedenen Ansatzpunkte und verbes-serter Anwenderfreundlichkeit liegen, um das sog. energiege-wahre Programmieren (engl. energ-aware programming) [6]in der Praxis zu vereinfachen.

5. LITERATUR[1] O. Landsiedel, K. Wehrle, and S. Gotz, “Accurate

prediction of power consumption in sensor networks,”in Proceedings of the 2nd IEEE workshop on EmbeddedNetworked Sensors, EmNets ’05, (Washington, DC,USA), pp. 37–44, IEEE Computer Society, 2005.

[2] A. Pathak, Y. C. Hu, and M. Zhang, “Where is theenergy spent inside my app?: fine grained energyaccounting on smartphones with eprof,” in Proceedingsof the 7th ACM european conference on ComputerSystems, EuroSys ’12, (New York, NY, USA),pp. 29–42, ACM, 2012.

[3] S. L. Graham, P. B. Kessler, and M. K. Mckusick,“Gprof: A call graph execution profiler,” in Proceedingsof the 1982 SIGPLAN symposium on Compilerconstruction, SIGPLAN ’82, (New York, NY, USA),pp. 120–126, ACM, 1982.

[4] J. Flinn and M. Satyanarayanan, “PowerScope: a toolfor profiling the energy usage of mobile applications,”in Mobile Computing Systems and Applications, 1999.Proceedings. WMCSA ’99. Second IEEE Workshopon, pp. 2–10, 1999.

[5] C. Cadar and K. Sen, “Symbolic execution forsoftware testing: three decades later,” Commun. ACM,vol. 56, pp. 82–90, Feb. 2013.

[6] T. Honig, C. Eibel, R. Kapitza, andW. Schroder-Preikschat, “SEEP: exploiting symbolicexecution for energy-aware programming,” SIGOPSOper. Syst. Rev., vol. 45, pp. 58–62, Jan. 2012.

13

[7] S. Schubert, D. Kostic, W. Zwaenepoel, and K. Shin,“Profiling software for energy consumption,” in GreenComputing and Communications (GreenCom), 2012IEEE International Conference on, pp. 515–522, 2012.

[8] A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y.-M.Wang, “Fine-grained power modeling for smartphonesusing system call tracing,” in Proceedings of the sixthconference on Computer systems, EuroSys ’11, (NewYork, NY, USA), pp. 153–168, ACM, 2011.

[9] J. Moreno, J. Wenninger, J. Haase, and C. Grimm,“Energy profiling technique for network-level energyoptimization,” in AFRICON, 2011, pp. 1–6, 2011.

[10] Z. Zhang and S. Fu, “Macropower: A coarse-grainpower profiling framework for energy-efficient cloudcomputing,” in Performance Computing andCommunications Conference (IPCCC), 2011 IEEE30th International, pp. 1–8, 2011.

[11] P. Levis, S. Madden, D. Gay, J. Polastre, R. Szewczyk,A. Woo, E. Brewer, and D. Culler, “The emergence ofnetworking abstractions and techniques in tinyos,” inProceedings of the 1st conference on Symposium onNetworked Systems Design and Implementation -Volume 1, NSDI’04, (Berkeley, CA, USA), pp. 1–1,USENIX Association, 2004.

[12] B. L. Titzer, D. K. Lee, and J. Palsberg, “Avrora:scalable sensor network simulation with precisetiming,” in Proceedings of the 4th internationalsymposium on Information processing in sensornetworks, IPSN ’05, (Piscataway, NJ, USA), IEEEPress, 2005.

14

Operating System Energy Accounting

Andreas MosthafFriedrich-Alexander University Erlangen-Nuremberg

andreas.mosthaf@e-technik.stud.uni-erlangen.de

ABSTRACTBesides performance, energy is an important issue for oper-ating systems—especially when they are running on a mo-bile platform. Targeting an optimal lifetime of the systembattery, operating systems have to provide mechanisms forenergy accounting and energy controlling. This documentdescribes the prerequisites for an effective energy manage-ment. It also introduces ECOSystem and the Cinder oper-ating system, two implementations of an energy-aware op-erating system, along with applications developed for thesesystems that demonstrate the benefits of energy manage-ment on operating systems.

1. INTRODUCTIONSince mobile phones—the dominating mobile systems on themarket—are capable of running general-purpose operatingsystems like Linux, there is a great demand for making oper-ating systems more energy-aware. Improvements have beenmade to make energy consumption more visible by means ofsmart device interfaces. In addition, modern devices providea lot of energy-saving modes to avoid wasting energy. Theseimprovements allow operating systems a coarse control ofthe platforms’ energy behavior.

Energy management requires energy accounting on theone side and energy controlling on the other side. Thisdocument describes the prerequisites for an effective en-ergy management on operating systems. An overview overmethods and techniques, providing relevant parameters con-cerning energy resources, is given in Section 2. Section 3then describes the required power model and control mech-anisms. Section 4 and Section 5 contain a brief introductionto ECOSystem [5] and the Cinder operating system [3]—twoimplementations of energy aware operating systems. There-after, Section 6 describes three applications, developed onthe Cinder operating system, demonstrating the benefits ofan energy aware operating system in typical use cases.

2. ENERGY VISIBILITYEnergy management on operating system level requires atfirst precise information about energy consumption of themanaged devices on the one hand and characteristics of thebattery on the other hand. Although modern hardware com-ponents may provide interfaces to retrieve the relevant pa-rameters, in most cases measurements are necessary to getaccurate results.

Due to the closed nature of mobile systems like smart-phones, measuring the power consumption of individual,

Discharge Rate Usable Battery Capacity(normalized to 1C discharge rate)

C/5 107 %C/2 104 %C 100 %2C 94 %4C 86 %

Table 1: Characteristics of a lithium-ion battery, adaptedfrom [1].

functional units is difficult. In such cases measuring thetotal system power and estimating the consumption of sin-gle components will lead to inaccurate results. However,there are mechanisms that allow operating systems to workaround this kind of error.

2.1 Battery CharacteristicsBattery lifetime is an important factor for mobile systemsand therefore it is a primary target of energy managementto maximize it. The discharge rate of a battery has a non-linear impact on the usable battery capacity. High dischargerates can lower the capacity to 70 %–80 %. Table 1 showsthe characteristics of a typical lithium-ion battery.

The Smart Battery interface in the ACPI specification [2]allows operating systems to query all relevant values like cur-rent voltage, remaining capacity, and discharge rate. Unfor-tunately, queries to this interface are slow and return onlyaveraged values of power consumption.

2.2 Power Consumption MeasurementTo measure the power consumption of managed devices onehas to consider the various states a device could reach. Theconsumption of a processor, for example, depends on theusage of the built-in functional units and therefore on thecurrent workload. Additionally modern devices offer powersaving modes we also have to consider. The transition be-tween the different modes of such devices is also a source ofenergy consumption that has to be taken into account.

Table 2 shows the measured energy consumption of anIBM Travelstar 12GN harddisk. Spinup, spindown and ac-cessing a block on the disk drains a fixed amount of energy,whereas energy consumption in one of the three idle statesdepends on the time the harddisk spends in the respectivestate.

15

State Cost Time Out (Sec)

Access 1.65 mJ/BlockIdle 1 1600 mW 0.5Idle 2 650 mW 2Idle 3 400 mW 27.5

Standby (disk down) 0 mWSpinup 6000 mJ

Spindown 6000 mJ

Table 2: Measured power state values and time-out valuesof an IBM Travelstar 12GN hard disk, adapted from [3]

2.3 Energy ProfilingTo provide precise energy accounting we have to assign themeasured energy consumption to the application that causesit. A simple approach is to sample power consumption andto assign the sample values to the thread currently usingthe processor. The results will be inaccurate due to the factthat simultaneously active hardware components could havebeen triggered by two different applications.

A more precise method to account energy online makesuse of performance counters embedded in modern proces-sors. Performance counters are implemented as hardwareregisters. By registering events that imply the consump-tion of a certain amount of energy at these counters, theoperating system is able to change its behavior and there-fore to adapt the expected power drain. For example, ahigh number of main memory references, although only alittle number of instructions were executed, could indicatethat performance is dominated by the main memory latency.Therefore, throttling the processor speed will improve theenergy efficiency without a significant negative impact onsystem performance.

3. ENERGY CONTROLTargeting a given battery lifetime means a limitation of thedischarge rate of the battery, shown in Table 1. Based on theinformation provided by hardware measurements, energy-aware operating systems must be able to adapt their schedul-ing so that the systems’ overall power consumption neverexceeds the demanded discharge rate. To provide energy-aware scheduling, mechanisms for accounting and distribu-tion of available energy resources among all competing tasksare required.

3.1 Energy ModelA prerequisite for energy accounting is an abstraction forthe resource energy. Such an abstraction is provided bythe Currentcy Model [5]. The model uses a common unit toaccount and allocate energy. The word currentcy is made upof the words currency and current since this unit is used topay for a certain amount of current. As the operating systemtargets a certain consumption rate, one unit represents theright to consume a certain amount of energy in a fixed timeinterval.

3.2 Control MechanismsEnergy management on operating systems requires mech-anisms for accurate accounting and effective distribution

of the resource energy. The following subsections describethree basic mechanisms: isolation, delegation, and subdivi-sion.

3.2.1 IsolationIsolation is an important security mechanism of process andmemory management in operating systems. Since applica-tions should not be able to drain energy from other applica-tions, isolation is therefore an important factor for energy-management, too.

3.2.2 DelegationDelegation allows a task to loan its available energy to othertasks. Therefore this is an important mechanism of inter-application cooperation. Donor and recipient of a delega-tion are both able to consume the delegated resource. Bydelegating resources from more than one donor to a singlerecipient, applications are able to contribute to expensiveoperations.

3.2.3 SubdivisionSubdivision allows a task the partitioning of its availableenergy. Combined with delegation, subdivision enables tasksto loan parts of their energy to other tasks. This is especiallyimportant for applications with child processes. In this casethe main task might want to be assured that child processesare not able to starve other components of the application.

4. ECOSYSTEMECOSystem is an implementation of the currentcy model,based on the Linux operating system. For handling energyas a first class resource, the kernel was modified to providemechanisms for allocating and accounting energy. This in-cludes a resource container object for the storage of energyunits. The prototype of ECOSystem was evaluated on anIBM Thinkpad T20 laptop with a set of microbenchmarkstargeting the CPU, the disk, and the network interface.

4.1 Currentcy AllocationECOSystem provides an interface to allow the user to seta target battery lifetime. The maximum discharge rate forthe battery depends on the targeted lifetime, as shown inSection 1.1. The difference between the current and themaximum discharge rate determines the amount of energythat can be allocated in a fixed time interval. This valuecorresponds to an amount of energy units that can be dis-tributed between all competing tasks. The distribution ofenergy is performed by a periodic kernel thread that modifiesthe values of all tasks’ resource containers periodically. If atask does not use all of its energy units, it can accumulatethese units up to a certain limit.

4.2 Currentcy AccountingPerforming system operations, like the execution of an in-struction or requesting data from a disk, requires a certainamount of energy. If a task wants to perform such an opera-tion, the operating system checks the corresponding energyvalue. If the value is sufficiently high, the operation will beexecuted. Otherwise, the task is blocked until it accumu-lated enough energy units for the requested operation.

16

Currentcy ModelApp CPU (mJ) HD (mJ) Net (mJ) Total (mJ)

DiskW 430 339,319 0 339,749NetRecv 256,571 0 553,838 810,409Compute 8,236,729 0 0 8,236,729

Program Counter SamplingApp CPU (mJ) HD (mJ) Net (mJ) Total (mJ)

DiskW 430 16 24 470NetRecv 256,571 9,235 20,206 286,012Compute 8,236,729 326,404 531,789 9,094,922

Table 3: Energy accounting: currentcy model vs. programcounter sampling, adapted from [5].

Due to the numerous, different energy characteristics ofmanaged devices, ECOSystem uses energy charging policieswith respect to these differences:

• CPU: Execution of instructions on the processor ischarged in dependence of a fixed power value and theprocessing time. A task running out of energy unitswill be preempted until it accumulates more units.

• Hard Disk: In addition to a fixed amount of energy forevery block accessed, all tasks that accessed the diskwithin the same session share the costs for spinning upand down the disk.

• Network Interface: Sending or receiving of data pack-ets is charged in dependence of the transmit power,the size of the packet, and the bitrate.

Assigning the costs of CPU operations to the correct taskis quite simple, whereas tracking the energy consumption ofthe disk or the network interface is more complex. Files inECOSystem are accessed through file related system calls.Hereby the container ID of the calling task is stored withinthe buffer cache entry of the disk. When the cache entry isactually written, the appropriate resource container will becharged for the operation. Source tasks of network opera-tions are identified by their associated source socket.

4.3 Energy AccountingThe result of an evaluation of the effectiveness of energy ac-counting implemented in ECOSystem is shown in Table 3.In this experiment three benchmarks were run simultane-ously on the system, each addressing a separate functionalunit. DiskW writes 4 KB of data every four seconds to thedisk, NetRecv receives continuously data from the networkinterface at the highest bitrate, and Compute is a batch jobrunning continuously on the processor. For comparison Ta-ble 3 shows the results of a similar run using a programcounter sampling technique.

ECOSystem assigns energy consumption to the appropri-ate application, whereas the results of the program countersampling show significant accounting errors. With programcounter sampling, energy consumption is measured periodi-cally and the values are assigned to the task currently run-ning on the CPU. The error in Table 3 arises from deviceoperations currently being executed but triggered by a taskthat it is not running.

1

1.2

1.4

1.6

1.8

2

2.2

2.4

1.2 1.4 1.6 1.8 2 2.2 2.4

Battery

Lifetim

e [hours

]

Targeted Lifetime [hours]

with correctionwithout correction

targeted lifetime

Figure 1: Targeted battery lifetime compared to the mea-sured lifetime, adapted from [5].

4.4 Battery LifetimeThe primary design objective for the development of ECOSys-tem was to achieve a targeted battery lifetime. As men-tioned in Section 2, offline measurements of closed mobilesystems could be inaccurate. This experiment shows a pos-sible impact of such an error on the battery lifetime.

In this experiment the system runs a CPU-intensive mi-crobenchmark. Additionally an accounting error is modeledby decreasing the power consumption value for the usageof the CPU. The usage of the CPU is now cheaper than itshould be and will lead to a shorter lifetime of the battery.Figure 1 shows the achieved lifetime of the system batteryin comparison to the targeted lifetime.

To handle such errors the operating system can make useof the Smart Battery interface. By periodically checking theremaining capacity of the battery, the discharge rate of thebattery and hence the amount of allocated energy can bedynamically adapted.

4.5 Energy SharingThis experiment demonstrates that ECOSystem is able tomanage energy sharing between simultaneously running ap-plications. One of the applications is ijpeg, a CPU-intensivegraphical application. The other application is netscape,which is mainly using the network interface. A performanceindicator for ijpeg is the computation speed and thereforeits CPU utilization. The performance of network applica-tions like netscape depends on response times and there-fore on page load latencies. Table 4 shows the measurementresults for various energy ratios between these two appli-cations, whereby the amount of allocated energy for bothapplications is set to 5 W.

The measurements show that both tasks match their tar-geted allocation. Although netscape makes use of all threefunctional units, ECOSystem tracks the power consumptionacross all devices accurately. The CPU utilization of ijpeg,and therefore its performance, increases nearly equivalentlyto the allocated power, whereas netscape shows a non-linearbehavior due to non-linear energy characteristics of the net-work interface.

17

a)

Energy Power Ave Power CPUShare Alloc (W) Used (W) Util (%)

70%:30% 3.5 3.507 22.55%60%:40% 3.0 3.008 19.34%50%:50% 2.5 2.500 16.08%40%:60% 2.0 2.008 12.91%30%:70% 1.5 1.503 9.67%20%:80% 1.0 1.005 6.46%

b)

Energy Power Ave Power PageShare Alloc (W) Used (W) Delay (s)

70%:30% 1.5 1.49 29.20560%:40% 2.0 2.006 17.44150%:50% 2.5 2.457 9.92840%:60% 3.0 2.961 6.32230%:70% 3.5 3.443 3.93420%:80% 4.0 3.663 3.032

Table 4: Results of energy sharing between ijpeg (a) andnetscape (b), adapted from [5].

5. CINDER OPERATING SYSTEMCinder is an operating system designed for modern mobilephones. It extends HiStar [4], a secure operating system thatprovides containers and gates in addition to conventionalkernel objects.

Every object in HiStar has to be referenced by a con-tainer including containers ifself. The hierarchical structureof containers is used by the Cinder operating system to deal-locate resources and therefore to implement a mechanism fordelegating and subdividing resources. Gates provide secureinter-process communication by using security labels for allobjects. This security concept of HiStar ensures isolation ofcontainers.

The Cinder operating system extends HiStar with twoadditional kernel objects: reserves and taps. These two ex-tensions to the kernel are explained in the following para-graphs.

5.1 ReservesReserves are kernel objects that permit the usage of energy.To determine the amount of energy a task is allowed to use,a power model similar to the currentcy model is used. Thevalue of a reserve is therefore a permission to use a certainamount of energy in a fixed time interval. If the value of a re-serve is not high enough for the operation the correspondingtask wants to perform, the kernel will prevent execution.

Although it is possible to partition a reserve’s value andassign it to other reserves, this is in most cases not practical,because threads rarely need to delegate fixed amounts ofenergy. Usually threads provide other threads with energyby using a fixed rate.

5.2 TapsIn order to guarantee a certain battery lifetime the dischargerate of the battery has to be limited. Transferring energybetween reserves with a fixed rate is therefore a better ap-proach than delegating fixed amounts of energy.

Taps are kernel objects that transfer a certain quantity of

RootReserve(15 kJ)

ThreadReserve

SystemBattery

Thread

0.1 xTap

750 mWTap

Figure 2: Consumption graph, adapted from [3].

energy between two reserves with a fixed rate. Therefore atap contains a rate, a source reserve, and a sink reserve. In-stead of transferring a fixed amount of energy, proportionaltaps transfer a certain fraction of the source reserves’ en-ergy to the sink reserve. In practice, taps are implementedas a thread whose job is to transfer energy values betweencorresponding reserves periodically.

5.3 Energy Consumption GraphDue to the hierarchical structure of reserves and taps, itis suitable to model it with a directed graph. The root ofsuch a directed graph represents the reserve connected to thesystem battery; all other reserves are a subdivision of thisroot reserve. A simple example of such a directed graphis shown in Figure 2. In this example the root reserve isconnected to the 15 kJ system battery. A single applicationdraws energy from a separate reserve connected to the rootreserve over a 750 mW tap.

5.4 Energy HoardingTasks can accumulate unused amounts of energy to use itfor future operations. However, to improve the performanceof the whole system, it is good practice to reclaim unusedenergy and assign it to other tasks. This problem can besolved by using backward taps. A backward tap transfersa fraction of the accumulated energy back to the source re-serve. The fraction of the backward tap is also a limitationfor the amount of energy the sink reserve is able to hoard.In Figure 2, a backward tap transfers 10 % of the reserve’saccumulated energy back to the root reserve. When the sinkreserve level in the example reaches 700 mW, both taps havethe same rate and therefore the level cannot raise anymore.

6. APPLICATIONSImproving the battery lifetime of a mobile system is justone goal of energy management. Another target is the per-formance the user expects. A common use case of modernsmartphones is to play music while browsing the internet.In this case user experience depends on the delay of net-work requests and a disruption-free playback of the musicfile. Although a user may accept varying delays, a disrup-tion of the playback will have an unacceptable impact on hisexperience.

The following subsections describe applications that weredeveloped on the Cinder operating system using reserves andtaps. They represent typical use cases operating systemshave to handle and will show the ability of this operatingsystem to control energy on mobile systems.

The platform on which Cinder is implemented and thefollowing applications are evaluated is an HTC Dream, whichis also known as Google G1. Because of its closed, integratedstructure measuring becomes a challenging task. Unfortu-nately the ARM11 core processor provides no performance

18

0

50000

100000

150000

200000

0 500 1000 1500 2000 25000100200300400500600700800

ReserveLevel(µJ)

Transferrate(KiB)

Time (seconds)

Reserve Level without Application Scaling

0

50000

100000

150000

200000

0 50 100 150 200 250 300 350 400 4500100200300400500600700800

ReserveLevel(µJ)

Transferrate(KiB)

Time (seconds)

Reserve Level with Application Scaling

Figure 3: The results of the image viewer application,adapted from [3].

counters. Therefore energy accounting is based on offlinemeasurements of device power states.

6.1 Energy Aware ApplicationsReserves and taps allow developers fine-grained control ofresources. Adapting the image quality of a graphical ap-plication to a given energy level is a good example for anenergy aware application.

The application described here is a network picture gallery.A thread separate from the main thread with a separatereserve handles the downloading of pictures. The rate ofthe tap between the reserves of the main application andthe download thread depends on the frequency of image re-quests and the size of the pictures. By periodically checkingthe resources’ energy level the application is able to adapt itsbehavior if the downloader is consuming energy too quickly.In this case the application requests only partial data fromthe interlaced PNG images.

Figure 3 shows the results of test runs with and with-out energy aware scaling where a batch of image requestsis made periodically. The line represents the energy levelof the downloader thread’s reserve, and the bars show theamount of data downloaded per image. A pause betweenthe batch requests allows the reserve of the downloader toaccumulate energy when using scaling. Without scaling thetransfer rate stays constant until the reserve runs out. Thisleads to a disruption of the downloader until the reserve hasaccumulated enough energy again. Therefore this examplemakes a trade-off between constant transfer rates and pic-ture quality.

6.2 Background ApplicationsBackground applications are another challenge for energymanagement. Despite being invisible for the user they mayinterfere with foreground applications and could thereforehave a negative impact on user experience.

The example in this section models an RSS reader and amail client. Each application has a reserve connected to a

RootReserve

ForegroundReserve RSS

Mail

14 mW

MailReserve

RSSReserve

BackgroundReserve

0 mW

137 mW

14 mW

137 mW

14 mW

Figure 4: The energy consumption graph for the backgroundapplication, adapted from [3].

Time (s)0 10 20 30 40 50 60

Est.Pow

er(mW)

0

40

80

120

160

A B

A in foregroundB in foreground

(a)

Time (s)0 10 20 30 40 50 60

Est.Pow

er(mW)

0

40

80

120

160

AB

A in foregroundB in foreground

(b)

Figure 5: The results of test runs with two tasks spinningfrom foreground to background, adapted from [3].

foreground and a background reserve, as shown in Figure 4.The taps to the background reserve have a constant smallrate of 14 mW for both applications. The rates of the tapsto the foreground reserve depend on the current state of atask. The task manager sets the foreground task tap to arate of 137 mW, which is the power the processor requiresto run. The rate of the background task is set to 0 mW andtherefore, the background task is not able to run the proces-sor until it accumulates enough energy from the backgroundreserve.

Figure 5a shows the results of a test run. The dark areasin Figure 5 show the power estimation for the two runningtasks and the dotted line is the result of an actual powermeasurement. Task A runs in the foreground in the 10 s till20 s interval, task B between 30 s and 40 s. Figure 5b showsa test run with a higher foreground rate of 300 mW. Withthe rate exceeding the required processor power, task A isable to accumulate the unused energy. Therefore task A hasstill enough energy to use the processor although set to thebackground and interferes with task B until energy runs outafter 40 s.

19

RootReserve

RSSReserve

RSS

Mail

NetworkServiceReserve

MailReserve

37.5 mW

37.5 mW

Figure 6: The energy consumption graph for the networkapplication, adapted from [3].

6.3 Network ApplicationsNetwork interfaces are very expensive regarding their energyconsumption. This is aggravated by the fact that they havea non-linear energy characteristic. Initial activation costsof a radio interface are very high but can be compensatedthrough bulk transfers. A common use case are backgroundapplications that make periodic use of the network interface.

This example describes the network access of two appli-cations over a network daemon, shown in Figure 6. Both ap-plications should make a poll every 60 seconds. Giving eachtask enough energy to activate the network daemon every 60seconds leads to the result shown in Figure 7a. Polling usesthe network interface just for a few seconds. The time be-tween the polls of the two different applications is thereforesufficient for the network interface to switch back to its idlemode and both tasks have to pay the full activation costsfor their polls.

A better approach is to implement the network daemonwith its own reserve to which the polling tasks can dele-gate their energy to. To activate the network interface, thesum of the reserves’ energy of the calling task and the net-work daemon must reach the activation costs. If the sum isnot high enough, the calling task delegates its energy to thedaemon’s reserve and blocks until enough energy is accumu-lated. Both of the polling tasks now only get enough energyto activate the network interface if they work in unison. Theresult of this implementation is shown in Figure 7b. Bothtasks are still polling every 60 seconds but now the networkinterface is activated only once in this period which leads toa significantly decreasing overall energy consumption.

7. CONCLUSIONThe performance of a mobile platform depends highly on thelifetime of the system battery. Improving energy manage-ment is therefore an important topic of research, especiallyconsidering that energy is a more and more limited and ex-pensive resource.

Abstracting energy to a first class resource and providingmechanisms to isolate, delegate, and subdivide it enablesoperating systems to manage energy on a fine-grained level.The evaluation of the presented applications developed on

0

0.5

1

1.5

2

0 200 400 600 800 1000 1200

Wat

ts

Seconds

Uncooperative Radio Access

0

0.5

1

1.5

2

0 200 400 600 800 1000 1200

Wat

ts

Seconds

Cooperative Radio Access Using Reserves and Limits

a)

b)

Figure 7: The results of test runs with (a) and without (b)a coordinated network stack, adapted from [3].

the Cinder operating system and ECOSystem shows thatthese systems are able to reach a given battery lifetime.Furthermore, these systems allow developers to implementenergy aware applications that will improve the user expe-rience by adapting the applications’ behavior to the currentenergy level.

However, it is uncertain if this approach improves theoverall energy efficiency, since there were no measurementsmade to compare energy consumption, performance and bat-tery lifetime of the evaluated systems with standard systems.Providing the ability to account and control energy on sucha fine-grained and accurate level requires a lot of additionalcomputation time that causes higher energy consumptionand a lower system performance. Consequently, it is doubt-ful if managing energy as a first class resource is a promisingapproach to improve energy efficiency on mobile platforms.

8. REFERENCES[1] Bellosa, F. The benefits of event-driven energy ac-

counting in power-sensitive systems. In Proceedings ofthe 9th ACM SIGOPS European Workshop (2000),pp. 37–42.

[2] Intel Corporation and Microsoft Corpo-ration and Toshiba Corporation. AdvancedConfiguration and Power Interface Specification.http://www.teleport.com/acpi, 1996.

[3] Roy, A., Rumble, S. M., Stutsman, R., Levis, P.,Mazieres, D., and Zeldovich, N. Energy manage-ment in mobile devices with the Cinder operating sys-tem. In Proceedings of the European Conference of Com-puter Systems 2011 (2011), pp. 139–152.

[4] Zeldovich, N., Boyd-Wickizer, S., Kohler, E., andMazieres, D. Making information flow explicit in HiS-tar. In Proceedings of the 7th Symposium on OperatingSystems Design and Implementation (2000), pp. 263–278.

[5] Zeng, H., Ellis, C. S., Lebeck, A. R., and Vahdat,A. ECOSystem: Managing energy as a first class operat-ing system resource. In Proceedings of the 10th Interna-tional Conference on Architectural Support for Program-ming Languages and Operating Systems (2003), pp. 123–132.

20

Runtime Environments and Software Frameworks

Jeremias IsnardyFriedrich-Alexander University Erlangen-Nuremberg

JeremiasIsnardy@web.de

ABSTRACTThe increasing need for mobile computer systems has engen-dered a new priority that has been neglected so far: aware-ness of the system’s energy consumption. Not only smart-phones, tablets or laptops should run as long as possible, butalso perpetual systems using environmental energy, whichshould be designed with energy-awareness in mind. Com-mon programming languages do not provide possibilities forthe programmer to adapt her code with records to energy.This document presents runtime environments and softwareframeworks designed to support the programmer at writingenergy-aware code: Eon [11], a programming language andruntime system for perpetual systems and EnerJ [10], a Javaextension introducing approximate data types.

1. INTRODUCTIONEnergy consumption of computer devices has become a mainconcern for developers with many challenges. The ques-tion, what a computer system can accomplish is closelyconnected to the availability of energy resources. Severalapproaches have been made to reduce energy consumptionon low-power architectures, performance/power trade-offsand resource management, which can be applied all withoutknowing the software. However, the programmer does nothave the opportunity to influence these approaches. Anotherway to manage the energy more efficient, is to allow energyconsiderations at the level of programming languages.

This can be derived in different ways. The followingSection 2 demonstrates one possible approach how to pro-vide functionality of managing energy for perpetual systems.These systems are a special kind of computer systems. Theyare designed in a way that they could run indefinitely justby harvesting energy of the environment; like solar or windenergy. Eon provides a programming language and runtimesystem for such systems, so that the programmer can imple-ment different scenarios depending on the available amountof energy. The section introduces the principle of Eon, ex-plains its functionality as a programming language and as aruntime system, shows experiments and evaluation results.

Section 3 shows a different more general approach. EnerJis an extension to the programming language Java and in-troduces a new approximate data type, which consumes lessenergy then common data types. The section explains theidea of EnerJ, how it is implemented and what hardware itneeds.

2. EON: A LANGUAGE AND RUNTIMESYSTEM FOR PERPETUAL SYSTEMS

Eon is both, a programming language and a runtime sys-tem, designed especially for the development of perpetualsystems. According to the authors Eon was the first energy-aware programming language (2007). It is based on the do-main-specific programming language Flux [2], which allowsprogrammers to build programs from different languages,including C and nesC. nesC stands for network embeddedsystems C, an extension to the C programming language,used to build applications for platforms using TinyOS.

2.1 Concepts of EonPerpetual systems have the property of running indefinitely.To do that, such systems are harvesting environment energy,e.g., motion, sun, wind or heat differentials. Nevertheless,harvesting energy sources and developing a perpetual systemface several challenges. Either energy is not always availableor it can be fluctuating. Depending on the purpose of thesystem, energy costs are also influenced by the environmentdynamically.

The main idea of Eon is to let the developer choose whichparts of the program are important and therefore should runcontinuously, and which parts can be deactivated when en-ergy is low. In that way the system can react to environ-mental changes automatically. Eon provides a simple wayto associate particular control flows with abstract energystates, representing the current available energy combinedwith an approximation for the near future. The Eon run-time system executes only those flows that are chosen forthe given energy state, managed by an integrated automaticenergy management. The energy states are described as arelative size (“high”, “low”), thus the programs are portableto other hardware platforms with different energy profiles.

2.2 Eon Programming LanguageEon is a coordination language [5] that combines code ofconventional languages, like Java, C or nesC. This way itis easy to separate code concerning energy from programlogic. Reusing existing code and porting Eon programs toother platforms are additional advantages. A coordinationlanguage describes the flow of data through different com-ponents.

Eon programming language uses the following structures:

• Source Node: Basically the leading program instanceproviding important data.

21

• Concrete Node: Corresponds to functions imple-mented in C or nesC. Required set of input data isprovided by the source nodes. It is producing a set ofoutput arguments.

• Abstract Node: Describes the flow of control anddata through multiple concrete or abstract nodes.

• Conditional Flows through Predicated Types,which need to be implemented by the programmer.The types are choosing one of the possible executionpaths.

• Eon Power States: Eon is able to perform runtimeadaptations. For this it is necessary so specify an adap-tation policy as a collection of adjustments organizedin a state ordering. Every state contains a list of ad-justments, sorted by their priorities.

• Adaptive Timers: To save energy the most commonadjustment is to disable components periodically. It isnecessary to define a range of intervals from which thetimer can choose.

• Energy-State Based Paths: Similar to the condi-tional flow an execution path will be chosen, but inthis case depending on the energy state.

Figure 1 shows a condensed example of Eon source code.The code was written for a GPS tracking device. The Eonprogramming language does not affect any program logic,but it manages the flow of the program, depending on choicesof the programmer or of the current energy state. The codewas designed to update GPS data in an appropriate rateand log them.It uses source nodes, like ListenBeacon (line 7) or GPSTimer(line 8) to get the important required data and to providethem for the concrete nodes, like GetGPS (line 12). The ac-tions of these nodes are implemented in C or nesC and arenot of any concern for Eon. The abstract node GPSFlow (line37) navigates the flow of the data, in this case from GetGPS

to another abstract node StoreGPSData (lines 38-39). Thisone is affected by the predicated type gotfix. Depending onit, StoreGPSData calls either LogGPSData (line 14) or Log-

GPSTimeout (line 16). Line 46 and 47 are defining a path,based on the energy state, which has been defined in line 32for high power. Depending on this energy state GPSTimer isgetting updated in an interval between 1 hour and 10 hours,for the high energy state. Otherwise only every 10 hours ifthe energy is low.

2.3 Eon Runtime SystemIt is not sufficient to have a programming language support-ing energy-aware coding only. It is also necessary to have aruntime system assembling it correctly. Choosing the idealenergy state for the system can be very sensitive.

The algorithm Eon uses to determine the ideal energystate tries to achieve the highest possible fidelity with thegiven energy while avoiding two energy states: empty (evenhigh priority flows can not be executed) and full (harvestedenergy can not be saved). The runtime system attempts tofind the ideal power state that is suitable as long as possible.Initially, it is assumed that the system runs at the highestenergy state and computes the amount of consumed andproduced energy over a short interval Ti. If the computation

1 // Predicate Types2 // SYNTAX: typedef PRED_TYPE PRED_TEST3 typedef gotfix TestGotFix;45 // Source Node Declaration6 // SYNTAX: NODENAME () => (OUTPUTS);7 ListenBeacon () => (msg_t msg);8 GPSTimer () => ();9

10 // Concrete Node Declaration11 // SYNTAX: NODEAME (INPUTS) => (OUTPUTS);12 GetGPS () =>13 (GpsData_t data , bool valid);}14 LogGPSData(GpsData_t data bool valid)15 => ();16 LogGPSTimeout(GpsData_t data bool valid)17 => ();18 LogConnectionEvent(msg_t msg) => ();1920 // Regular Sources21 // SYNTAX: source NODENAME => NODENAME;22 source ListenBeacon => HandleBeacon;2324 // Timer Sources25 // SYNTAX: source timer NODENAME26 => NODENAME;27 // Eon Timer Source28 source timer GPSTimer => GPSFlow;2930 // Eon States31 // there is always an implicit BASE state32 stateorder {HiPower };3334 // Abstract Nodes and Predicate Flows35 // SYNTAX: ABSTRACT [[type ,..][ state]] =36 // CONCRETE ->... CONCRETE;37 GPSFlow = GetGPS -> StoreGPSData;38 StoreGPSData :[*, gotfix ][*] = LogGPSData;39 StoreGPSData :[* ,*][*] = LogGPSTimeout;4041 // Abstract Node using Energy Predicates42 HandleBeacon :[* ,*][ HiPower]43 = LogConnectionEvent;4445 // Eon Adjustable Timer46 GPSTimer :[ HiPower] = (1 hr, 10 hr);47 GPSTimer :[*] = 10 hr;

Figure 1: Eon Code [11]

results in an empty battery, the system lowers the energystate and repeats the computation. Once Ti has been found,it examines longer intervals in the form of 2n ·Ti for n = 1..Nto make sure it is truly sustainable.

To adapt the energy state in the correct way, an accu-rate model of the energy consumption is required, containingenergy costs and frequency of each execution path or flow.Each time a flow completes, an exponentially weighted mov-ing average (EWMA) of the flow’s energy cost gets updated.

Additionally, an estimate of how much energy the systemis going to harvest in the future is required. Assuming thatthe energy production of the following days will be similar tothe recent days the prediction algorithm from Kanasl et al.[6,7] provides sufficiently accurate predictions.

2.4 ExperimentTo evaluate Eon, various deployments were conducted, in-cluding an automobile tracking system. Five GPS receivers,gaining their energy from the sun, were mounted on top ofthe roof of cars and have been tracked for two weeks. Dur-ing this time the weather was highly variable, thus also theenergy supply.

22

The collected data were used afterwards in a trace-drivensimulation extending the period of two weeks to three monthsto get an impression of the long-term behavior of Eon. Toavoid transient deviations, only the results of the last monthof the simulation were considered. Several test cases weresimulated, each with a different GPS sampling rate accord-ing to five energy policies:

• Conservative – minimum sustainable rate of all traces

• Greedy – maximum sustainable rate of all traces

• Best Static – best sustainable rate for each trace

• Eon – using a solar predictor algorithm

• Eon (Oracle) – using a perfect weather predictor

2.5 ResultsFigure 2 shows the average number of daily GPS readings,comparing the five different traces and the five different poli-cies. Every trace was exposed to a different amount of sunenergy, thus there are big variations among the traces.

Figure 2: Average number of daily GPS readings fordifferent energy policies and traces [11]

It should be mentioned that the best sustainable policyand the oracular Eon policy only exist in theory. Both wouldrequire an exact prediction of solar trends. Regarding thisfact, the Eon predictor achieves a surprisingly good resultcompared to the oracle. However, it is important to notethat the ratio between energy consumption and battery sizeis quite low. Thus, errors of the prediction algorithm do nothave much impact on this deployment.

Figure 3 shows the result from another perspective. Itcompares the amount of each trace’s energy that has beenconsumed by different parts of the system. The percentagenumber represents the average amount of time the trace wasspending with an empty battery. The board overhead isthe energy spent in the measurement board, the idle energyis the energy spent waiting and not executing a flow, theGPS energy was spent on taking samples, unused energy wasenergy left in the battery and wasted energy is any energythat was collected but could not be stored due to a fullycharged battery.

Figure 3 also demonstrates the advantages of Eon towardsthe conservative and greedy policies. The conservative one

Figure 3: Amount of energy consumed by differentparts of the system [11]

has a low sampling rate of GPS data and wastes a lot of col-lected energy. The greedy policy on the other hand has largeperiods of dead time. Eon accomplishes both, a good sam-pling rate and a good workload of the energy without havingany dead time.Additional experiments were conducted withEon, generating several further results.

A user study examined Eon regarding its usability. In itthe effort of coding a program with Eon and the performanceof this code were compared with the same task written in C.The participants of the Eon group did not have any difficul-ties to learn the ropes of Eon and finished the task in nearlythe same time as the C coders. Regarding the performanceof the program the big advantage of Eon emerged. For theEon coders it was quite easy to organize their program in amore efficient and in a more energy-aware way, respectively.

Eon needs additional computation to determine the idealenergy state. This computations need also some energy. Forthis reason Eon needed to be examined regarding a possibleoverhead. Some experiments showed that this needed addi-tional energy is so small compared to the remaining energyconsumption that it can be neglected.

As mentioned before the capacity of the battery has alsoan impact. If the capacity is small, errors of the predictionalgorithm can lead to dead times in the worst case. Figure 4demonstrates that the smaller the battery size the bigger therisk of a dead time. From a battery size of approximately150 mAhr this risk can be neglected.

3. ENERJ: APPROXIMATE DATA TYPESEnerJ is an extension to Java adding approximate data types.

3.1 Concept of EnerJMany applications or some sections in an application cantolerate inaccuracies. For these regions precise computa-tions are a waste of energy. EnerJ tries to exploit this factand introduces a new data type, especially designed to per-form computations not in a precise but an approximatedway. It introduces type qualifiers that distinguish betweenapproximate and precise data types and claims to be safeand general.

3.2 Type SystemThis section lists the extensions of EnerJ to Java and how todeal with it as a programmer. It outlines the changes made

23

Figure 4: Dead time of a device with different bat-tery sizes [11]

to Java and indicates several possible pitfalls.

Type AnnotationsEvery value has an approximate or a precise type, whichthe programmer can assign by using @Approx and @Precise

(since it is default, not necessary) respectively. It is notdesirable and thus not possible to assign an approximate-typed value into a precised-typed one. Only the oppositedirection is valid.

In some cases it can be necessary to work temporarilywith precise even when using approximated data. The pro-grammer has the option to use the endorsement concept,introduced by [1]. This allows her to use approximated dataas precise ones, as the following code example shows [10].

@Approx int a = ...;int p; // precise by defaultp = a // illegalp = endorse(a) // legal

OperationsWhen mixing the computations of precise and approximateddata, additional features need to be considered. This isachieved by overloading operators and methods based onthe type qualifiers. To ensure the correct choice of the op-erator, EnerJ implements a bidirectional type checking [3].So the computation of the approximated value a = b + c(both precise) returns an approximated value, even if theparameters b and d are both precise.

Control FlowApproximated data cannot be used in conditions, since itcould affect the control flow and thus violate the propertythat no information flows from approximated to precise data [10]:

@Approx int val = ...;boolean flag; // preciseif(val == 5) { flag = true; }else { flag = false; } // illegal

By using the introduced endorse concept, the programmeris able to work around this restriction.

ObjectsIt is also possible to create approximable classes. Clientshave the option to create precise and approximable instancesof it. To guarantee this possibility the @Context qualifier hasbeen introduced. All variables marked with it can be preciseor approximated, depending on the choice of the program-mer, as illustrated in the following code example [10]:

@Approximable class IntPair {@Context int x;@Context int y;@Approx int numAdditions = 0;void addToBoth(@Context int amount) {

x += amount;y += amount;numAdditions ++;

}}

This class has parameters x and y which can be both preciseand approximated and another parameter numAdditions whichis always an approximated one. The parameter amount ofthe function addToBoth is also depending on the program-mer’s choice.

It is not only possible to distinguish parameters but alsowhole methods. The programmer needs to write one for theprecise case and one for the approximated one, for exam-ple [10]:

@Approximable class FloatSet {@Context float[] nums = ...;float mean() {

float total = 0.0f;for (int i = 0; i < nums.length; ++i)

total += nums[i];return total / nums.length;

}

@Approx float mean_APPROX () {@Approx float total = 0.0f;for (int i = 0; i < nums.length; i += 2)

total += nums[i];return 2 * total / nums.length;

}}

To distinguish methods overloaded on precision the suffix_APPROX has been introduced. Both methods are calculatingthe mean value of all numbers saved in nums. In case ofthe approximated method, the calculation averages only halfof the numbers, saves computation steps and therefore alsoenergy.

3.3 Hardware RealizationIt is not sufficient to distinguish between approximated andprecise types at the programming level. Except for somecomputation steps one can save in an algorithm, there willnot be any energy savings if the hardware does not sup-port some kind of separation on the hardware level. Thusan approximation-aware execution substrate is needed.Withthe right choice of the hardware both, approximated storageand approximated operations can be used.

Approximated storage uses unreliable registers, data cachesand main memory. The register number respectively thememory address separates it from the precise data. Thephysical memory reserves regions for the approximated data.The approximated operations use specific instructions, whichcan use special functional units to perform them.

Figure 5 illustrates a hardware model providing approxi-mation-aware functionality. The shaded areas represent com-

24

ponents that support approximation. Registers and datacache use SRAM storage cells, which can be made approxi-mate by decreasing supply voltage. Functional units supportit in the same way, whereas floating point functional unitsadditionally can decrease the size of their mantissas. Mainmemory (DRAM) supports it by reducing the refresh rate.

Figure 5: Approximation-aware hardwaremodel [10]

Table 1 summarizes three different policies for the hard-ware settings to examine the amount of energy being savedby using approximated data. Numbers marked with * areclaimed to be educated guesses by the authors, the otherswere taken from literature. For every policy different adap-tations are used with an increasing impact to the hardwaresettings. E.g. the mild policy uses only small changes, ob-taining more accuracy but losing potential to save energy.

Table 1: Three different approximation strategies[10]

3.4 ExperimentIn order to evaluate EnerJ, a compiler and runtime systemhas been implemented to execute benchmark as if it wasrunning on an approximation-aware architecture. The cho-sen benchmarks are listed in Table 2. They are existing Javaprograms, modified with the approximated data type.

To gain any information about the energy savings, someassumptions have to be made. No overheads are consideredwhen implementing or switching to approximate hardware,like a latency when scaling the voltage. In addition only asimplified model with three components is influencing theenergy consumption:

• Instruction execution: To estimate the savings,abstract energy units are assigned to arithmetic oper-ations. These estimations are based on three studies[4, 8, 9]

• SRAM storage: SRAM storage and instructionsthat access it are assumed to account for 35% of the

Application Lines Prop. Total Annot. Endorse-of code FP decls. decls. ments

FFT 168 38.2% 85 33% 2SOR 36 55.2% 28 25% 0MonteCarlo 59 22.9% 15 20% 1SMM 38 39.7% 29 14% 0LU 283 31.4% 150 23% 3ZXing 26171 1.7% 11506 4% 247jMonkeyEng. 5962 44.2% 2104 19% 63ImageJ 156 0.0% 118 34% 18Raytracer 174 68.4% 92 33% 10

Table 2: Applications used as benchmarks [10]

microarchitecture’s power consumption. The rest of itis consumed by the remaining instruction executions.To compute the total CPU power savings both savingsare scaled accordingly.

• DRAM storage: A server-like setting has to be as-sumed, in which DRAM accounts for 45% of the powerand CPU 55%.

Considering the fact that various generous assumptionsare necessary to gain any information about the energy sav-ings the results should be considered as very optimistic.

3.5 ResultsThe functions listed in Table 2 are annotated manually withthe attempt to strike a balance between reliability and en-ergy savings. The first five applications are scientific algo-rithms from the SciMark2 benchmark. ZXing is a bar codedecoder for smartphones, jMonkeyEngine a game engine,ImageJ a raster image manipulation software and Raytracera 3D image renderer. The validity of these benchmarks ishard to evaluate. It can not be assumed that the authorsused the best possible adaptations for the applications. Byall means it would had been a better approach to use lessbenchmarks and to vary the amount of approximated datain it.

Figure 6 shows the normalized behavior of the energy con-sumption of all these applications. The bar labeled ”B” rep-resents the baseline value: the energy consumption withoutapproximated data types. The numbered bars correspond tothe different strategies introduced in Table 1. Every bar isdivided into several regions, each representing the individualportion of the energy consumption.

Each benchmark can be computed with less amount of en-ergy, depending on the aggressiveness of the used strategy.But saving energy is not the only aspect which need to beconsidered. Computing with approximated values insteadof precise ones leads to unavoidable errors in the results.Figure 7 compares these errors of each benchmark regard-ing the used strategy. Some of the results show huge errors,even for the medium strategy, whereas other ones only showneglectable deviances. No matter what, the use of approxi-mated data types will always be a tradeoff between qualityof data and energy savings.

25

Figure 6: Estimated CPU/memory system energyconsumed for each benchmark [10]

Figure 7: Output errors of the benchmarks depend-ing on the strategies [10]

4. CONCLUSIONDeveloping computer systems that are not only fast andreliable but also energy-aware is one of the big challengesin computer science today. Creating runtime systems andsoftware frameworks that allow the programmer to affectthe energy consumption directly is inevitable with respectto the future. This document presents two different ways toget more control of the energy flow in the system.

Eon, designed especially for perpetual systems, uses aquite simple approach. It allows the programmer to deter-mine different scenarios for different energy states, so it isup to him to decide how the system behaves having muchenergy or less. To ensure the correct implementation, Eonis not just a programming language but also a runtime sys-tem. So it is able to manage the desired code but alwayswith respect to the available energy. It is mainly designedfor perpetual systems and for these it is a suitable way tomanage available energy. But it should be mentioned thatit saves energy only at the expense of performance. It doesnot consider any ways to save energy in the system directlye.g. through hardware adaptations.

EnerJ tries to save energy of a system from a differentpoint of view. It introduces a new data type as an extensionto Java. This kind of data is only approximated so it doesnot need the same size of storage and is faster in computa-tion. In this way the usage of this new types can save a lot ofenergy. As easy as the approach sounds, it is quite difficultto integrate it in computer systems. The hardware of the

system has to be designed for it and the determination ofthe region in an application where it could be useful can byquite tricky.

Both approaches use different main ideas. But both areassociated with the mentioned disadvantages. Energy sav-ings may have become a main aspect for developers, butthere are a set of other aspects a programmer need to con-sider. Does the additional work pay off? Is the concept onethat is sustainable or will it vanish in the near future? Isthe program still portable with the used concept or does itneed a specified hardware? How much effort would it be tointegrate the concept into an existing project? A program-mer need to ask herself all these questions before using on ofthese introduced approaches or another one. There is andwill always be more to it than just saving energy.s

5. REFERENCES[1] Askarov, A., and Myers, A. A semantic framework

for declassification and endorsement. In ESOP (2010).

[2] Burns, B., Grimaldi, K., Kostadinov, A.,Berger, E. D., and Corner, M. D. Flux: Alanguage for programming high-performance servers.In Proceedings of USENIX Annual TechnicalConference (May 2006).

[3] Chlipala, A., Petersen, L., and Harper, R. Strictbidirectional type checking. In TLDI (2005).

[4] D.Brooks, V.Tiwari, and Martonosi, M. Wattch:a framework for architectural-level power analysis andoptimizations. In ISCA (2000).

[5] Gelernter, D., and Carriero, N. Coordinationlanguages and their significance. In Communicationsof the ACM (Februar 1992).

[6] Kansal, A., Hsu, J., Srivastava, M. B., andRaghunathan, V. Harvesting aware powermanagment for sensor networks. In DesignAutomation Conference (July 2006).

[7] Kansal, A., Jason Hsu, S. Z., and Srivastava,M. B. Power management in energy harvesting sensornetworks. In ACM Transactions on EmbeddedComputing Systems (May 2006).

[8] Li, S., Ahn, J. H., Strong, R., Brockman, J.,Tullsen, D., and Jouppi, N. Mcpat: An integratedpower, area, and timing modeling framework formulticore and manycore architectures. In MICRO(2009).

[9] Natarajan, K., Hanson, H., Keckler, S. W.,Moore, C. R., and Burger, D. Microprocessorpipeline energy analysiss. In ISLPED (2003).

[10] Sampson, A., Dietl, W., Fortuna, E.,Gnanapragasam, D., Ceze, L., and Grossman, D.EnerJ: Approximate Data Types for Safe and GeneralLow-Power Computation. In Proceedings ofProgramming Language Design and Implementation(PLDI ’11), California (June 2011).

[11] Sorber, J., Kostadinov, A., Garber, M.,Brennan, M., Corner, M. D., and Berger, E. D.Eon: A language and runtime system for perpetualsystems. In Proceedings of The Fifth InternationalACM Conference on Embedded Networked SensorSystems (SenSys ’07), Sydney (Nov. 2007).

26

Entwurf umweltfreundlicher Rechenzentren

Wolfgang RödleFriedrich-Alexander-Universität Erlangen-Nürnbergwolfgang.roedle@mb.stud.uni-erlangen.de

KURZBESCHREIBUNGIn der vorliegenden Ausarbeitung zum Thema umweltfreund-liche Rechenzentren geht es um Ansätze zur Reduzierungdes Energieverbrauchs großer verteilter Systeme und Rech-nerverbunde. Dabei wird genauer auf das Gebäudedesignam Beispiel des in Lockport (New York) erbauten Yahoo!Compute Coop-Rechenzentrums eingegangen. Die Bauform,die Innenarchitektur, die Ausrichtung und die klimatischenBedingungen des Standorts sorgen für einen geringeren Ener-gieverbrauch, indem dadurch auf aktive Kühlung (z. B. Lüfteroder Wasserkühlsysteme) verzichtet werden kann. Die Küh-lung der Computer erfolgt hierbei fast ausschließlich durcheinströmende Außenluft. Das Gebäudedesign von Yahoo! re-duziert auch den CO2-Ausstoß und den Wasserverbrauch bzw.verringert die Abwassermenge, welche bei den mit Wassergekühlten Anlagen anfällt. Ein weiterer Vorzug des Designssind die kürzeren Bauzeiten und damit geringeren Baukos-ten des Rechenzentrums, die durch die Einfachheit und dasverbaute Material ermöglicht werden.

Energieersparnis durch Gebäudearchitektur reicht jedochnicht aus, um ein Rechenzentrum umweltfreundlich zu ge-stalten. Das GREEN-NET-Framework bietet hier eine Mög-lichkeit an, zusätzlich Energie durch verbesserte energiege-wahre Software-Infrastruktur zu sparen. Der Ansatz versuchtEndbenutzern ein Gefühl für den Energieverbrauch ihrerProgramme zu verschaffen und zieht diese aktiv in Entschei-dungen über Leistung und Energieverbrauch mit ein.

1. EINFÜHRUNGDa Internetdienste immer mehr Funktionen bereitstellenund immer mehr Benutzer diese in Anspruch nehmen, seies von einem Desktop-Computer von zu Hause aus odermit einem Smartphone von unterwegs, werden auch mehrRechenzentren benötigt, die viel Strom verbrauchen. Derhohe Energieverbrauch kommt u. a. von ineffizienten Kühl-systemen und von betriebsbereiter IT-Ausrüstung, die überlängere Zeit ungenutzt bleibt. Die vorliegende Ausarbeitungfasst Möglichkeiten der Stromeinsparung von Rechenzentrenzusammen und geht dabei speziell auf die Gebäudearchitek-tur vom Yahoo!-Compute-Coop-Rechenzentrum sowie aufGREEN-NET ein. Letzteres Framework ermöglicht einer-seits, dass Rechenzentren energieeffizienter betrieben werdenkönnen, und andererseits deren CO2-Ausstoß zu verringern,der durch mit Kohleenergie angetriebene Lüfter und Kühlsys-teme anfällt. Bei der Gebäudearchitektur wird hauptsächlichder Strom durch Weglassung dieser Lüfter und Kühlsystemereduziert, wobei auf der Software-Seite bei den Internetdiens-ten der Strom durch Abschalten von unbenutzten Applika-

tionen und Netzknoten sowie durch direkten Zugriff auf dieHardware, wie CPUs oder Festplatten, realisiert wird.

Im zweiten Kapitel wird das „grüne“ Rechenzentrum vonYahoo! vorgestellt. Dabei wird genauer auf die Thermody-namik und die Kühlmethoden der Anlage eingegangen undanschließend Vergleiche zu ähnlichen Rechenzentren von Goo-gle und Facebook genannt. Das dritte Kapitel befasst sichmit einem Ansatz für Internetnetze und Clouds, die durchEinbeziehung der Endbenutzer energieeffizienter laufen sollen.Das vierte Kapitel liefert eine Diskussion über die vorgestell-ten Konzepte. Abschließend fasst das fünfte Kapitel kurzdie Möglichkeiten den Stromverbrauch bei Rechenzentren zureduzieren zusammen.

2. YAHOO! COMPUTE COOP (YCC)Das YCC-Rechenzentrum wurde aufgrund des Klimas inLockport errichtet. Dabei handelt es sich um ein Rechen-zentrum, dessen Server zu 99% durch Außenluft gekühltwerden, d. h. es fallen keine bzw. sehr geringe Kosten fürdie Klimatisierung an. Durch die spezielle Bauweise unddie Ausrichtung der einzelnen Gebäude werden thermody-namische Gesetze und die an diesem Standort günstigenWindbedingungen hervorragend ausgenutzt und sorgen da-durch für eine umweltfreundliche und kostenfreie Kühlung(„Free Cooling“) der Computer. Neben der Reduzierung vomStromverbrauch wird auch der Wasserverbrauch im Vergleichzu konventionellen, wassergekühlten Rechenzentren drastischverringert. Der Wasserverbrauch sinkt gegenüber konventio-neller Rechenzentren auf 5%. Auch der CO2-Ausstoß, derdurch Dieselmotoren angetriebene Lüfter entsteht, wird re-duziert, da sich die Anzahl der Lüfter auf ein Minimumbeschränkt. Der Standort Lockport ist nicht nur aufgrundseines Klimas geeignet, sondern auch aufgrund der Nähe zuden Niagarafällen, die sich 30 Kilometer westlich der Anlagebefinden. Damit kann die IT-Ausrüstung durch nachhalti-ge Energie betrieben werden. Diese Eigenschaften machendas YCC zu einem umweltfreundlichen, „grünen“ Rechen-zentrum. Zusätzlich gewähren die Gebäudearchitektur, dasBaumaterial und die Bauweise sowohl kürzere Bauzeiten undsomit geringere Baukosten als auch eine kostengünstigereInstandhaltung der Rechenzentren.

Die Designidee des YCC bringt viele Normenüberschrei-tungen der American Society of Heating, Refrigerating andAir-Conditioning Engineering (ASHRAE) mit sich und auchRisiken. Experten sind der Meinung, dass die Vorzüge dieRisiken bei weitem übersteigen und das Design in ZukunftStandard wird. Yahoo! besitzt bereits viele Patente für dasYCC und deren Technologien.

27

Abbildung 1: Luftstrom bei unklimatisierter Außen-luftkühlung [2]

2.1 KühlmethodenDas Gebäude nutzt eine Eigenschaft der Thermodynamik aus,welche besagt, dass wärmere Luft aufsteigt und Luftmassenunterschiedlicher Temperatur sich auszugleichen versuchen.Um eine geeignete Architektur zu finden, baute Yahoo! an-fangs ein Testlabor in Santa Clara (Kalifornien) [1]. Nachdemdieses sehr gute Ergebnisse lieferte, wurde das Compute-Coop-Projekt im Jahr 2009 gestartet. Die Abbildungen 1,2 und 3 zeigen die Bauform einer Hälfte des Gebäudes. Imoberen Bereich, dem Dachboden, der einzelnen Gebäude istein leerer Raum, der die durch die Server erwärmte Luftaufsteigen lässt. Das Schrägdach sorgt für den Abzug zurMitte hin, wo sich ein Kamin befindet. An den oberen Wän-den des Kamins und der unteren Außenwand des Gebäu-des befinden sich Lüftungsschlitze mit Filtersystemen, umdie für die Kühlung erforderliche Außenluft einströmen zulassen und diese von Schmutz- und Staubpartikeln zu be-freien. Sensoren liefern Daten über die Windgeschwindigkeitund die Lufttemperatur, die dann an Überwachungsgerä-ten ausgewertet werden. Anschließend wird mit Hilfe diesergewonnenen Daten einer der drei möglichen Kühlmodi derAnlage ausgewählt. Zusätzlich wird die Geschwindigkeit dereinströmenden Luft durch Dämpfungslüfter geregelt. Damitdie Computer die Luft zur Klimatisierung nutzen können,müssen sie in offenen Racks (dt. Regalen) gelagert werden [1,4]. Das Rechenzentrum wurde großflächig angelegt, sodasseine optimale Raumluftzirkulation gegeben ist. Frühere For-schungen ergaben, dass Temperaturen zwischen 16 und 18 ◦Coptimal für Datenzentren sind. Erfahrungswerte zeigten je-doch, dass Temperaturen von 27 ◦C vollkommen ausreichendsind [10]. Die drei bereits angesprochenen Kühlmodi werdenim Folgenden vorgestellt.

2.1.1 Vollständig unklimatisierte AußenluftkühlungBei Temperaturen von 21 ◦C bis 29,5 ◦C werden in diesem Mo-dus die Rechner nur durch Außenluft gekühlt. Diese strömtdurch Lüftungsschlitze an der äußeren Wand ein und wirddort gesäubert. Durch den leeren Raum im oberen Bereichdes Gebäudes steigt die durch die Server erwärmte Luft undwird durch die oben liegenden Lüftungsschlitze wieder nachaußen geleitet. Hierbei entsteht kein Overhead, also keinezusätzlichen Stromkosten durch Lüftersysteme.

2.1.2 Vollständig klimatisierte AußenluftkühlungBei Temperaturen von 29,5 ◦C bis 43,5 ◦C wird die Luft kurznach dem Einströmen in das Gebäude durch ein wasser-gesättigtes Medium geleitet, um Verdunstungskühlung zuermöglichen. Durch die Wasserpartikel in der Luft werden

Abbildung 2: Luftstrom bei klimatisierter Außenluft-kühlung [2]

Abbildung 3: Luftstrom bei Außen- und Innenluft-kühlung [2]

den Servern zusätzlich Wärme durch Verdunstung entzogen(siehe auch [5]).

Nur knapp neun Tage im Jahr befinden sich die Tempera-turen in diesem Bereich und die Anlage benötigt zum Klima-tisieren der Rechner diese zusätzliche Verdunstungskühlung.An den restlichen Tagen im Jahr reicht die Außenluft zurKühlung der Rechner aus.

2.1.3 Gemischte AußenluftkühlungIm Winter bzw. bei Temperaturen unter 21 ◦C wird einTeil der in den oberen, leeren Raum geleiteten Luft wiedernach unten gepumpt und mit der einströmenden Außenluftgemischt, um hohe Temperatur- und Luftfeuchtigkeitsunter-schiede zu verhindern. Dafür werden Ventilatoren an derDecke nahe der Außenwände eingesetzt.

2.2 Vergleich mit anderen RechenzentrenTabelle 1 zeigt einen Vergleich von Yahoo!s Rechenzentren.Die Einrichtung in Santa Clara wird mit Wasser gekühlt undbraucht damit zusätzlich Platz für die Wasserspeicherungund -leitungen sowie Energie für den Transport des Wassers.Die Anlage in Quincy (Washington) wird auch durch Au-ßenluft gekühlt, hat jedoch nicht die vorteilhafte Bauformdes YCC, um die Außenluft ohne viel Bearbeitung, das heißtohne Ventilatorsysteme, zur Kühlung der Server zu verwen-den. Es ist zu erkennen, dass die Anlagen in Lockport undQuincy durch neue Technologien deutliche Energieeinspa-rungen für die Server, also die IT-Ausrüstung, besitzen. DerEnergieverbrauch für die Kühlsysteme wurde bereits bei derAnlage in Quincy durch Ventilatoren statt Wasserkühlungstark verringert. Das YCC senkt diese nochmals um 90%.Die Effizienz ist – auch wenn es sich bei diesen Daten nurum erste Zahlen handelt – sichtbar.

Um ein übersichtliches Maß für den Energieverbrauch unddie Effizienz der Rechenzentren zu haben, wird das Maß PUE

28

SantaClara,CA

Quincy,WA

Lockport,NY

Leistungsaufnahmepro Server (W) 257 101 99

Leistungsaufnahmefür 25.000 Serverohne Kühlung (kW)

6.438 2.529 2.489

Leistungsaufnahmefür die Klimatisie-rung (kW)

2.285 434 46

Gesamte Leis-tungsaufnahmefür 25.000 Server(kW)

8.722 2.963 2.535

Tabelle 1: Analyse der Energieeffizienz von verschie-denen Rechenzentren von Yahoo! [1]

(Power usage effectiveness, dt. Effektivität der Stromnutzung)eingeführt [1, 11]:

PUE = Gesamter Energieverbrauch der AnlageEnergieverbrauch für die IT

Dieses stellt den gesamten Energieverbrauch der Anlageins Verhältnis zu dem Energieverbrauch, der ausschließlichdurch die IT anfällt. Zum Energieverbrauch der IT zählenu. a. Energieverbräuche von Rechnern, Speichereinheiten undNetzwerken. Der gesamte Energieverbrauch setzt sich ausden Verbräuchen der IT und aus den Energieverbräuchender Kühlsysteme, Kraftstoffnutzung, Stromverluste und sons-tigen Energieverbräuchen zusammen. Aus der Tabelle 2 gehtdeutlich hervor, dass dieses Verhältnis bei der YCC-Anlagebeinahe bei dem Wert 1,0 liegt und somit fast keine zusätzli-chen Energiekosten außerhalb der IT anfallen.

Die großen Einsparungen beim Kohlenstoffdioxidausstoßund bei der Energie sind der Tabelle 2 ebenfalls zu entnehmen.Sie zeigt die umweltfreundliche Seite des Gebäudedesigns.

Der PUE-Wert ist aufgrund seiner Neuheit nicht exaktdefiniert. Die meisten Organisationen wie Yahoo! oder Fa-cebook nehmen in den Gesamtverbrauch nur den gesamtenVerbrauch der Anlage auf, berücksichtigen jedoch nicht Ver-luste im Stromnetz, bei Transformatoren oder bei Generato-ren. Wenige Unternehmen nehmen diese Verluste ebenfalls imPUE mit auf. Im Vergleich dazu hat das neue Rechenzentrumvon Google einen PUE-Wert von 1,12, jedoch unter Einbezugsämtlicher Verluste. Mit der allgemeineren Rechnung liegtder PUE-Wert mit 1,06 sogar unter dem des Yahoo! ComputeCoop [9]. Die vorliegenden Werte der neuen Anlage von Fa-cebook schlagen die Rechenzentren von Yahoo! und Google.Dort wird ein PUE-Wert von bis zu 1,02 angegeben, wassomit fast dem Idealwert entspricht. Aktuelle Werte sind mitregelmäßigen Updates unter [12] abzulesen. Sie schwankenum den Wert 1,09.

Das Datenzentrum von Facebook in Prineville funktioniertgenau wie das YCC durch Kühlung der Server mit Außenluftund Wasserspritzdüsen für die heißen Tage im Jahr. Für die„open racks“ (dt. offene Computerregale) hat Facebook das„Open Compute Initiative“-Projekt gestartet [3] und sich zuder besonderen Bauform der Racks die zugehörigen Patentegesichert. Zudem kann die Anlage in Prineville Regenwasser

SantaClara,CA

Quincy,WA

Lockport,NY

PUE 1,62 1,27 1,08Relative Energie-einsparung für ein 9-MW-YCC-Gebäude(kWh/Jahr)

26.541.307 12.094.773 -

Durchschnittlichejährliche Kohlen-stoffdioxideinspa-rung (Tonnen CO2)

14.863 6.773 -

Tabelle 2: Energie- und Kohlenstoffeinsparung derRechenzentrumdesigns im Vergleich [1]

aufbereiten, nutzt Solarenergie und leitet die von den Servernausgestrahlte Wärme in Büroräume, um diese zu heizen [8].

Egal ob Yahoo!, Google, Facebook oder andere Unterneh-men, alle Unternehmen, die groß angelegte Rechnersystemefür Internetdienste nutzen, achten auf eine energieeffizienteund umweltfreundliche Gestaltung dieser Anlagen. Dabeiwerden natürliche Ressourcen, wie Flüsse, Wasserfälle oderSonnenlicht, herangezogen, um saubere, nachhaltige Energiezu nutzen.

3. GREEN-NET-FRAMEWORKEnergie- und Kohlenstoffdioxideinsparungen durch umwelt-freundliche Kühlsysteme reichen im Allgemeinen nicht aus,um den Energieverbrauch bei Rechenzentren zu minimierenund diese als umweltfreundlich und energieeffizient einzustu-fen. Ein Framework mit dem Namen GREEN-NET bietetdie Möglichkeit Energie zu sparen durch das Einbinden desEnbenutzers und dessen Entscheidungen. Das GREEN-NET-Framework zeichnet sich durch einen Top-down-Ansatz, deraus drei Stufen besteht, aus. Zunächst soll der Endbenutzerein Gefühl für den Energieverbrauch der von ihm benutztenInternetleistungen bekommen. Dabei werden Informationenzu den Energieverbräuchen seiner Programme gesammeltund graphisch dargestellt. In der zweiten Stufe soll der End-benutzer in Entscheidungen zur Reduzierung von Energie-verbrauch mit einbezogen werden, wodurch Applikationenund Rechenknoten, die unbenutzt aktiv laufen, abgeschaltetwerden. Zudem soll die Hardwareleistung reduziert werden,was hauptsächlich Taktfrequenzen von CPUs und Umdre-hungszahlen von Festplatten betrifft. Dabei muss stets einKompromiss zwischen Energiereduzierung („grüner Ansatz“)und der Leistung („Performance-Ansatz“) gefunden werden.Da der Endbenutzer diese Entscheidung am ehesten Treffenkann und sollte, wird er im GREEN-NET-Framework miteinbezogen. Die dritte Stufe umschließt die Unterstützung fürdas automatische Abschalten unbenutzter Netzwerkknoten.Für das Sammeln der Informationen, das Präsentieren derausgewerteten Daten und die Unterstützung automatisierterEnergiereduzierung, werden eigene Tools und Bibliothekenzur Verfügung gestellt. Da es sich hierbei um ein Forschungs-gebiet handelt, muss die reale Welt, welche die Endbenutzermit ihren Entscheidungen umfasst, simuliert werden. Hierfürwerden mögliche Entscheidungsrichtungen implementiert, diedie Benutzer allgemein treffen können. In den Richtlinien desGREEN-NET-Frameworks sind sechs Abstufungen zwischenLeistung („user“) und maximaler Energieersparnis unter Ein-

29

haltung gegebener Fristen („deadlined“) vorgesehen.

3.1 Informieren des EndbenutzersUm den Endbenutzer in Energiesparentscheidungen mit ein-zubeziehen, muss der Benutzer in erster Linie über den Ener-gieverbrauch seiner Applikationen informiert werden. Dafürbietet zum Beispiel Google das sogenannte PowerMeter anoder Microsoft die Hohm-Cloud-Anwendung [13]. Zusätzlichzum Stromverbrauch kann sogar die Kohlenstoffdioxidemis-sion aufgrund des Energiegemisches des Wohnorts errechnetwerden. Es verschafft dem Benutzer ein Gefühl darüber,wie umweltschonend oder -verschmutzend dessen elektrischeGeräte betrieben werden. Beide Strommessgeräte beziehensich jedoch auf ein komplettes Gerät, wie zum Beispiel eineHeizung, Beleuchtung oder einen Computer und nicht aufeinzelne Programme. Es müssen auch Daten über den Ener-gieverbrauch der Endbenutzer über Monate und sogar Jahrehinweg gesammelt werden, um den Verlauf und die Entwick-lung darzustellen. Das datenschutzrechtliche Problem wirdan dieser Stelle offengelegt. Erst nach dem Sammeln und Ana-lysieren können die Strommesser dem Benutzer Vorschlägezum Energieverbrauch liefern.

Die für das hier beschriebene GREEN-NET-Frameworkbenutzte Messmethode misst den Verbrauch eines ganzenComputers in Testlaboren, die ein Rechenzentrum simulie-ren. Das HAMEG HM8115-2 ist ein Leistungsmesser, derverschiedene Informationen, wie Schein-, Wirk- und Blind-leistung und Phase messen kann [14]. Neben dem HAMEG-Leistungsmesser wird noch die Omegawatt box von Omega-Watt für Messungen von Knoten herangezogen. Das Mess-gerät wird für 162 Knoten verwendet, was dazu dient, denEnergieverbrauch verschiedener Knoten zu messen.

Um die gesammelten Daten über den Energieverbraucheinzelner Computer und Internetknoten zu vereinen, wurdeeine große Bibliothek implementiert.

Nach Auswertung der gesammelten Daten müssen dieErgebnisse den Endbenutzern zur Verfügung gestellt werden.Dafür gibt es die Möglichkeit die Ergebnisse auf eine Web-seite oder mit Hilfe von Internetdiensten dem Benutzer zurVerfügung zu stellen. Die Webseiten werden mit Hilfe desRRDtool-Programms verwendet, um den zeitlichen Verlaufdes Energieverbrauchs der Knoten, auf die die Applikatio-nen des Benutzers zugreifen, graphisch darstellen zu können.Dabei werden keine weiteren Informationen über die Nut-zung der Programme mitgeliefert. Die zweite Möglichkeitden Energieverbrauch über einen Internetdienst abzufragen,besteht darin einen genauen Zeitraum zu nennen, in dem dieProgramme auf einen bestimmten Knoten zugreifen.

3.2 Einbezug des EndbenutzersBei dem vorgestellten GREEN-NET-Framework besitzen dieEndbenutzer zwei Möglichkeiten in den Energieverbrauchaktiv einzugreifen.

• Zum einen können sie explizit angeben, welche Teile derHardware abgeschaltet werden können, da sie für diederzeitig laufenden Programme weniger relevant sind.Dies bezieht sich rein auf ihre Applikationen. Hierfürmuss der Benutzer bei jedem Aufruf eines neuen Pro-gramms erneut entscheiden, welche Teile der Hardwareabgeschaltet werden können bzw. wie viel Leistungvon den jeweiligen Geräten vonnöten ist. Dafür muss

der Benutzer genaue Kenntnisse über sein Programmbesitzen.

• Die zweite Möglichkeit besteht darin, dass die Endbe-nutzer der Middleware ein Verhalten vorgeben. Damitnehmen sie Einfluss auf das ganze System und u. a.auch auf Knoten, die komplett abgeschaltet werdenkönnen. Das Verhalten schwankt zwischen Energiespa-ren und hoher Leistung. Bei dieser Möglichkeit mussder Benutzer nicht genau die Hardwarevoraussetzungenseiner Programme kennen.

Je nachdem, wie sich die Benutzer entscheiden, mussdie Hardware den Wünschen der Benutzer nach Leistungoder Energieeffizienz eingestellt werden. Dafür gibt es einRessourcen- und Auftragsverwaltungssystem (Ressource andJob Management System (RJMS)), das für dieses Frameworkdynamisch angepasst werden musste – das sogenannte OAR.

Das OAR kann je nach Einstellung bzw. Wunsch desEndbenutzers die Drehzahl der Festplatte und die Taktfre-quenz der Prozessoren steuern. Damit können die Benutzerdirekt Einfluss auf die Hardware und damit auf den Energie-verbrauch der Computer nehmen. Da es sich bei OAR umeine quelloffene Software handelt, sind weitere Entwicklun-gen, wie das Abschalten von Netzwerkknoten, noch in derEntwicklung.

An dieser Stelle werden bei den Laborversuchen die Ent-scheidungen der Benutzer über den Kompromiss zwischenhoher Leistung und Energieersparnis durch die oben genann-te GREEN-NET-Strategie simuliert. Je nach Modus werdendie CPU-Taktfrequenz und/oder die Festplattendrehzahl ver-ringert. Die Skalierbarkeit für weitere Elemente befindet sichauch hier noch in der Erforschung.

3.3 Mechanismus zur automatisierten Sicher-stellung von Energiegewahrheit

Der Mechanismus zur automatisierten Sicherstellung vonEnergiegewahrheit umschließt das automatische Abschaltenvon Netzknoten oder sogar Computern, die gerade nichtgebraucht werden. An dieser Stelle wird wieder das OARherangezogen, das diese Funktion automatisch ermöglicht.

3.3.1 Energiereduzierung und LeistungsverlusteUm Leistung und Energieverbrauch gegeneinander abzuwä-gen, werden zwei Verwaltungsmodi für die anfallenden Aufträ-ge bereitgestellt. Zum einen wird ein Standard-Verwaltungs-modus verwendet, d. h. volle Leistung auch im unbenutztenZustand, und zum anderen ein stromsparender „grüner“ Ver-waltungsmodus, welcher unbenutzte Knoten selbstständigabschaltet und bei Allokationen wieder einschaltet. BeideVerwaltungsmodi wurden bei 50,32% Systemauslastung (Ab-bildung 5) und bei 89,62% Systemauslastung (Abbildung 6)gemessen und verglichen.

Die Abbildungen beschreiben den zeitlichen Verlauf desmomentanen Leistungsverbrauchs. Die rote Linie entsprichtdem normalen Verwaltungssystem, das durch aktiven Betrieballer Knoten einen konstanten Verlauf hat. Am Graphen fürdas grüne Verwaltungssystem, der schwarz eingezeichnet ist,kann man die Ein- und Ausschaltvorgänge der Rechenknotenerkennen. Die Fläche unterhalb der Graphen beschreibt denEnergieverbrauch.

In den beiden Abbildungen ist die Energieersparnis desgrünen Verwaltungsmodus deutlich zu erkennen. Die hohen

30

Abbildung 4: Energieverbrauch über die Zeit bei50,32% Systemauslastung

Werte am Anfang des Graphen in Abbildung 4 kommen vomHochfahren aller Knoten vor der Messung. Tabelle 3 stellt dieErgebnisse der Messungen übersichtlich dar. In beiden Fällenist durch den grünen Verwaltungsmodus ein Energiegewinnabzulesen. Ein Viertel des normalen Energieverbrauchs kannbei 50,32% der Systemauslastung gespart werden. Im Fal-le der höheren Systemauslastung ist dieser geringer, da esweniger Zeitfenster gibt, in denen Knoten unbenutzt unddamit abschaltbar sind. Jedoch entstehen durch das ständigeEin- und Ausschalten der Knoten extrem hohe Wartezeitenfür die Aufträge. Die durchschnittliche Wartezeit mit grü-nem Verwaltungsmodus bei halber Systemauslastung beträgtknapp 14 Minuten. An dieser Stelle bleibt zu konstatieren,dass das Leistungsvermögen stark unter der Energieersparnisleidet.

3.3.2 VorhersagenUm das Problem des Overheads (dt. Mehraufwand) bezogenauf die Wartezeit beim Ein- und Ausschalten der Netzknotenzu verbessern, bieten sich Vorhersagen an, mit deren Hilfevorausschauend Knoten aktiviert und deaktiviert werdensollen. Dadurch kann einerseits Energie gespart werden undandererseits die Leistung nur marginal beeinflusst werden;im besten Fall bleibt diese gänzlich unbeeinflusst. Hierfürwerden u. a. auch Schlupfzeiten (engl. slack times) berechnetund ausgenutzt.

Die Schlupfzeit ist die Zeit zwischen dem voraussichtlichenTerminationszeitpunkt und der Deadline eines Arbeitsauf-trags (siehe Abbildung 5) [15]. Sie beschreibt den Spielraumder Bearbeitung und damit die Dringlichkeit des Auftrags.Bei Unterbrechungen z. B. durch Interrupts wird die Fertig-stellung des Auftrags verzögert, wodurch sich der Schlupfverringert.

Durch Vorhersagen werden deutlich bessere Ergebnisseim Wettstreit zwischen Energiereduzierung und Leistungs-ausbeute erzielt.

Abbildung 5: Energieverbrauch über die Zeit bei89,62% Systemauslastung

4. DISKUSSIONDie guten PUE-Werte des YCC sind aus der Tabelle 2 abzu-lesen, jedoch ist anzumerken, dass das mit Wasser gekühl-te Rechenzentrum von Google gleichwertige Zahlen liefert.Es ist also nicht erforderlich das Design von YCC für einRechenzentrum heranzuziehen. Auch mit konventionellen,wassergekühlten Anlagen kann das Rechenzentrum durchniedrige PUE-Werte und Wiederverwendung des Wassersumweltfreundlich sein.

Die Kühlmethode des YCC funktioniert nur mit offenenRacks, da sonst das Kühlmittel, also die Luft, nicht dieServer erreichen kann. Auch wenn diese Racks immer mehrzu einem Standard werden, sind geschlossene Racks z. B.zum Mieten von Servern nötig, die in solchen Rechenanlagenohne zusätzlichen Aufwand für die Kühlung nicht eingesetztwerden können.

Wie in [10] beschrieben, liegt die optimale Außenlufttem-peratur für die Kühlung der Server bei 27 ◦C. Lockport bietetsich somit nicht als Standort an, da die Temperaturen nur imJuli durchschnittlich bei den optimalen Werten liegen [16].Im restlichen Jahr ist es deutlich kühler, sodass die Anlage imdritten Kühlmodus betrieben werden muss, d. h. mit Ventila-toren für die Mischung der kalten Außenluft mit der bereitserwärmten Innenluft. Ein wärmeres, maritimes Klima, wiez. B. in San Diego, ist als Standort für ein Rechenzentrumnach dem Design des YCC vorzuziehen.

Beim GREEN-NET-Framework setzen die Entwickler aufdas Verständnis und Wissen der Endbenutzer über ihre Soft-und Hardwarekomponenten. Das ist jedoch für die Benut-zung der Geräte nicht vonnöten und somit bei den wenigstenNutzern vorhanden. Die RJMS-Tools müssen die Benutzerzudem über Spezifikationen der Komponenten informierenbzw. ihnen Vorschläge zur Energiereduzierung liefern. Dieskostet zusätzlich Energie, was weitere Evaluationen erforder-lich macht.

Des Weiteren können die Endbenutzer zwischen Leistungund Energieersparnis wählen. Bei dieser Entscheidung werdendie meisten Endbenutzer die deutlich kürzeren Wartezeiten

31

Modus Normal Grün Normal GrünSystemauslastung 50,32 89,62Anzahl der Aufträge 309 188Gesamter Energie-verbrauch (kWh) 42,7 30,6 40,7 36,6

DurchschnittlicherEnergieverbrauch(kWh)

5,9 4,2 5,8 5,2

Wartezeit derAufträge im Durch-schnitt (s)

8 829 1 218

Tabelle 3: Gesamter Energieverbrauch und Warte-zeiten vom normalen und grünen Verwaltungsmo-dus [1]

Abbildung 6: Schlupf

(siehe Tabelle 3) und somit die Leistung der Energieersparnisvorziehen. Die hohen Leistungsverluste für größere Stromkos-tenersparnisse des Endbenutzers und Rechenzentrums sinddie Hauptkritikpunkte bei dem vorgestellten Ansatz. Vorher-sagen über Ressourcenallokationen sind deshalb unerlässlich,wenn sich dieser Ansatz bei den Endbenutzern durchsetzensoll.

5. ZUSAMMENFASSUNGDiese Ausarbeitung zeigt Ansätze, die dazu dienen Rechen-zentren umweltfreundlicher und energieeffizienter zu gestal-ten. Das Gebäudedesign von Yahoo! für Rechenzentren hatsich profiliert. Ein PUE-Wert von bis 1,08, 40% wenigerEnergieverbrauch für die gesamte Anlage und ein 95% ge-ringerer Wasserverbrauch im Vergleich zu konventionellenAnlagen sind deutliche Indikatoren, die für eine Umstellungauf die neue Architektur von Rechenzentren sprechen [6, 7].Nicht nur bei Yahoo!, sondern auch bei anderen Unterneh-men wie Google und Facebook, ist diese Architektur für einenahezu kostenlose Klimatisierung der Rechner heute aktiv imEinsatz und höchster Stand der Technik von Kühlsystemenin Rechenzentren.

Das vorgestellte GREEN-NET-Framework bietet eineMöglichkeit, Energie durch Einwirken auf die Hardware zusparen. Dabei werden Netzwerkknoten abgeschaltet, Dreh-zahlen von Festplatten und Taktfrequenzen von Prozessorenindividuell eingestellt. Dieser grüne Ansatz zur Energieredu-zierung geht jedoch stark auf Kosten der Leistung. Hier sindweitere Entwicklungen nötig und genauere Messdaten überden Stromverbrauch von einzelnen Programmen erforderlich.Auch die individuelle Einstellbarkeit der Hardware benötigtweitere Forschung und Entwicklung. Grundsätzlich ist zu

sagen, dass allein das Informieren des Benutzers ein energie-bewussteres Verhalten schafft und womöglich den Verbrauchindirekt in Rechenzentren und zu Hause senkt.

6. LITERATUR[1] Da Costa, G., Dias De Assuncao, M., Gelas, J.P,

Georgious, Y., Lefevre, L., Orgerie, A.C, Pierson, J.M.,Richard, O, Sayah, A. Multi-facet approach to reduceenergy consumption in clouds and grids: TheGREEN-NET framework In: ACM/IEEE InternationalConference on Energy-Efficient Computing andNetworking (e-Energy), pp. 95-104. ACM, 2010.

[2] Bob Lytle, Chris Page. Yahoo! Compute Coop (YCC):A next-generation passive cooling design for datacenters, Juli 2011.

[3] Mark Hachman. Facebook launches ’open computeinitiative’ servers, Juli 2011.http://www.pcmag.com/article2/0,2817,2383257,00.asp,

[4] Open Racks. Triple racks for servers, 2011.http://www.opencompute.org/wp/wp-content/uploads/2011/07/DataCenter-Mechanical-Specifications.pdf

[5] Jay Park. Data center design director, Juli 2011.http://regmedia.co.uk/2011/04/07/facebook_open_com-pute_triple_rack.jpg

[6] Richard L. Brandt. Four companies that went green,Januar 2013.http://www.greencomputingreport.com/gcr/2013-01-04/four_companies_that_went_green.html?page=2

[7] Rich Miller. Inside the Yahoo Computing Coop,September 2010.http://www.datacenterknowledge.com/archives/2010/09-/20/inside-the-yahoo-computing-coop/

[8] Facebook. Press release: Facebook opens first datacenter in Prineville, Oregon, April 2011.https://www.facebook.com/notes/prineville-data-center/press-release-facebook-opens-first-data-center-in-prineville-oregon/10150150581753133

[9] Google. Effizienz: So machen wir das, 2013.http://www.google.com/about/datacenters/efficiency-/internal/

[10] Jürgen Kleinöder, Vorlesung zu energieeffizientenDatenzentren, Erlangen, 2013.

[11] Margarete Rouse. Power Usage Effectiveness (PUE),April 2009.http://searchdatacenter.techtarget.com/definition/power-usage-effectiveness-PUE

[12] Facebook. Prineville, OR data center, 2013.https://www.fbpuewue.com/prineville

[13] Werner Pluta. Microsoft Hohm hilft beim Stromsparen,Juni 2009. http://www.golem.de/0906/67997.html

[14] Hameg. Leistungsmessgerät, Juli 2013.http://www.hameg.com/1.147.0.html

[15] Fabian Scheler, Wolfgang Schröder-Preikschat,Real-time systems, 2012,. htt-ps://www4.cs.fau.de/Lehre/WS12/V_EZS/Vorlesung/

[16] u.s. climate data. Climate of Lockport, NY, 2013.http://www.usclimatedata.com/climate.php?lo-cation=USNY0827