ENERGY MANAGEMENT IN MOBILE DEVICES WITH THE

CINDER OPERATING SYSTEMArjun Roy, Stephen M. Rumble, Ryan Stutsman, Philip Levis,

David Mazières, Nickolai Zeldovich

PROBLEM

• memory and CPU time treated as first-class resources

• mobile devices are „the dominant end-user computing platform of the decade“

• energy is the new speed

• energy is not controllable at all

• (at least not like memory and CPU time)

MECHANISM

Reserve

• right to use a given quantity of a resource

• when the resource is used, the reserve is consumed

Tap

• conduit between a source and a sink reserve

• transfers specific rate of resource allowance

QUOTAS

energy isolation, subdivision and delegation

Figure 1. A 15 kJ battery, or root reserve, connected to a reservevia a tap. The battery is protected from being misused by the webbrowser. The web browser draws energy from an isolated reservewhich is fed by a 750 mW tap.

3.4 Resource Consumption GraphReserves and taps form a directed graph of resource con-sumption rights. The root of the graph is a reserve represent-ing the system battery; all other reserves are a subdivisionof this root reserve. Figure 1 shows a simple example of aweb browser whose consumption is rate limited using a tap.The tap guarantees that even if the browser is aggressivelyusing energy the battery will last at least 5 hours (15,000 J at0.750 J/s is about 5.6 hours).

3.5 Access Control & SecurityAny thread can create and share reserves or taps to subdivideand delegate its resources. This ability introduces a problemof fine-grained access control. To solve this, reserves andtaps are protected by a security label, like all other kernelobjects. The label describes the privileges needed to observe,modify, and use the reserve or tap.

Using resources from a reserve requires both observe andmodify privileges: observe because failed consumption indi-cates the reserve level (zero) and modify for when consump-tion succeeds. Since a tap actively moves resources betweena source and sink reserve, it needs privileges to observe andmodify both reserve levels; to aid with this, taps can haveprivileges embedded in them.

4. Cinder on the HTC DreamControlling energy requires measuring or estimating its con-sumption. This section describes Cinder’s implementationand its energy model. The Cinder kernel runs on AMD64,i386, and ARM architectures. All source code is freely avail-able under open-source licenses. Our principal experimentalplatform is the HTC Dream (Google G1), a modern smart-phone based on the Qualcomm MSM7201A chipset.

4.1 Energy accountingEnergy accounting on the HTC Dream is difficult due to theclosed nature of its hardware. It has a two-processor design,as shown in Figure 2. The operating system and applicationsrun on an ARM11 processor. A secure, closed ARM9 co-processor manages the most energy hungry, dynamic, andinformative components (e.g. GPS, radio, and battery sen-sors). The ARM9, for example, exposes the battery level asan integer from 0 to 100.

Recent work on processors has shown that fine-grainedperformance counters can enable accurate energy estimates

t

f(t)

ARM 9 (Closed):Modem, Power, GPS

ARM 11: Cinder,Application S/W

R

Figure 2. The two ARM cores in the MSM7201A chipset. Cinderruns on the ARM11, whereas the ARM9 controls access to sensitivehardware including the radio and GPS. The two communicate viashared memory and interrupt lines.

within a few percent [Economou 2006; Snowdon 2009].Without access to such state in the HTC Dream, however,Cinder relies on the simpler well-tested technique of build-ing a model from offline-measurements of device powerstates in a controlled setting [Flinn 1999b; Fonseca 2008;Zeng 2002]. Phones today use this approach, and so Cinderhas equivalent accuracy to commodity systems.

4.2 Power ModelOur energy model uses device states and their duration toestimate energy consumption. We measured the Dream’senergy consumption during various states and operations.All measurements were taken using an Agilent Technolo-gies E3644A, a DC power supply with a current sense re-sistor that can be sampled remotely via an RS-232 interface.We sampled both voltage and current approximately every200 ms, and aggregated our results from this data.

While idling in Cinder, the Dream uses about 699 mWand another 555 mW when the backlight is on. Spinning theCPU increases consumption by 137 mW. Memory-intensiveinstruction streams increase CPU power draw by 13% overa simple arithmetic loop. However, the HTC Dream doesnot have hardware support to estimate what percentage ofinstructions are memory accesses. The ARM processor alsolacks a floating point unit, leaving us with only integer,control flow, and memory instructions. For these reasons,our CPU model currently does not take instruction mix intoaccount and assumes the worst case power draw (all memoryintensive operations).

4.3 Peripheral PowerThe baseline cost of activating the radio is exceptionallyhigh: small isolated transfers are about 1000 times more ex-pensive, per byte, than large transfers. Figure 3 demonstratesthe cost of activating the radio and sending UDP packetsto an echo server that returns the same contents. Resultsdemonstrate that the overhead involved dominates the total

SAVING ENERGY

0 5

10 15 20 25 30 35 40

0 5 10 15 20 25 30 35 40

Jou

les

Packets per Second

10 Second Flow Energy Usage Across Packet Sizes and Rates

1500 bytes/pkt750 bytes/pkt

1 bytes/pkt

Figure 3. Radio data path power consumption for 10 secondflows across six different packet rates and three packet sizes. Shortflows are dominated by the 9.5 J baseline cost shown in Figure 4.For this simple static test, data rate has only a small effect on thetotal energy consumption. The average cost is 14.3 J (minimum:10.5, maximum: 17.6).

0

0.5

1

1.5

2

0 50 100 150 200 250 300 350 400

Wa

tts

Seconds

Radio Activation Power Draw

Figure 4. Cost of transitioning from the lowest radio power stateto active. One UDP packet is transmitted approximately every40 seconds to enable the radio. The device fully sleeps after 20 sec-onds, but the average plateau consumes an additional 9.5 J of en-ergy over baseline (minimum 8.8 J, maximum 11.9 J). Power con-sumption for a stationary device can often be predicted with rea-sonable accuracy, but outliers, such as the penultimate transition,occur unpredictably.

power cost for flows lasting less than 10 seconds in duration,regardless of the bitrate.

Figure 4 shows this activation cost. An application pow-ers up the radio by sending a single 1-byte UDP packet. Thesecure ARM9 automatically returns to a low power modeafter 20 seconds of inactivity. Because the ARM9 is closed,Cinder cannot change this inactivity timeout.

With this workload, it costs 9.5 joules to send a singlebyte! One lesson from this is that coordinating applicationsto amortize energy start-up costs could greatly improve en-ergy efficiency. In §5.5 we demonstrate how Cinder can usereserves and taps for exactly this purpose.

4.4 Mobility & Power Model ImprovementsCinder’s aim is to leverage advances in energy accounting(see §8.2) to allow users and applications to provision andmanage their limited budgets. Accurate energy accountingis an orthogonal and active area of research. Cinder is adapt-able and can take advantage of new accounting techniquesor information exposed by device manufacturers.

// Create a reserve

object_id_t res_id;

res_id = reserve_create(container_id, res_label);

objref res = OBJREF(container_id, res_id);

// Create a tap and connect it between

// the battery and the new reserve

object_id_t tap_id;

tap_id = tap_create(container_id, root_reserve,

res, tap_label);

objref tap = OBJREF(container_id, tap_id);

// Limit the child to 1 mW

tap_set_rate(tap, TAP_TYPE_CONST, 1);

if (fork() == 0) {

// child process: switch to new reserve before exec

self_set_active_reserve(res);

execv(args[0], args);

}

Figure 5. energywrap excerpt without error handling.

5. ApplicationsTo gain experience with Cinder’s abstractions, we devel-oped applications using reserves and taps. This section de-scribes these applications, including a command-line utilitythat augments existing applications with energy policies, anenergy constrained web browser that further isolates itselffrom its browser plugins, and a task manager application thatlimits energy consumption of background applications.

5.1 energywrap

Taking advantage of the composability of Cinder’s resourcegraph, the energywrap utility allows any application to besandboxed even if it is buggy or malicious. energywraptakes a rate limit and a path to an application binary. Theutility creates a new reserve and attaches it to the reserve inwhich energywrap started by a tap with the rate given asinput. After forking, energywrap begins drawing resourcesfrom the newly allocated reserve rather than the original re-serve of the parent process and executes the specified pro-gram. This allows even energy-unaware applications to beaugmented with energy policies.

The sandboxing policy provided by energywrap is im-plemented in about 100 lines of C++. An excerpt is shownin Figure 5. HiStar provides a wrap utility designed to iso-late applications with respect to privileges and storage re-sources. Coupling this utility with energywrap allows anyapplication or user to provide a virtualized environment toany thread or application. Section 6.1 evaluates the effec-tiveness of energy sandboxing and isolation.

energywrap has proved useful in implementing policieswhile designing and testing Cinder, particularly for legacyapplications that have no notion of reserves or taps. Sinceenergywrap runs an arbitrary executable, it is possible touse energywrap to wrap itself or shell scripts, which mayinvoke energywrap with other scripts or applications. This

LIMIT ENERGY HOARDING

Figure 6. (a) A web browser configured to run for at least 6 hourson a 15 kJ battery. The web browser further ensures that its plugincannot use more than 10% of its energy. (b) Adding 0.1x backwardproportional taps promotes sharing of excess energy unused by thebrowser and plugin.

allows a wide class of ad hoc policies to be scripted usingstandard shell scripting or on-the-fly at the command line.

5.2 Fine-grained ControlMobile browsers now support plugins like Adobe Flash [Fla2009], and we can expect more plugins and extensions tofollow. On a device where resources are precious, it is im-portant to have tight control over these plugins.

In Cinder, an application may be given some fixed rate orquota of energy using reserves and taps. A web browser may,for example, want to also run a plugin while ensuring that itcannot starve other plugins or even the browser itself. Shownin Figure 6a, the browser can allocate a separate reserve forthe plugin and connect it to its own energy via a low rate tap.

Often a single plugin (e.g. Flash) may be handling anumber of pages or requests all in a single process. To scalethe energy given to the plugin with the number of pagesit is handling, the browser can add a tap per page. Whena particular page is no longer being handled (e.g. the usernavigates away) the taps associated with that page can beautomatically garbage collected, effectively revoking thosepower sources.

Cinder includes a simple graphical web browser basedon links2 that runs in Xorg or standalone against the frame-buffer. It is augmented with an extension running in a sepa-rate process, whose energy usage is subdivided and isolatedfrom the browser. The browser can send requests to the ex-tension process (for ad blocking, etc.), and if the extension isunresponsive due to lack of energy the browser can displaythe unaugmented page.

5.2.1 Reclaiming Unused ResourcesConsider a problem common to many applications: a webbrowser would like to allow a plugin to consume resourcesquickly while making sure it shares unused resources. Theplugin may fully utilize peripherals and drive the device atpeak power, requiring a reserve fed with a high rate tap. Thisraises a problem: if the plugin draws less than its tap rate, the

reserve will slowly fill with energy that no other applicationcan use.

To solve this problem, an application can use a propor-tional tap. These taps transfer a fraction of their source re-serve’s resource per unit time, rather than a fixed quantity.Figure 6b shows the fix to the browser; the plugin reserveon the right is limited to a maximum average power draw of70 mW. The backwards proportional tap means the pluginreserve can store up to 10 s of this power (700 mJ) for burstyoperations. Once the reserve reaches 700 mJ, the backwardsproportional tap drains the reserve as quickly as the forwardconstant tap fills it. Similarly, the browser’s reserve can ac-cumulate up to 7000 mJ while being forced to share unusedenergy with other applications.

5.2.2 Hoarding and Resource DecayBackward proportional taps alone are insufficient for pre-venting malicious applications from hoarding. Threads cansidestep taxation by creating a new reserve with no propor-tional taps and periodically transferring resources to it. Theapplication could, over time, accumulate energy equal to thebattery and starve the rest of the system.

To prevent this, Cinder could provide a reserve clone()

rather than reserve create(). This call would take a re-serve that an application has access to and create a newreserve taking care to duplicate any backward proportionaltaps that the application does not have the permission to re-move. Additionally, Cinder would need to disallow systemcalls that transfer resources from a fast-draining reserve to amore slow-draining reserve unless the caller has proper per-mission (that is, the permission to remove all the backwardtaps from the source reserve that do not have a correspond-ing backward tap at the target reserve).

These constraints eliminate hoarding, but complicate ap-plications that are not malicious. Therefore, in practice, Cin-der prevents hoarding by imposing a global, long-term decayof resources across all reserves; every reserve has an implicitproportional backward tap to the battery.

By default, Cinder is configured to leak 50% of reserveresources after a period of 10 minutes. This long (but shortcompared to the period between battery recharges) half-lifeallows applications to accumulate and store energy for sig-nificant periods, and permits the system to make large-scalelong-term hoarding impossible. ESX Server [Waldspurger2002] successfully uses a similar “idle memory tax” to miti-gate hoarding of unused memory between virtual machines.

Further experience with these abstractions is needed tounderstand whether the trade-offs associated with the morefundamental solution for hoarding are worth making.

5.3 Energy-Aware ApplicationsUsing Cinder, developers can gain fine-grained control ofresources within their applications, providing a better expe-rience to end users. This includes adaptive policies for pro-grams where partial or degraded results are still useful, and

TIDBITS

• applications can inspect their reserve and adapt

• different reserves for foreground and background operation

• executing a service depletes the caller’s reserve

• multiple caller’s can pool reserves to pay device startup cost

• netd short-sales reserve when receiving

EVALUATION

Figure 8. The mail checker and RSS feed downloader are con-strained to use up to 37.5 mW apiece. When making network re-quests, netd explicitly transfers energy from their reserves into itsown reserve. Once the requesting application’s reserve, combinedwith the netd reserve, has enough energy, the radio will turn on.This simple policy helps synchronize applications’ network access,reducing active radio time and saving energy.

life, as the process is trusted not to hoard energy and, byconstruction, only stores enough energy to activate the radiobefore being expended.

Cinder estimates the cost of radio access by trackingwhen network transmit and receive events occur. For in-stance, if the radio has been idle for 20 seconds or more,threads wishing to use the network must contribute enoughenergy to turn the radio on and maintain the active powerstate until it idles again (§4). Once the radio is on, back-to-back actions are cheaper than ones with more delay betweenthem because they extend the active period (delay the nextidle period) less significantly.

For example, if the radio has been active for one second,it will automatically idle again 19 seconds later, so transmit-ting now only extends the active period by 1 second. How-ever, if the radio is active but no packets have been sent orreceived for 15 seconds, transmitting now will extend theactive period by an additional 15 seconds – the same actionbecomes much more expensive.

This leaves the problem of how to charge for incomingpackets since energy has already been spent to receive them.To facilitate this, threads can debit their own reserves up toor into debt even if the cost can only be determined after-the-fact. This allows user space accounting; for example, inthis case the receiving thread under the control of netd’s sendgate debits its own reserve when packets are delivered to it.

Section 6.4 evaluates the effectiveness of netd in aidingcooperation between applications to increase the responsive-ness of services while retaining their energy budget.

6. EvaluationUsing the applications described in §5, we evaluate whetherCinder meets the requirements described in Sections 1 and2: can it control energy, provide visibility into the energy of arunning system, and provide subdivision, delegation, as wellas isolation? Furthermore, we evaluate whether Cinder canfacilitate dynamic energy-aware applications and improvea system’s energy efficiency by managing complex deviceswith non-linear power consumption.

Time (s)

0 10 20 30 40 50 60

Est

. P

ow

er

(mW

)

0

20

40

60

80

100

120

140

160

180

A

B

B1

B2

B forks B1

B forks B2

Figure 9. Stacked graph of Cinder’s CPU energy accountingestimates during isolated process execution. Process A’s energyconsumption is isolated from other processes’ energy use despiteB’s periodic spawning of child processes (B1 and B2). The sumof the estimated power of the individual processes closely matchesthe measured true power consumption of the CPU of about 139mW during this experiment.

All experiments exception the image viewer of §6.2 useCinder running on an HTC Dream. The image viewer evalu-ation was performed on a Lenovo T60p laptop. To measurepower draw, we connect the Dream to the Agilent E3644ADC power supply. To monitor reserve energy levels we usethe Dream’s serial port output.

6.1 Isolation, Subdivision, and Delegation: Buggy andMalicious Applications

We first show how a simple use case – protecting the systemfrom a buggy or malicious energy hog – requires isolation,subdivision, and delegation. Figure 9 shows a stacked plotof Cinder’s energy accounting estimates of two processes,A and B. In this experiment, the system is configured toevenly subdivide and delegate enough power to fully utilizethe CPU between the two processes (about 68 mW to eachprocess since running the CPU costs 137 mW).

Process B spawns a new child process at about 5 seconds(B1) and again at about 10 seconds (B2). Without reservesand taps, these additional processes would cause A to receivea smaller share of the CPU. Here, however, Process A isisolated from these forks and still consumes about 50% ofthe CPU (and power share).

This experiment highlights the fine-grained nature of Cin-der’s control: not only is A isolated from B, but B is also ableto protect itself from its own children, B1 and B2. Ratherthan have its children draw from B’s own reserve, B cre-ates two new reserves subdividing and delegating its powerto each using two taps. Each of the taps has one-quarter thepower of B’s tap, such that after spawning both they are us-ing half of B’s power. Figure 9 shows that both A and B’spolicies are composed and enforced in the expected way.

6.2 Subdivision and Delegation: Image ViewerTo demonstrate the practicality of energy-aware applicationsin Cinder, we used our image viewer described in §5.3,

ADAPTIVE APPLICATION

0

50000

100000

150000

200000

0 500 1000 1500 2000 2500 0 100 200 300 400 500 600 700 800

Re

serv

e L

eve

l (µ

J)

Tra

nsf

er

rate

(K

iB)

Time (seconds)

Reserve Level without Application Scaling

Figure 10. The same image viewer application as in §5.3, butwithout dynamic scaling of image quality. The line representsenergy in the downloader’s reserve while the bars represent theamount of data downloaded per image.

0

50000

100000

150000

200000

0 50 100 150 200 250 300 350 400 450 0 100 200 300 400 500 600 700 800

Re

serv

e L

eve

l (µ

J)

Tra

nsf

er

rate

(K

iB)

Time (seconds)

Reserve Level with Application Scaling

Figure 11. Image viewer with energy-aware scaling of imagequality enabled. As energy becomes scarce, quality is lowered andless data is downloaded per image. The experiment takes less thanone-fifth the time to complete within the energy budget versus thenon-adaptive viewer due to adaptation to reduced available energy.

tested with and without energy-aware image scaling. Thetests mimic a user loading a page of images, pausing to viewthe images, and then requesting more. We tracked the energyreserve levels, the amount of data transferred over the net-work interface, the download time for each batch of images,and the average bytes transferred per image over time. Eachimage was of similar size (⇠2.7 MiB) and each batch con-tained the same number of images. Pausing between batchesallowed the energy reserve for the downloader thread to fillat a constant rate. The first pause lasted for 40 seconds, witheach successive pause being 5 seconds shorter than the pre-vious pause, so a smaller amount of energy built up in thereserve after each batch was downloaded.

When image download sizes are not scaled back as inFigure 10, the amount of data transferred stays constant perbatch. With each successive batch, the amount of energy inthe reserve at the start of the batch decreases since the userpauses more briefly after downloading. Thus the reserve runsout soon after the start of each batch in this case, with theimage transfers stalling until enough energy is available forthe thread to continue, causing a long run time.

When image requests use energy-aware scaling as in Fig-ure 11, the quality of images and bytes transferred for eachimage drops as the energy level dips, and the transfer timeper image decreases with the smaller image data. Over thecourse of the test, the level of energy present in the reservedropped below the threshold, but never to zero. The images

downloaded 5 times more quickly than the viewer whichdoes not scale the images.

6.3 Delegation and Subdivision: BackgroundApplications

Section 5.4 presented a configuration where system power issubdivided into a highly powered task manager reserve anda low powered background reserve. These reserves delegatetheir energy to applications running in the foreground andbackground, respectively, allowing background applicationsto continue to make slow forward progress, but keepingforeground applications responsive. This experiment uses aconfiguration identical to Figure 7.

Figure 12a shows two processes spinning on the CPU,initially in the background. The background tap provides thetwo of them 14 mW, enough to keep the 137 mW CPU at10% utilization. At about 10 seconds, the task manager se-lects Process A as the foreground process, granting it enoughenergy to fully utilize the CPU (137 mW). Process B con-tinues to run according to its background power share of14 mW. At the 20 second mark, the task manager retiresProcess A to the background by setting its foreground taprate to 0 mW. At 30 seconds, the task manager gives ProcessB access to the foreground resources and, similarly, returnsit to the background at 40 seconds.

Figure 12b highlights the need for Cinder to preventlarge-scale hoarding. The configuration is the same ex-cept the foreground tap gives 300 mW of power. Because300 mW is greater than the CPU cost of 137 mW, applica-tions in the foreground can accumulate excess energy. Thetwo processes move in and out of the foreground as before,but this accumulated energy changes their behavior. When Bis moved to the foreground, A still has plenty of energy, andso competes with B for the CPU such that each receives a50% share. After A exhausts its energy, it returns to its orig-inal 14 mW. Shortly thereafter, B moves to the backgroundas well. But just as A did, B accumulated energy during itstime in the foreground and so is able to use ⇠90% of theCPU until it exhausts its reserve.

The system-wide half-life both caps the total energyhoarding possible during foreground operation and returnsapplications to the natural background power over a 10minute period. This allows a process to perform an elevatedamount of work briefly after returning to background statusif it underutilized its resources while in the foreground.

6.4 Delegation: Cooperative Network StackWe demonstrate the effectiveness of Cinder’s modified netd(shown in Figure 8), comparing it to an energy-unrestrictednetwork stack. In both experiments, an RSS feed downloaderstarts with a poll interval of 60 seconds. Fifteen secondslater, a mail fetcher daemon starts, also with a 60 secondpoll interval. Both applications are provided enough powerto start the radio every 60 seconds, if they work in unison.

0

50000

100000

150000

200000

0 500 1000 1500 2000 2500 0 100 200 300 400 500 600 700 800

Rese

rve L

eve

l (µ

J)

Tra

nsf

er

rate

(K

iB)

Time (seconds)

Reserve Level without Application Scaling

Figure 10. The same image viewer application as in §5.3, butwithout dynamic scaling of image quality. The line representsenergy in the downloader’s reserve while the bars represent theamount of data downloaded per image.

0

50000

100000

150000

200000

0 50 100 150 200 250 300 350 400 450 0 100 200 300 400 500 600 700 800

Rese

rve L

eve

l (µ

J)

Tra

nsf

er

rate

(K

iB)

Time (seconds)

Reserve Level with Application Scaling

Figure 11. Image viewer with energy-aware scaling of imagequality enabled. As energy becomes scarce, quality is lowered andless data is downloaded per image. The experiment takes less thanone-fifth the time to complete within the energy budget versus thenon-adaptive viewer due to adaptation to reduced available energy.

tested with and without energy-aware image scaling. Thetests mimic a user loading a page of images, pausing to viewthe images, and then requesting more. We tracked the energyreserve levels, the amount of data transferred over the net-work interface, the download time for each batch of images,and the average bytes transferred per image over time. Eachimage was of similar size (⇠2.7 MiB) and each batch con-tained the same number of images. Pausing between batchesallowed the energy reserve for the downloader thread to fillat a constant rate. The first pause lasted for 40 seconds, witheach successive pause being 5 seconds shorter than the pre-vious pause, so a smaller amount of energy built up in thereserve after each batch was downloaded.

When image download sizes are not scaled back as inFigure 10, the amount of data transferred stays constant perbatch. With each successive batch, the amount of energy inthe reserve at the start of the batch decreases since the userpauses more briefly after downloading. Thus the reserve runsout soon after the start of each batch in this case, with theimage transfers stalling until enough energy is available forthe thread to continue, causing a long run time.

When image requests use energy-aware scaling as in Fig-ure 11, the quality of images and bytes transferred for eachimage drops as the energy level dips, and the transfer timeper image decreases with the smaller image data. Over thecourse of the test, the level of energy present in the reservedropped below the threshold, but never to zero. The images

downloaded 5 times more quickly than the viewer whichdoes not scale the images.

6.3 Delegation and Subdivision: BackgroundApplications

Section 5.4 presented a configuration where system power issubdivided into a highly powered task manager reserve anda low powered background reserve. These reserves delegatetheir energy to applications running in the foreground andbackground, respectively, allowing background applicationsto continue to make slow forward progress, but keepingforeground applications responsive. This experiment uses aconfiguration identical to Figure 7.

Figure 12a shows two processes spinning on the CPU,initially in the background. The background tap provides thetwo of them 14 mW, enough to keep the 137 mW CPU at10% utilization. At about 10 seconds, the task manager se-lects Process A as the foreground process, granting it enoughenergy to fully utilize the CPU (137 mW). Process B con-tinues to run according to its background power share of14 mW. At the 20 second mark, the task manager retiresProcess A to the background by setting its foreground taprate to 0 mW. At 30 seconds, the task manager gives ProcessB access to the foreground resources and, similarly, returnsit to the background at 40 seconds.

Figure 12b highlights the need for Cinder to preventlarge-scale hoarding. The configuration is the same ex-cept the foreground tap gives 300 mW of power. Because300 mW is greater than the CPU cost of 137 mW, applica-tions in the foreground can accumulate excess energy. Thetwo processes move in and out of the foreground as before,but this accumulated energy changes their behavior. When Bis moved to the foreground, A still has plenty of energy, andso competes with B for the CPU such that each receives a50% share. After A exhausts its energy, it returns to its orig-inal 14 mW. Shortly thereafter, B moves to the backgroundas well. But just as A did, B accumulated energy during itstime in the foreground and so is able to use ⇠90% of theCPU until it exhausts its reserve.

The system-wide half-life both caps the total energyhoarding possible during foreground operation and returnsapplications to the natural background power over a 10minute period. This allows a process to perform an elevatedamount of work briefly after returning to background statusif it underutilized its resources while in the foreground.

6.4 Delegation: Cooperative Network StackWe demonstrate the effectiveness of Cinder’s modified netd(shown in Figure 8), comparing it to an energy-unrestrictednetwork stack. In both experiments, an RSS feed downloaderstarts with a poll interval of 60 seconds. Fifteen secondslater, a mail fetcher daemon starts, also with a 60 secondpoll interval. Both applications are provided enough powerto start the radio every 60 seconds, if they work in unison.

POOLING

Time (s)

0 10 20 30 40 50 60

Est

. P

ow

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

. P

ow

er

(mW

)

0

40

80

120

160

AB

A in foregroundB in foreground

(b)

Figure 12. Stacked graph of Cinder’s CPU energy accountingestimates as processes A and B spin on the CPU. Together, theyare allowed 14 mW while in the background. The task managerruns A in the foreground in the 10 - 20 second interval and B in theforeground during the 30 - 40 second interval. (a) shows the resultsfor the foreground tap providing the process with 137 mW (theprecise cost of using the CPU at 100%). (b) shows the foregroundtap providing the process with 300 mW. The dotted line showsactual power measurements compensated for baseline power drawwith an idle CPU and averaged over 1 second intervals.

0

0.5

1

1.5

2

0 200 400 600 800 1000 1200

Wa

tts

Seconds

Uncooperative Radio Access

0

0.5

1

1.5

2

0 200 400 600 800 1000 1200

Wa

tts

Seconds

Cooperative Radio Access Using Reserves and Limits

Figure 13. Two background applications, a pop3 mail and anRSS fetcher, each poll every sixty seconds. a) Since they are notcoordinated, their use of the radio is staggered, resulting in in-creased power consumption. Each application uses the radio for atmost a few seconds, but neither takes advantage of the other hav-ing brought the radio out of the low power idle state. b) The samemail and RSS background applications using reserves and limits tocoordinate their access to the radio data path. Enough energy is al-located to each application to turn the radio on every two minutes.By pooling their resources, they are able to turn the radio on at mostevery sixty seconds.

0

2

4

6

8

10

12

0 200 400 600 800 1000 1200

Jo

ule

s

Seconds

netd Reserve Level Over Time

Figure 14. The level of the reserve into which the two back-ground applications transfer their allotted joules. When the reservereaches a level sufficient to pay for the cost of transitioning the ra-dio to the active state, it is debited, the radio is turned on, and theprocesses proceed to use the network. Although Figure 4 showedan average 9.5 J cost to power up the radio, netd requires 125%of this level before turning the radio on, essentially mandating thatapplications have extra energy to transmit and receive subsequentpackets. Therefore, the reserve does not empty to 0.

Non-Coop Coop ImprovTotal Time 1201s 1201s N/A

Total Energy 1238J 1083J 12.5%Active Time 949s 510s 46.3%

Active Energy 1064J 594J 44.2%

Table 1. Improvements in energy consumption and active radiotime using cooperative resource sharing in Cinder. Energy use dueto the radio is reduced, resulting in a 12.5% total system powerreduction over the 20 minute experiment.

Figure 13a shows the uncooperative applications wastingenergy – running when the radio is idle and powering it upindependently. Neither combines efforts to amortize costs.

In comparison, Figure 13b shows what happens with themodified netd. Each application still only receives enoughenergy to activate the radio every two minutes; however,when they initiate network operations, their threads blockand contribute acquired energy to the netd reserve (Fig-ure 14). Since the two threads combine their power in thenetd reserve, every 60 seconds enough energy is saved touse the radio and both applications proceed simultaneously.

Using delegation, independent applications in Cinder au-tomatically collaborate, improving quality of service. In thiscase, the improved quality of service is increasing the fre-quency of mail and news checks by a factor of two, usingthe same energy budget. Table 1 shows the energy savings ofthe modified netd. In total, 12.5% less energy is used in thesame time interval for an equivalent amount of work. Whilesignificant, we stress that our baseline power consumptionis artificially dominant, as Cinder does nothing to place thehardware into lower power states while idle in contrast toLinux. We expect Cinder to provide greater improvement ona mature mobile platform that makes full use of power sav-ing features.

SUMMARY

• token-bucket shaping for energy use

• throttling threads when energy reserve is depleted

• enables energy isolation and controlled delegation

• applications can adapt and pool

0 50

100 150 200 250 300 350 400

Back

light

GSM CPU

RAM

Gra

phic

s

LCD

Res

t

Pow

er (m

W)

0%33%67%

100%

Figure 9: Video playback power breakdown. Aggregatepower excluding backlight is 453.5 mW.

0 50

100 150 200 250 300 350 400

Back

light

GSM CPU

RAM

Gra

phic

s

LCD

Audi

o

Res

t

Pow

er (m

W)

0%33%67%

100%

Figure 10: Power breakdown for sending an SMS. Ag-gregate power consumed is 302.2 mW, excluding back-light.

the contacts application and selecting a contact, typingand sending a 55-character message, then returning tothe home screen; lasting a total of 62 seconds. To en-sure the full cost of the GSM transaction is included, wemeasured power for an additional 20 seconds. The aver-age result of 10 iterations of this benchmark are shownin Figure 10. Again, the power for four backlight bright-ness levels is shown.

Power consumed is again dominated by the displaycomponents. The GSM radio shows an average power of66.3± 20.9 mW, only 7.9 mW greater than idle over thefull length of the benchmark, and accounting for 22 %of the aggregate power (excluding backlight). All othercomponents showed an RSD of below 3 %.

3.3.4 Phone call

Figure 11 shows the power consumption when makinga GSM phone call. The benchmark is trace-based, andincludes loading the dialer application, dialing a number,and making a 57-second call. The dialled device wasconfigured to automatically accept the call after 10 sec-

0 100 200 300 400 500 600 700 800

Back

light

GSM CPU

RAM

Gra

phic

s

LCD

Res

t

Pow

er (m

W)

0%33%67%

100%

Figure 11: GSM phone call average power. Excludingbacklight, the aggregate power is 1054.3 mW.

0 50

100 150 200 250 300 350 400 450

Back

light

GSM CPU WiF

iG

raph

ics

LCD

Res

t

GSM CPU WiF

iG

raph

ics

LCD

Res

t

Pow

er (m

W)

0%33%67%

100%

GPRSWiFi

Figure 12: Power consumption for the email macro-benchmark. Aggregate power consumption (excludingbacklight) is 610.0 mW over GPRS, and 432.4 mW forWiFi.

onds. Thus, the time spent in the call was approximately40 seconds, assuming a 7-second connection time. Thetotal benchmark runs for 77 seconds.

GSM power clearly dominates in this benchmark at832.4± 99.0 mW. Backlight is also significant, howevernote that its average power is lower than in other bench-marks, since Android disables the backlight during thecall. The backlight is active for approximately 45 % ofthe total benchmark.

3.3.5 Emailing

For this benchmark, we used Android’s email applica-tion to measure the cost of sending and receiving emails.The workload consisted of opening the email applica-tion, downloading and reading 5 emails (one of whichincluded a 60 KiB image) and replying to 2 of them. Theresults of the benchmark are shown in Figure 12, aver-aged over 10 iterations.

The power breakdown between the GPRS and WiFi

0 50

100 150 200 250 300 350 400

Back

light

GSM CPU

RAM

Gra

phic

s

LCD

Res

t

Pow

er (m

W)

0%33%67%

100%

Figure 9: Video playback power breakdown. Aggregatepower excluding backlight is 453.5 mW.

0 50

100 150 200 250 300 350 400

Back

light

GSM CPU

RAM

Gra

phic

s

LCD

Audi

o

Res

t

Pow

er (m

W)

0%33%67%

100%

Figure 10: Power breakdown for sending an SMS. Ag-gregate power consumed is 302.2 mW, excluding back-light.

the contacts application and selecting a contact, typingand sending a 55-character message, then returning tothe home screen; lasting a total of 62 seconds. To en-sure the full cost of the GSM transaction is included, wemeasured power for an additional 20 seconds. The aver-age result of 10 iterations of this benchmark are shownin Figure 10. Again, the power for four backlight bright-ness levels is shown.

Power consumed is again dominated by the displaycomponents. The GSM radio shows an average power of66.3± 20.9 mW, only 7.9 mW greater than idle over thefull length of the benchmark, and accounting for 22 %of the aggregate power (excluding backlight). All othercomponents showed an RSD of below 3 %.

3.3.4 Phone call

Figure 11 shows the power consumption when makinga GSM phone call. The benchmark is trace-based, andincludes loading the dialer application, dialing a number,and making a 57-second call. The dialled device wasconfigured to automatically accept the call after 10 sec-

0 100 200 300 400 500 600 700 800

Back

light

GSM CPU

RAM

Gra

phic

s

LCD

Res

t

Pow

er (m

W)

0%33%67%

100%

Figure 11: GSM phone call average power. Excludingbacklight, the aggregate power is 1054.3 mW.

0 50

100 150 200 250 300 350 400 450

Back

light

GSM CPU WiF

iG

raph

ics

LCD

Res

t

GSM CPU WiF

iG

raph

ics

LCD

Res

t

Pow

er (m

W)

0%33%67%

100%

GPRSWiFi

Figure 12: Power consumption for the email macro-benchmark. Aggregate power consumption (excludingbacklight) is 610.0 mW over GPRS, and 432.4 mW forWiFi.

onds. Thus, the time spent in the call was approximately40 seconds, assuming a 7-second connection time. Thetotal benchmark runs for 77 seconds.

GSM power clearly dominates in this benchmark at832.4± 99.0 mW. Backlight is also significant, howevernote that its average power is lower than in other bench-marks, since Android disables the backlight during thecall. The backlight is active for approximately 45 % ofthe total benchmark.

3.3.5 Emailing

For this benchmark, we used Android’s email applica-tion to measure the cost of sending and receiving emails.The workload consisted of opening the email applica-tion, downloading and reading 5 emails (one of whichincluded a 60 KiB image) and replying to 2 of them. Theresults of the benchmark are shown in Figure 12, aver-aged over 10 iterations.

The power breakdown between the GPRS and WiFi

DISCUSSION

• interesting mechanism, but does it allow useful management?

• thinking inside the box: energy should be like CPU time

• hard: deadlines are inherent, energy cap is not

• thinking outside the box: system does only useful work

• efficiency: order requests to use resource better

• adaptivity: quality-resource tradeoff