You are on page 1of 14

Wattson: Empowering Developers to

Estimate App Energy Consumption

Radhika Mittal‡ , Aman Kansal† , Ranveer Chandra†


‡ †
IIT Kharagpur, Kharagpur, India Microsoft Research, Redmond, WA
radhikamittal.iitkgp@gmail.com {kansal,ranveer}@microsoft.com

ABSTRACT the energy efficiency of the apps can significantly improve


Battery life is a critical performance and user experience the battery lifetime of smartphones.
metric on mobile devices. However, it is difficult for app de- However, very few tools are available for developers to
velopers to measure the energy used by their apps, and to ex- improve the energy efficiency of their apps. In fact, most
plore how energy use might change with conditions that vary developers are not even aware of the amount of energy their
outside of the developer’s control such as network conges- app consumes. While they could use a power meter to mea-
tion, choice of mobile operator, and user settings for screen sure the actual energy draw for their app in a lab during
brightness. These problems become even more challeng- test runs, such an approach is not used in practice because
ing because a large fraction of mobile apps are developed it requires the developers to purchase and set up the power
by small companies, freelance developers, or start-ups with- measurement equipment. Given that several developers are
out extensive laboratory infrastructure or expertise for power hobbyists and students who may not have access to a mea-
measurement. We present an energy emulation tool that al- surement lab, this approach becomes very cumbersome to
lows developers to estimate the energy use for their mobile use. Furthermore, it is very difficult to perform these mea-
apps on their development workstation itself. The proposed surements for all device hardware, all possible network con-
techniques scale the emulated resources including the pro- ditions, user settings for screen brightness, and so on. Also,
cessing speed and network characteristics to match the app the measurement only reveals the total power used and it is
behavior to that on a real mobile device. We also enable not obvious what the contribution of different components
exploring multiple operating conditions that the developers (CPU, network, or display) is, which makes it harder to fo-
cannot easily reproduce in their lab. The estimation of en- cus the optimization effort.
ergy relies on power models for various components, and we Another alternative is for developers to use the “battery
also add new power models for components not modeled in use” tool on Android phones, or the Nokia Energy Profiler
prior works such as AMOLED displays. We also present a (NEP) on Nokia Symbian phones. These tools help end-
prototype implementation of this tool and evaluate it through users identify apps that are energy hungry. However, they
comparisons with real device energy measurements. do not provide useful information in the app development
phase, and furthermore, the data is not detailed enough to
help the developer improve the energy efficiency of the app.
1. INTRODUCTION Profiling how energy might change with varying conditions
Poorly written apps can sap 30 to 40% of a phone’s bat- is cumbersome with this approach.
tery [8]. Battery lifetime is a common cause of frustration In this paper we present a system, called Wattson, that al-
in smartphone users. Several efforts in research and indus- lows a developer to estimate the energy consumed by her app
try are actively investigating techniques to improve the bat- over a custom run. It also enables the app developer to esti-
tery life of smartphones. These efforts range from improv- mate the energy consumption for different phone platforms
ing battery density, to dedicated processors and accelerators as well as different operating conditions. In addition to help-
to offloading computations from the application processor. ing app developers design energy efficient software, Wattson
However, despite these hardware innovations, the battery also helps identify energy hungry portions of the code at an
improvements are not visible to the user. One of the pri- early stage.
mary culprits is poorly written software, which can callously Wattson works in three steps. First, the app is run inside a
eat into the extra battery juice provided by the hardware im- mobile device emulator by the developer on her workstation.
provements. Wattson scales the resources from the development worksta-
A significant portion of the battery is used when the phone tion that are provided to the mobile device emulator so that
is actively used by the user. Over the last couple of years, the the application takes similar time to run as it would on a real
active time has mostly translated to the time when the user is mobile device. For instance, downloading a webpage over
running some app on her phone. Consequently, improving

1
a cellular data connection takes longer, and Wattson shapes also reduce the energy consumption of the app, performance
the network characteristics experienced by the mobile device and energy consumption are not always correlated. In some
emulator to be similar to those of a real cellular data connec- cases, two design choices can give exactly the same perfor-
tion. The scaling of resources is tuned to match different mance but consume significantly more energy.
operating conditions, such as variable network connectivity. Scenario 1: Downloading two different images: An app
Second, Wattson measures the resource consumption of the might need to display a picture, say as a background in their
app on the development workstation, and records a time se- game. Two pictures that have identical size and textural de-
ries for each component (CPU, display, network) of the mo- tail, might take the same amount of time to download and
bile device emulator for the time that the app is run. This render. However, depending on the colors used in the pic-
resource consumption is scaled to express the utilization lev- ture, the amount of energy consumed when displaying the
els as if the app was run on a real mobile device. Finally, it picture might be very different [4]. For example, in Figure 1,
processes the resource consumption time series through en- both the images have nearly the same resolution, but Image-
ergy models of the display, processor and the network, for 1 has colors that consume much higher power (1000mW)
desired operating conditions and user settings, and outputs a compared to Image-2 that consumes less than 500mW. Thus,
time series of the energy consumed by the app, broken down using Image2 can greatly reduce the app energy consump-
by component. tion.

1.1 Contributions
Wattson design makes the following contributions:
First, to the best of our knowledge, we present the first
system that can estimate an app’s energy consumption in dif-
ferent operating conditions (carrier, signal strength, bright-
ness) without requiring expensive lab equipment and explicit
measurements with repeated runs for each operating condi-
tion. (1) (2)
Second, we present techniques to scale resources on the
PC to match resource consumption on the phone. For ex- Figure 1: Image1 consumes display power of 1000mW
ample, we show how network traffic sent by an emulator and Image2 consumes display power of 500mW
connected over a high speed Internet link can be scaled to
match the performance as if it were running over a cellular Scenario 2: Batching multiple downloads: An app might
network. need multiple files to be downloaded at some intervals. They
Third, we expand the catalog of power models available can either be downloaded as and when required or all of
for mobile device components. For displays, while prior them can be downloaded at one go. The bandwidth used and
work provides models for LCD and OLED we found that user experience might remain the same in both cases. How-
AMOLED screens are not modeled well, and hence we pro- ever, multiple downloads would result in a larger amount
vide a new power model for AMOLED. For the cellular net- of energy wastage as each download would incur some tail
work, we expand the measured parameters to include more energy cost for the network [15]. Batching the downloads
mobile operators. would consume a much lower amount of energy. For exam-
We have tested our system with multiple applications, de- ple, both 10kB and 100kB downloads consume nearly 20J of
vices, network conditions, and carrier networks. Wattson energy. Thus, ten spaced out 10kB downloads could result
achieves correct performance scaling for a variety of com- in 200J of energy consumption, and batching them up could
monly performed application tasks. Average energy error save up to 90% of the energy.
varied from 4% to 9% across different apps. The accuracy Another design choice in app development is the trade-off
of energy estimation when compared with the variability in between native and hybrid apps. Native apps run nearly en-
hardware energy measurement for the same task over multi- tirely on the mobile device, and provide good performance.
ple runs indicates that Wattson can offer a better energy es- Hybrid apps use less custom code on the phone, and down-
timate by eliminating several variable factors such as back- load a large fraction of their content from their web site.
ground activity on the mobile device. Such a design offers portability across multiple mobile plat-
forms. There are obvious pros and cons of both designs.
2. NEED TO ESTIMATE APP ENERGY However, there exists no easy mechanism for a developer to
An app developer usually optimizes his app for perfor- realize the energy tradeoffs of hybrid vs. native apps.
mance. In most cases, this implies reducing the processing
and network latency, avoiding excessive memory use, and 3. Wattson SYSTEM DESIGN
sometimes, also reducing the bandwidth consumption. Al- The goal of Wattson is to compute the runtime energy
though it might seem that performance optimizations would consumption of an app without explicitly executing it on a

2
mobile device. Both total energy and time series of power carriers and signal strengths. Finally, we develop a new
consumption over time for each of the key components are model for AMOLED displays. The energy models may be
generated. developed for all mobile devices for which app deployment
One way to generate the total energy number is to mea- is intended; the number of models required may be reduced
sure the actual current being drawn by the phone when the by considering representative devices in various device classes
app is running. However, requiring every app developer (a with different screen sizes and cellular network types.
number of whom are hobbyists and enthusiasts) to install the A block diagram of Wattson design is shown in Figure 2.
measurement equipment is an arduous ask. Performing the The leftmost blocks represent the measurement of real de-
measurements also becomes tedious because the measure- vice power characteristics required for power model gener-
ments have variability due to differences in network condi- ation. This is only required for the development of Wattson
tions, background activities, such as email synchronization and the mobile app developer does not have to perform any
running on the phone, that may have no relationship to the of these measurements. They obtain the power models as
app that the developer is concerned with. While some of the part of Wattson. On the developer machine, the execution
background activities can be disabled, not all operating sys- APIs for the mobile device are provided to the test appli-
tem activities are under the developer’s control. Further, the cation, typically in the form of a mobile device emulator,
measurement only shows the total energy use and does not such as the Windows Phone Emulator or Android Emulator.
separate out the impact of display, network, and CPU that We insert resource scaling techniques between the emula-
can be important for the developer to make their optimiza- tor and the actual hardware on the developer machine. As
tion decisions. the app under test is executed on the emulator, we monitor
Instead, we investigate a modeling based approach in the the resource consumption using resource profiling methods
design of Wattson. Most mobile development toolchains available on the development workstation. In our prototype,
provide an emulator to assist in app development such as the the Windows performance profiling APIs are used to mon-
Android Emulator, or the Windows Phone Emulator. While itor resource use. The resource consumption monitored on
the emulators do not accurately reproduce all mobile device the scaled resources is used in the energy calculation block
characteristics, the low overhead of their use makes them to estimate the app energy using power models.
very beneficial for a variety of testing. The techniques de-
veloped in Wattson extend the capabilities of mobile device
Test Application
emulators to provide an estimate of the app battery consump-
tion.
However, the design of Wattson is non-trivial. A key chal- Emulated Mobile
Target Mobile Device Device APIs (Phone
lenge is that the utilization of resources on the developer’s Emulator)
workstation is very different than on the phone. The devel- Resource Scaling Resource
Resource Power
oper’s workstation, even if using a low end PC or a laptop, Profiling Profiling
Profiling
Hardware Resources
is a much more powerful device compared to the phone. For
Power Model
instance, a CPU utilization of 10% on a 3 GHz processor Generation Developer
Workstation
with 6MB of last level cache is not a good indicator of how
much CPU will be consumed on the phone. Second, tim-
Energy Calculation
ing of events might be different when running the app on
the emulator than on the phone. Network packets may ar-
App Energy use
rive much faster on the development machine, causing the
user clicks for the subsequent tasks to be sooner and this
may completely change the time spent on application tasks. Figure 2: Block diagram of Wattson components. The
These differences make it challenging to estimate the energy blocks shaded in gray are used for app development in
correctly using the emulator on the developer’s machine. existing systems. Wattson introduces additional blocks
enable energy estimation.
3.1 Design Overview We describe resource scaling and power modeling meth-
We address the above challenges using a “resource scal- ods for each of the modeled components in the rest of this
ing” approach. We scale down the powerful components of section.
the developer machine to match the capabilities of the mo-
bile device. New scaling methods are developed for the CPU 3.2 Cellular Network (3G)
and the network. One of the significant energy hogs on the phone is the
The other important component of Wattson is “power mod- cellular network interface. Prior work has shown that the
eling”. We use previously proposed models for CPU and cellular data interface by itself can consume about 1 W of
WiFi energy consumption. For the cellular interface, we power [15], and the instantaneous energy consumed by the
augment previously proposed models to work for different interface depends on the state of the network card.

3
3.2.1 Resource Scaling Bandwidth: The measurements in [20] show that 3G HS-
The goal of resource scaling is to obtain the network re- DPA download bandwidth varies from 500-2500 kbps and
source consumption of the application as if executed on a upload bandwidth varies from 200-1600 kbps. Our measure-
real cellular data link. One simple technique to simulate the ments showed bandwidths ranging from 1000-3000 kbps for
cellular network packet trace is to capture the packet activity download and 800-980 kbps for upload. The bandwidth
over the high speed network connection of the developer’s varies due to various reasons including changes in network
machine and then stretch the timing characteristics to match congestion, wireless channel quality at the phone location,
those on a lower speed link. For example, suppose a 10 sec- and other factors. We model all these variations using three
ond trace would take 30 seconds over the cellular interface, different bandwidth parameters denoting bandwidth under
one could multiply all time-stamps of the Ethernet packet good, average, and poor network link quality. The parame-
trace by 3. A more sophisticated alternative to stretch the ter values are set as shown in Table 1
trace would be replay the trace from the high speed interface Network quality Download (kbps) Upload (kbps)
on a lower speed interface simulated using a fine grained Good 2500 1600
packet level simulator, such as QualNet or ns-3. However, Average 1500 900
this technique has several drawbacks. A slower interface will Poor 500 200
affect other parameters of the network flow, such as the TCP
window size, which are not captured by stretching the high Table 1: Network scaling parameters for bandwidth.
speed packet trace. Also, the stretching will not produce the
corresponding impact on other resources such as the timing Loss: Wireless links also suffer significantly more losses
of user clicks or other tasks in the app that depends on net- compared to the high bandwidth Internet connection typi-
work activity. cally available on the development machine. To emulate link
The approach we have taken is to shape the network link losses, we use the well known Gilbert Elliot Channel Model,
bandwidth and latency such that the observed network ac- described in [23]. According to this model, the network is
tivity in terms of packets sent and received is similar to the assumed to be in one of two states, denoted good and bad,
activity that would be observed on a cellular data link for each with a different loss rate. The model also describes the
the same communication task. We accomplish this by intro- transition probabilities between the two states, that allows
ducing our resource scaling code at layer 2.5 in the network simulating the losses over time. The transition probabilities
stack, that is, between IP and the MAC layer. The delay, and the loss rates are shown in Figure 4. The loss rates vary
loss and bandwidth parameters are chosen to mimic differ- with the network link quality.
ent network conditions. Figure 3 illustrates this approach.
The network characteristics are governed by the parameters P=0.04
described below. Network Loss Rate

Loss Rate = 0 Good 0.2


Average 0.5
DEVELOPER Poor 0.8
APPLICATION IN Good
EMULATOR P=0.06
Wattson Bad

Uploaded Frames Scaled Download

Figure 4: Loss rate parameters used for network scaling.


3G Network
Layer 2.5 Traffic Shaper Parameters State switching time is 100ms for the above transition di-
Network Device Driver
agram.
Scaled Upload Downloaded Frames In certain instances, when the developer is using a slow
Internet connection for their developer machine, such as a
Figure 3: Resource scaling for the network using layer home Internet connection, then the underlying network may
2.5 traffic shaping. itself have non-negligible latency and losses. In this case,
Wattson should first probe and estimate the network latency
The latency, bandwidth and loss parameters for cellular using known methods [9] and then add on any additional
networks have been studied in several prior works in wireless resource scaling to the measured characteristics.
communications, and we rely on the existing literature to
guide our choice of these parameters. 3.2.2 Power Modeling
Latency: The measurement and modeling work in [7, 10] The power model for the 3G network must model not only
has characterized the cellular data link latency for 3G net- the active energy consumption when communicating data
works using a normal distribution with a mean of 200ms and but also the “tail” time, or the time for which the radio in-
a standard deviation of 100ms. We found this model to be terface remains in a higher power state after finishing the
valid in our own measurements of 3G network latency using communication activity. The tail time can be spent in the
ping tests. active state itself, known as DCH, or an intermediate state,

4
known as FACH where the radio power consumption is re- with signal strength.
duced but any further communication would require a small
amount of channel slot acquisition overhead. Some radios Signal Strength DCH (mW) FACH (mW)
may have a second lower powered intermediate state known High 600 300
as PCH. After the tail time is over, the radio falls down to its Medium 800 300
idle state where the energy consumption is very low. This Low 1500 400
model was studied in depth in [15, 16] for the AT&T UMTS
network. The presented model, known as the ARO model, Table 2: Cellular interface power variation with signal
allows back-calculating the radio power state from a network strength.
packet trace. We use a cellular network power model based
on this technique. Mobile Operators. The second setup uses a power meter
However, there are two aspects that have not been looked attached to the battery terminals of a smartphone to measure
at before. First, to the best of our knowledge, prior work has power. We connected multiple devices from different mobile
not studied when the energy states change across different operators available in our region: AT&T (Samsung Focus),
carriers. Second, the energy consumed at varying received T-Mobile (HTC HD7), Verizon (HTC Trophy), and Sprint
signal strengths has not been studied. (HTC Arrive). While T-Mobile and AT&T use GSM based
To fill in the above gaps, we set up two different experi- networks with the UMTS standard from 3GPP for data. Ver-
ments, as follows, illustrated in Figure 5. izon and Sprint use the Evolution-Data Optimized (EVDO)
standard from the CDMA2000 family provided by 3GPP2.
The tail behavior on the CDMA networks is different from
that observed on the GSM based operators in that the in-
termediate states are not used. The power trace for a small
download using the device connected to Sprint’s network is
shown in Figure 6 as an example.

2500

2000
Figure 5: Experimental setups for the network power
Power (mW)

measurements using Windows Phone and the 3G proto- 1500


type board 1000

Signal Strength. This testbed uses a cellular data devel- 500


opment board from Ericsson that exposes the antenna ports. 0
We connected an RF signal strength attenuator to the antenna 0 5 10 15 20 25
Time (s)
port to vary the incoming signal strength and performed the
measurements on a weekend when the network conditions
Figure 6: Network tail energy measurement for Sprint.
were lightly loaded. The setup was located where we typi-
The data communication ends near time = 7s along the
cally observed good signal strength. The power supply leads
x-axis but the radio stays in a higher power state for an
of the development board were connected to a power meter.
additional 10 seconds after that.
The attenuator allows us to change the signal strength re-
ceived by the cellular data interface. We varied the amount Performing similar measurements for all operators with
of data downloaded and uploaded at different signal strengths multiple download sizes, we obtain tail-state parameters shown
and measured the DCH and FACH power and tail times. in Table 3.
We observed that the power consumption in DCH and
FACH states increases as the signal strength decreases and Operator DCH FACH PCH
recorded the power values. Since a developer will likely AT&T 5s 12s 0
only emulate their application with a small number of signal T-Mobile 5s 1s 1s
strength variations, we discretize the signal strength to three Verizon 6s 0 0
levels. The power measurements for the AT&T network are Sprint 10s 0 0
shown in Table 2. While these power measurements are
taken using a radio interface board and not a phone, the idle Table 3: Tail state power parameters for different oper-
power of the board can be different from that of the phone ators.
but the differences between the power levels at different sig-
nal strengths come from the radio primarily and can be used The parameters measured for the different networks might
to adapt the power model for varying signal strengths. The change after the 3GPP Rel8 fast dormancy standards are
tail times for DCH (5sec) and FACH (12sec) did not vary adopted since the new standards allow for shorter active tail

5
times under certain conditions. The models above will need displays [4], several modern mobile devices use Active Ma-
to be modified to change the tail times depending on the con- trix OLED (AMOLED) displays. The existing power mod-
ditions for fast dormancy. els are not a good approximation for AMOLED displays
and hence we develop a new power model for this type of
3.3 WiFi Network displays. While the peak power of the display is similar to
The WiFi network also consumes significant power when that of the CPU and the network, the fraction of energy con-
in use but its power model and performance characteristics sumed by the display can be much larger than the other com-
are very different from the cellular network. The models ponents since the display is constantly active throughout an
used for WiFi are described below. application’s use. An accurate estimation is thus important
For cases where the developer machine is connected to the for this most dominant energy consumer.
Internet using WiFi (as is common for laptops), the resource The OLED power model shows linear and additive prop-
scaling aspect is not needed. Otherwise, resource scaling erties: the energy consumption of the display as a whole is
is performed using the same layer 2.5 approach as for the the sum of the energy consumption of the individual pixels
cellular network. The scaling parameters may be adjusted and the the energy use of a pixel is the sum of the R,G, and
for WiFi characteritics that are well studied in literature [1]. B components. Further, the power model for the R,G, and B
The power model for Wifi is based on the PSM model components is a linear function of the color component mag-
described in [11]. The Wifi interface can be in one of four nitudes, provided they are converted from the standard RGB
major states - Deep Sleep (10mW), Light Sleep (120mW), (sRGB) color space to linear RGB. For AMOLED displays
Idle (400mW), and High (600mW). When no packet trans- this model breaks down as the magnitude of the pixel color
fer takes place, it remains in Deep Sleep state. Brief power components increases. Figure 7 shows the power measured
spikes of 250mW at intervals of 100ms are observed in this for the Samsung Focus device with the AMOLED display
state, and these correspond to reception of beacons from an set to different colors. The R,G and B components labeled
associated AP. When a packet is to be transmitted, the inter- are converted to linear RGB. The linear model holds at low
face moves to the High power state immediately. If a packet magnitudes. However, at high magnitudes (the colors in the
is to be received, the radio can only learn about it at the next surface labeled B=255), the linear model no longer holds.
beacon, and then it moves to the High power state. The ra- The power is scaled down when each of the color compo-
dio remains at High power while the transfer is taking place, nents is emitting a higher intensity light.
and then moves to Idle state. It rises to High state from Idle
whenever it gets any packet to transmit or receive. If no
network activity occurs in Idle state for around 1s the radio
1400
moves to the Light Sleep state. The Light Sleep tail time
is 500ms, after which, if no network activity occurs, it falls 1200
B=255
back to Deep Sleep. If network activity does occur in ei- 1000
Power (mW)

ther the Idle or Light Sleep state, the radio changes its power 800
state to High again. Both Idle and Light Sleep states also
600
have regular spikes of additional 250mW of power spaced at
400
100ms to receive beacons.
The above power state transitions can be re-created di- 200
300 B=0
rectly if the network activity is known. Thus, we again cap- 300
200
ture the network trace using a network sniffing library as 200
100
part of Wattson. The trace can be combined with the power 100
0 0
model above to compute the power consumption. R G

3.4 Display Figure 7: Power measurements for different colors on an


As for other components we need to resource scale the AMOLED display.
display and model its power consumption. Fortunately, ex-
isting mobile device emulators already perform resource scal- Studying the AMOLED display characteristics with more
ing for the display: the emulated app is provided only a small measurements, we further found that the power consumed
screen area representing the mobile device display. The only is not just a function the color of a pixel but also depends
scaling needed is that the emulator window may be re-sized on the properties of the other pixels in the image. Thus, the
somewhat, changing the number of pixels in the display and additive nature of the OLED model also does not apply to
to overcome this, one may simply multiply the number of AMOLED. Figure 8 shows the power consumption at vary-
pixels by the appropriate scaling ratio. ing fractions of the screen set to white. The graph shows
The power model for the display is more challenging. While the power predicted using the additive OLED model where
prior work has provided power models for LCD and OLED the power would increase linearly with the area, as well as

6
the observed ground truth. It seems obvious that the power only significant for higher color magnitudes. The deviation
is scaled down as a greater portion of the screen is emitting does become significant at different threshold for different
brighter light levels. colors and we approximate that using four different thresh-
olds: one for R+G+B magnitude, and one each for R+G,
2500 G+B, and B+R magnitudes, denoted τRGB , τRG , τGB and
Measured OLED Model
2000 τBR respectively. The power scale down is assumed to be
1500 proportional to the fraction of such high intensity pixels.
Power (mW)

The final model is summarized as follows. Suppose the


1000
lookup entry for a color indexed by [r, g, b] by finding the
500 nearest index in the lookup table is denoted l(r, g, b). Let the
0 power consumption of the entire screen, obtained by sum-
10 30 50 70 90 ming up the powers over all pixels of a screen-shot s, be de-
White display fraction (%)
noted L(s). Suppose the fraction of pixels in s that exceed
Figure 8: AMOLED power changes as the fraction of either of the thresholds τRGB , τRG , τGB and τBR is denoted
white colored pixels changes. β(s). Also, suppose that the power consumption for the dis-
play using the additive OLED power model is computed as
Interestingly, we also found through additional measure- O(s). Then the power consumption when the screen display
ments that the scaling down of power not only depends on matches s is computed as:
area but varies by color. Figure 9 shows an example mea- Pdisplay = β(s) ∗ L(s) + (1 − β(s)) ∗ O(s) (1)
surement for two colors, compared with the OLED model
based predicted values. While the predicted values are dif- One further optimization to the above model is that in-
ferent for the two colors, what is important to note is that stead of considering all pixel values on the screen, we could
the difference between the measured and predicted values is randomly select a smaller fraction of the pixels and use those
also different for the two colors: s2 is significantly greater as representative of the entire screen. The accuracy of this
than s1. model along with sub-sampling is evaluated in Section 5.
From an implementation perspective, the pixel informa-
1480 RG - Meaured tion of the display is easy to obtain when an app is being
RG - OLED Model emulated. we simply capture the developer machine’s screen
1280
BR - Measured s1
1080 BR - OLED Model and extract the region corresponding to the emulator’s dis-
Power (mW)

880 s2 play area.


680 For completeness, we also measured the power consump-
480 tion of LCD displays with varying screen sizes at two dif-
280 ferent color levels, and the measurements are presented in
0 25 50 75 100 125 150 175 200 225 250 Table 4. The LCD can be modeled using simply the bright-
Linear R,G,B
ness level as the variation with color is not significant. As
expected, devices with different screen sizes do consume dif-
Figure 9: Change in power with color.
ferent amounts of energy and hence multiple models may be
incorporated in Wattson for different devices.
Such a power model becomes difficult to parameterize
since even though the area dependent power scaling could Brightness Color 3.6in 4.3in
be modeled using curve fitting, the curve parameters would Low Black 132 mW 294 mW
vary for each color. Thus, we use a lookup table spanning the White 127 mW 330 mW
entire R,G,B gamut of values, discretized to 16 color mag- Medium Black 363 mW 557 mW
nitudes per component, yielding a lookup table with 16 × White 359 mW 573 mW
16 × 16 = 4096 entries. The entries of this table contain High Black 559 mW 778 mW
the power value measured if the entire screen was set to White 554 mW 790 mW
that color, and in effect models the power scale down com-
pared to the additive model at 100% area coverage for that Table 4: Power measurements for LCD displays for HTC
color. The lookup table cannot be used directly however Arrive (3.6in screen size) and HTC HD7 (4.3in screen
because the power value does not follow the lookup table size).
when a color occupies less than the entire screen, and then its
power consumption is closer to that predicted by the additive
OLED model. Rather than fitting 4096 individual curves to 3.5 CPU
model the area dependant power variation for the basis col- Mobile devices use much lower power processors due to
ors, we make a implifying approximation that is based on their battery constraints compared to the processor used on
the observation that the deviation from the OLED model is the developer’s machine. The processor frequency, cache

7
hierarchy, and various computational units are different, re- to use dynamic voltage and frequency scaling (DVFS). How-
sulting in very different execution performance across the ever, DVFS only provides a few scaling levels and none of
two processors for the same computation. As for the net- these may correspond to the desired setting. Also, in typical
work, a simple mapping of phone CPU resource utilization implementations of DVFS all cores of a processor share the
level to the developer machine processor will not suffice as same supply rail and scaling down one core scales down the
the entire timing of the app activities depends on the CPU entire processor. This is undesirable as this will cause the en-
timing. Hence we need a resource scaling technique that tire developer machine, including the emulator and Wattson
preserves the timing behavior of the emulated app execu- activities to be scaled down.
tion. We also need a power model to compute the energy Hence, we use an alternative approach where the cycles
consumption from the measured scaled resource use. allocated to the mobile device emulator running the test app
are limited. One way to do this would be to modify the mo-
3.5.1 Resource Scaling bile device emulator such as the Android Emulator or the
Windows Phone Emulator to run the app in a limited num-
One approach to resource scaling would be to use a cycle- ber of cycles and leave other cycles idle. This of course re-
accurate simulation of the mobile device processor on the quires separate porting to each mobile emulator and unlike
developer machine and then execute the mobile application the network scaling technique is not generically applicable
on the cycle accurate processor simulator. The cycle-accurate to all emulators. Instead we use an external technique where
simulators can reproduce the activities of the mobile proces- the emulator is not modified.
sor very accurately. However, the resource consumption of The approach is illustrated in Figure 10. In this approach,
cycle-accurate simulator is very high and it does not in fact the mobile device emulator, denoted E in the figure (in our
run in real time on a development machine. A unit time prototype, the Windows Phone Emulator, encapsulated in
worth of computation on the real phone processor may ac- process XDE.exe) is affinitized by Wattson to one core, shown
tually consume more than one time units on the simulator. as core 0 in the figure. The priority level of the emulator
Since the simulator tracks the time ticks, the trace produced process is set to one level lower than normal. Affinity and
is usable for simulating the CPU alone but when the timing priority modifications are performed using the relevant OS
affects the activities on other components such as the net- APIs. In addition, Wattson starts an additional thread, de-
work, the energy calculation will get skewed. noted by P in the figure, also affinitized to core 0. All other
Hence, we take a light-weight approach where we attempt active threads, including the threads running as part of Watt-
to scale down the performance of the emulated process run- son are affinitized to other processor cores 1 through n. The
ning on the development machine by allowing it access to end result is that P gets a priority to run and cycles left un-
fewer processor cycles. This is an approximation in that the used by P are available for E. This way, by controlling the
nature of computation can affect how many cycles of one number of cycles used up by P , we can control the resource
processor correspond to the other processor, given that the scaling for E. Other methods to control the resource scaling
processor architectures are vastly different and aside from for the processor are also possible, such as using OS sched-
the number of cycles, the size of processor caches, acceler- uler modifications or Virtual Machine containers, and may
ators and bus speeds will matter as well. We compare the be employed depending on developer platform constraints.
execution time on a mobile device processor (Samsung Fo-
cus with a 1GHz Scorpion CPU) and a development ma- Control Thread
chine using a 2.7GHz Intel Core-2 Quad-core processor for DEVELOPER
Wattson
a few simply computational tasks including floating point APPLICATION IN
EMULATOR
computations, fixed point computations, and memory inten-
sive compute tasks. The slow-down in execution time did
OS APIs
not vary greatly across these tasks and for this pair of pro- KERNEL E - lower P - higher
(Affinity, Priority)
priority priority
cessors, the slow down was a factor of 7.2, implying that
a 100% CPU utilization on the phone processor can be ap- CPU 0 Remaining
COMPUTER E and P threads
proximated using a 100/7.2 = 13.8% utilization of one core HARDWARE affinitized to … affinitized to
CPU 0 other cores
on the developer machine processor. CPU n

The scaling factor can be easily measured for different


developer machines as follows. Suppose the computational Figure 10: CPU resource scaling. E denotes the mo-
task used for measuring the above scaling factor consumed bile device emulator and P denotes the resource control
t0 seconds on the developer machine used above. This same thread started by Wattson.
computation can be run by Wattson on a new developer ma-
chine, and the execution time measured purely in software.
Suppose the time measured is t1 . The scaling factor can be 3.5.2 Power Modeling
modified as 13.8 ∗ t1 /t0 . Power models for the CPU are available in the literature [18]
One way to scale down the development machine CPU is and we used a simple utilization based power model where

8
the CPU power is expressed as a linear function of the phone’s way to detect if and when the app used the GPS from outside
CPU utilization: the existing emulators.
Pcpu = α ∗ ucpu
4. IMPLEMENTATION
where ucpu represents the phone CPU utilization and α is a We implemented Wattson for the Windows Phone Devel-
power model parameter. The CPU utilization measured by opment framework as an extension to Visual Studio. The
Wattson for the emulator process on the developer machine emulator process (XDE.exe) starts once an app developer
is scaled according to the scaling factor in Section 3.5.1 to chooses to debug his app on the emulator. During any run
obtain ucpu . of the app, the developer can choose to activate Wattson. It
We measured the value of α on the Samsung Focus device works alongside the app running on the emulator with dif-
for different computations (Table 5) and use an average value ferent threads for network resource scaling, packet capture
of 722.6mW for simplicity. and filtering, CPU resource scaling, CPU usage monitoring,
and display screen capture.
Computation Power (mW)
The developer can select different operating conditions for
Floating Point 665
the run, such as network conditions (good, medium, bad),
Fixed Point 722
display brightness (low, medium, high), phone brand and
Memory Intensive 781
model, network carrier (AT&T, Verizon, T-Mobile, or Sprint),
Table 5: CPU power consumption at 100% utilization, and received signal strength. Since display brightness and
excluding device idle power signal strength do not affect the timing of the app execution,
these parameters can even be changed after the test run and
A practical complication that arises in implementing the the energy estimates are updated on the fly using a previ-
CPU power model is that sometimes, depending on OS schedul- ously obtained resource consumption trace.
ing behavior, the cycles consumed by the controlled thread The output of Wattson includes: (i) a time series of power
P and the emulator E may not exactly follow the scaling fac- consumed for every component, and (ii) the total energy con-
tor, and the converted ucpu could be higher than 100%. In sumed. Using the battery capacity specification, we can also
such cases we stretch out the excess CPU utilization over the estimate how long the battery would last if a user continu-
subsequent time slot, iteratively to as many slots as needed, ously ran the app on her phone. A screenshot of Wattson
to keep the CPU utilization within any single time slot to be output is shown in Figure 11. The UI elements on the left al-
at most 100%. low the developer to change operating conditions while the 4
graphs show the energy used on the network, display, CPU,
3.6 Other Components and the overall device respectively.
Some of the other components are also significant from
an energy standpoint. The most notable one is the Graph-
ics Processor (GPU). The GPU is mostly hardware managed
and no software observable metrics regarding its utilization
level are easily available. Power models for the GPU are
thus not widely studied in the literature. Resource scaling
for the GPU will also be non-trivial.
We largely omit the GPU from our model. One approx-
imation that we do include is that the GPU is heavily used
during video playback. Thus, we measured the power con-
sumption on a mobile device for several video playback tests
and found that while some portion of the power measure- Figure 11: Wattson output showing energy data.
ment can be explained using the CPU and display, a signifi-
cant portion remains attributable to the GPU. On an average We capture the network packet trace from the developer
the GPU power was estimated to be 231mW across three machine’s network interface card using a Windows library
different videos. Thus, if the emulated app is detected to for network sniffing, available as part of Network Monitor
be playing video, we can add this power value for the dura- 3.4 [13]. The packets transmitted/received by the emulator
tion that the video is played. Other uses of the GPU such as process (XDE.exe) are filtered out based on the source and
graphics intensive games, are not covered by this approxi- destination IP addresses and ports obtained from IPHelper
mation. API (GetTCPTable and GETUDPTable) by matching the cor-
The GPS sensor used for location is another component responding process ID.
that consumes non-trivial energy. While the GPS does not For CPU loading and binding, WinAPI functions present
require any resource scaling and the power model is also not in kernel32.dll are used to set the affinities for the em-
too difficult, we exclude the GPS because there is no easy ulator and the controlled loading thread, P , to a single core

9
and all the other threads in Wattson to the remaining cores. domly selected pixels instead of considering all pixels is also
CPU usage is captured using the Performance Monitor API. shown. Again the model has very little error.
WinAPI user interface functions are used for capturing the
screen as required to obtain pixel information for the display 1500
power model. Measured
Estimated, All Pixels
5. PERFORMANCE EVALUATION Estimated, Subsampled 1%

The accuracy of the energy estimate produced by Watt- 1000

Power (mW)
son depends both on the correctness of resource scaling as
well as the accuracy of the power models used. To evalu-
ate the overall performance, we compare the estimated en-
500
ergy use as well as the measured energy use for multiple
tasks performed on the mobile device. Since apps cannot be
downloaded to the emulator from the app marketplace, we
developed our own apps to perform these tests. 0
Application 1: Display only. We begin our evaluations 5 10 15 20 25 30
Image Number
with the display power model. While the LCD and OLED
power models are available in prior work, the AMOLED
model and is new and we evaluate its accuracy using an Figure 13: Measured and emulated energy for Applica-
application that consumed energy only in the display. The tion 1, with 30 different images.
display is also the single most dominant energy consuming
Another parameter worth exploring is the loss in accuracy
component that must be used by any foreground application.
suffered by sub-sampling only a small fraction of the pixels
We first test the accuracy of our discretized lookup table
rather than using all pixels. Using fewer pixels can reduce
that only stored 4096 colors out of the possible 255 × 255 ×
the computational overhead as well as the data overhead of
255 = 16581375, which is approximately only 0.024% of
tracing app resource use, enabling higher frame rate tracing.
all possible color values. This test is performed with 100
We compare the accuracy achieved when all pixels are in-
random colors that are not in the lookup table, set to oc-
cluded and the incremental increase in error at sub-sampling
cupy 100% of the display area. This tests the accuracy of the
1% and 0.1% of the pixels. From the results shown in Fig-
modified AMOLED model for color dependent power scal-
ure 14, reducing to 1% from 100% does not change the accu-
ing. Figure 12 shows both the estimated an the measured
racy much (the gray bars indicating the loss in accuracy are
power and suffers from very little error.
very small) while reducing down to 0.1% does start intro-
ducing significant changes in accuracy. The implementation
1400
Measured
of Wattson may be tuned to different subsampling levels de-
1200
Modeled pending on accuracy and resource use trade-offs desired.
Errors

1000
25
All Pixels
Power (mW)

800

Subsampled 1%
600 20 Subsampled 0.1%
400

15
Error (%)

200

0
0 10 20 30 40 50 60 70 80 90 100
10
Image Number

5
Figure 12: Testing the AMOLED display power model
with 100 random colors.
0
0 5 10 15 20 25 30
For a more realistic test, we use an application that sim- Image Number
ply displays a static image and performs no CPU or network
activity. Thirty different images encompassing various typi- Figure 14: Display model error when all pixels are con-
cal app displays including simple GUIs to rich textures and sidered, or only 1% or 0.1% of the pixels are considered.
photographic imagery were included in this set. Figure 13
shows the measured and estimated energy (using equation Application 2: Local Computation. This test is designed
(1)) for all 30 images. The energy estimated using 1% ran- to model applications that include only local computation

10
without network use or heavy graphics. The mobile app has
a simple GUI display, largely black with some white buttons.
25 Measured
Clicking the buttons causes computations to take place for
Estimated
5s, 10s, or 20s. An example power trace captured using the 20

Energy (J)
power meter is showed in Figure 15(a). For the same run, the
measured power trace averaged over 1s intervals as well as 15
the emulated power from Wattson is shown in Figure 15(b).
Power was measured with the mobile device in the airplane 10
mode to avoid cellular network background activity. How- 5
ever, the device does have some background activity as seen
in the raw trace near time 12s, and such activity, being inde- 0
5s 10s 20s
pendent of the app, should be excluded from consideration
for the app developer. This is difficult in the measured power
but is easy when using Wattson. Figure 16: Experimental evaluation of emulation accu-
racy for Application 2.
2000
Power (mW)

ure 17. The power trace shows significant power spikes


1000 above the radio’s high power state due to the CPU activ-
ity corresponding to processing of packet arrivals during the
download.
0
0 5 10 15 20 25 30
Time 2000

(a) Raw Trace Power (mW)


1000
Power (mW)

1000 Measured
Emulated
0
500 0 5 10 15 20 25 30
Time

0
0 5 10 15 20 25 30 Figure 17: Example data capture for Application 3.
Time
(b) Averaged over 1s Performing the above test for different downloaded file
sizes ranging from small to large, and repeating each test 5
times, the measured and estimated energy use is shown in
Figure 15: Comparing measured and emulated energy Figure 18. The emulation energy is close enough for the de-
for Application 2. veloper to make the correct design choices based on the es-
timates provided by Wattson. Average error is 4.73% across
Performing such an evaluation for the three different com- all tests.
pute units, the total energy consumed over a 30s period, as Application 4: Internet Browsing. This application down-
measured and emulated is shown in Figure 16. Each mea- loads a webpage and renders it on the display. We test em-
surement is averaged over 5 random runs and the standard ulation accuracy over five different web pages differing in
deviations are shown as error bars. Since the resource scal- content size and complexity. The web pages are chosen to be
ing can behave differently from one run to another, the emu- static pages without variable advertisement content to make
lated energy can also vary slightly across runs. Overall, the the experiment repeatable across a real device and Wattson.
emulated energy is lower since certain background activities The webpages used are listed in Table 6.
are absent from the emulated trace. The mean error across all
these runs is 9.3%. The primary factors leading to the error Web page Size Images
include any errors in the power model, the fact that back- AMOLED Wiki Page 357kB 9
ground activities cause the measured energy to be artificially ACM 353kB 16
higher, and the error in resource scaling that may cause the MSDN Mobile Apps 828kB 9
emulated CPU usage to be different from measured. Google 117kB 4
Application 3: Networked Apps. Next we consider ap- NPS/Yose 532 14
plications that use the network in addition to the CPU and
display. A simple application is developed that can down- Table 6: Webpages used for testing Application 4.
load files of different sizes from a predetermined web server.
As before, a sample power measurement is shown in Fig- Energy is measured over a common session length of 50s

11
may keep a local cache of images used for different weather
conditions and only download succinct weather data from
Measured
25 its web server. Second, the app may use different images for
Estimated
depicting a weather condition such as a cloudy day: a sim-
20 ple cloud icon (such as Figure 20-(a)) that has a very small
Energy (J)

image size (18kB), a rich photographic cloud image which


15 has significant detail but requires a larger file size of 138kB
to be stored or downloaded (Figure 20-(b)) or even an ani-
10 mated image that shows a simple set of moving cloud icons
(such as two frames with varying cloud locations, with one
5 frame shown in Figure 20-(c)), with a file size of 90kB.
0
1kB 100kB 1MB
Download Size

Figure 18: Estimated and measured energy for Applica-


tion 3 with varying download sizes.

for each URL. A variable portion of the session is spent on (a) (b) (c)

fetching the webpage for each case. Nevertheless, there are


variations across multiple runs due to network variability
and web server variability. The measured and estimated en- Figure 20: Three sample images considered for a
ergy is shown in Figure 19. The average error over all these weather app design.
experiments is 4.64% which is very similar to the variabil-
The smallest image, Image 1, size is likely to save energy
ity in measurement one may observe even with real device
on the network. Image-2 appears to be the darkest and may
measurements due to changing network conditions and de-
save energy on the display. Image-3 seems attractive in that
vice background activity.
it shows animation but it is not clear what the overhead for
animation is in terms of energy. The decision depends on
100 understanding energy consumption in multiple dimensions.
Measured Estimated Simply optimizing the app for lower CPU utilization will not
80 necessarily reduce energy. Also, the display power model
depends on color implying that even two images that appear
Energy (J)

60 similarly bright may consume different energy. The decision


would be much easier if the energy data for all these options
40 was easy to obtain and that is exactly what Wattson enables.
Trying the three different images in the app and recording
20
the Wattson output, we obtain the data summarized in Fig-
ure 21.
0
Wiki ACM MSDN Goog NPS
80
Display CPU Network
Figure 19: Estimated and measured energy for Applica- 60
tion 4.
Energy (J)

40

5.1 Case Study: Weather Application Design


20
Let us consider a fairly common application that is in-
stalled on a large fraction of mobile devices: a weather appli- 0
cation. The developer has at least a couple of design choices Image 1 Image 2 Image 3
and we show how Wattson assists in making the correct de-
cisions. Figure 21: Energy estimate summary from Wattson for
First, the app may always download the content to be dis- weather app design choices.
played, such as weather icons or images, from the web1 , or it
1
such application designs are sometimes referred to as hybrid apps Several facts become obvious from this data. First, even
and using the HTML standard, such apps can operate seamlessly on multiple platforms.

12
though Image 1 is much simpler and has a smaller file size, the catalogue of models to include AMOLED.
it does not help save any energy on the network. This hap- Power models for the cellular data network have been de-
pens because for such small downloads the network energy veloped in [15, 16], where multiple power states of the net-
is dominated by the tail states of the radio. A related implica- work hardware were inferred using external measurement.
tion is that saving the images locally and only downloading The times spent in various states depend on the configuration
the text data related to weather will not help save much en- settings used by the specific mobile network. Prior work has
ergy. In fact, downloading content from the web may make already provided the models inferred for the AT&T network,
app design more portable across mobile platforms. and we expanded the measurements to develop similar mod-
Second, the display is consuming the largest fraction of els for three other mobile operators. Network energy mea-
the energy for this scenario. Clearly an image that saves surements for the cellular and WiFi networks were also pre-
energy on the display is likely to be beneficial, and other sented in [17], where the differences in energy and perfor-
factors are less important. mance were used to determine the best network for commu-
Third, looking in detail at the component breakdowns, one nicating large data segments. Another aspect of cellular data
also notices that the CPU power consumption of the third network energy is its variation with signal strength, which
image is the highest. Looking at the emulation output from was studied in [19]. Since testing applications in varying
Wattson (not shown for brevity) also shows that, while for channel conditions is difficult through actual measurements,
the first two images the CPU energy is nearly zero, after the using the modeling information from [19] is useful in en-
download completes, the CPU is consuming an average of abling emulation of the application energy behavior in mul-
150mW continually while Image 3 is displayed. This im- tiple channel conditions.
plies that while one could choose darker colors to reduce the Prior work has also looked at determining the energy con-
display portion of the energy, the CPU portion will not re- sumed by each app. [21] tracks the resource usage of each
duce if animation is used. Since Wattson shows the exact component, and applies power models from the data sheet
overhead of animation, the developer can determine if it is specs. PowerScope [6] tracks the application with the active
important for their app scenario or not. Armed with such context on the processor (a single core CPU without hyper-
data, the developer can also decide if the app should high- threading was used) and measures the power at fine time res-
light important information, such as a hazardous weather olution. The power consumed by the device during the time
alert, using brighter colors or animation. the application had active processor context is used as an
approximation of the application’s power consumption. A
6. RELATED WORK limitation of both these approaches is that asynchronous ac-
tivities performed when the application does not have active
Wattson builds upon a large body of work on modeling processor context, and tail-state energy use by certain com-
the energy consumption of phones [2,5,22]. The work in [2] ponents are not correctly attributed.
focused specifically on a Palm device and measured several Another powerful modeling approach, eProf [14], traces
components including the CPU, LCD, device buttons, touch system calls made by applications and uses power state mod-
pen, and the serial link which was the primary communica- els for various components to infer energy used. It can incor-
tion channel on that device. It also discussed methods for porate tail-energy use, such as when a component remains
synchronizing power and resource usage traces. On simi- in a higher energy state after the application is done using it.
lar lines [22] is a more recent work that presents tools for We incorporate such state based models for the cellular net-
automated execution of test benchmarks and measurement work. Detailed system call tracing also enables fine grained
of power, to enable generation of power models for vari- attribution of energy to specific OS activities performed by
ous components on the mobile device. The modeling ap- the application and the use of such techniques can help fur-
proach was refined further in [5] by providing a tool named ther refine the energy attribution view provided by Wattson.
Sesame, that makes the model generation process even eas- While the above systems are intended to track multiple ap-
ier by eliminating the need for external power measurement plications, the attribution problem is simplified in Wattson
equipment, by using the battery drain measurements avail- since a developer typically wishes to optimize the single ap-
able on the mobile device itself. Our work builds upon such plication that they are developing. In Wattson, we emulate a
prior modeling work by using the available power models as single application and hence avoid attribution complexity.
inputs for our techniques. We also expand the set of avail-
able models to cover additional technology variations.
Some of the most energy intensive components, includ- 7. CONCLUSIONS AND FUTURE WORK
ing the display and network have been modeled extensively. In this paper we presented Wattson, a system to estimate
OLED display power models [3] have been used for develop- the energy consumption of apps during the development and
ing innovative methods for display energy optimization [4]. emulation stage. The goal is to enable app developers to use
LCD based screens were modeled in [22]. Many newer de- this feedback to design more energy efficient code. Wattson
vices including the iPhone, use AMOLED based displays for works in two stages. First, it scales down the emulation en-
which power models were not available. We have expanded vironment on the developer’s machine (network, CPU, dis-

13
play) to mimic the phone. Second, it applies empirically- [10] J. Manweiler, S. Agarwal, M. Zhang, R. Roy Choudhury, and
derived models to estimate the energy consumed by the app. P. Bahl. Switchboard: a matchmaking system for multiplayer
This approach gives us the flexibility to test an app’s energy mobile games. In Proceedings of the 9th international
conference on Mobile systems, applications, and services,
consumption under various scenarios and operating condi- MobiSys ’11, pages 71–84, 2011.
tions. We have prototyped Wattson for the Windows Phone [11] J. Manweiler and R. Roy Choudhury. Avoiding the rush
platform and shown its effectiveness for a variety of apps. hours: Wifi energy management via traffic isolation. In
Moving forward, we realize that Wattson is just the first Proceedings of the 9th international conference on Mobile
step in improving the energy efficiency of apps. Other use- systems, applications, and services, MobiSys ’11, pages
253–266, 2011.
ful steps would be to obtain actual energy measurements [12] J. C. McCullough, Y. Agarwal, J. Chandrashekar,
from the wild, and provide users with real feedback about S. Kuppuswamy, A. C. Snoeren, and R. K. Gupta. Evaluating
the energy consumed by different apps on her phone. Al- the effectiveness of model-based power characterization. In
though Android phones have the “battery use” tool for the Proceedings of the 2011 USENIX annual technical
latter, it is not accurate because of lack of supporting hard- conference, USENIXATC’11, pages 12–12, 2011.
[13] Microsoft. Network monitor 3.4.
ware. We are actively working on ways to modify existing http://www.microsoft.com/download/en/
phone hardware to obtain detailed energy consumption num- details.aspx?displaylang=en&id=4865.
bers from the phone. Furthermore, we are also investigating [14] A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y.-M. Wang.
techniques to augment the models of Wattson with real mea- Fine-grained power modeling for smartphones using system
surement data. This will help reduce any inaccuracies of call tracing. In Proceedings of the sixth conference on
Computer systems, EuroSys ’11, pages 153–168, 2011.
the energy models shown in [12]. Together, we believe that [15] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, and
these efforts will help developers produce apps that will sig- O. Spatscheck. Profiling resource usage for mobile
nificantly increase the battery lifetime of mobile phones. applications: a cross-layer approach. In Proceedings of
International Conference on Mobile Systems, Applications,
and Services, MobiSys ’11, pages 321–334, 2011.
8. REFERENCES [16] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen, and
[1] A. Balasubramanian, R. Mahajan, and A. Venkataramani. O. Spatscheck. Characterizing radio resource allocation for
Augmenting mobile 3g using wifi. In Proceedings of the 8th 3g networks. In Proceedings of the 10th annual conference
international conference on Mobile systems, applications, on Internet measurement, IMC ’10, pages 137–150, 2010.
and services, MobiSys ’10, pages 209–222, 2010. [17] M.-R. Ra, J. Paek, A. B. Sharma, R. Govindan, M. H.
[2] T. L. Cignetti, K. Komarov, and C. S. Ellis. Energy Krieger, and M. J. Neely. Energy-delay tradeoffs in
estimation tools for the palm. In Proceedings of the 3rd ACM smartphone applications. In Proceedings of the 8th
international workshop on Modeling, analysis and international conference on Mobile systems, applications,
simulation of wireless and mobile systems, MSWIM ’00, and services, MobiSys ’10, pages 255–270, 2010.
pages 96–103, 2000. [18] S. Rivoire, P. Ranganathan, and C. Kozyrakis. A comparison
[3] M. Dong, Y.-S. K. Choi, and L. Zhong. Power modeling of of high-level full-system power models. In Proceedings of
graphical user interfaces on oled displays. In Proceedings of the 2008 conference on Power aware computing and
the 46th Annual Design Automation Conference, DAC ’09, systems, HotPower’08, pages 3–3, 2008.
pages 652–657, 2009. [19] A. Schulman, V. Navda, R. Ramjee, N. Spring, P. Deshpande,
[4] M. Dong and L. Zhong. Chameleon: a color-adaptive web C. Grunewald, K. Jain, and V. N. Padmanabhan. Bartendr: a
browser for mobile oled displays. In Proceedings of the 9th practical approach to energy-aware cellular data scheduling.
international conference on Mobile systems, applications, In Proceedings of the sixteenth annual international
and services, MobiSys ’11, pages 85–98, 2011. conference on Mobile computing and networking, MobiCom
[5] M. Dong and L. Zhong. Self-constructive high-rate system ’10, pages 85–96, 2010.
energy modeling for battery-powered mobile systems. In [20] W. L. Tan, F. Lam, and W. C. Lau. An empirical study on the
Proceedings of the 9th international conference on Mobile capacity and performance of 3g networks. IEEE
systems, applications, and services, MobiSys ’11, pages Transactions on Mobile Computing, 7:737–750, June 2008.
335–348, 2011. [21] H. Zeng, C. S. Ellis, A. R. Lebeck, and A. Vahdat.
[6] J. Flinn and M. Satyanarayanan. Powerscope: A tool for Ecosystem: managing energy as a first class operating system
profiling the energy usage of mobile applications. In resource. In Proceedings of the 10th international conference
Proceedings of the Second IEEE Workshop on Mobile on Architectural support for programming languages and
Computer Systems and Applications, WMCSA ’99, pages operating systems, ASPLOS-X, pages 123–132, 2002.
2–, 1999. [22] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M.
[7] J. Huang, Q. Xu, B. Tiwana, Z. M. Mao, M. Zhang, and Mao, and L. Yang. Accurate online power estimation and
P. Bahl. Anatomizing application performance differences on automatic battery behavior based power model generation
smartphones. In Proceedings of the 8th international for smartphones. In Proceedings of the eighth
conference on Mobile systems, applications, and services, IEEE/ACM/IFIP international conference on
MobiSys ’10, pages 165–178, 2010. Hardware/software codesign and system synthesis,
[8] S. Jha. Poorly written apps can sap 30 to 40% of a phone’s CODES/ISSS ’10, pages 105–114, 2010.
juice., June 2011. CEO, Motorola Mobility, Bank of America [23] X. Zhao, Y. Dong, H. tao Zhao, Z. Hui, J. Li, and C. Sheng.
Merrill Lynch 2011 Technology Conference. A real-time congestion control mechanism for multimedia
[9] H. V. Madhyastha, T. Anderson, A. Krishnamurthy, transmission over 3g wireless networks. In Communication
N. Spring, and A. Venkataramani. A structural approach to Technology (ICCT), 2010 12th IEEE International
latency prediction. In Proceedings of the 6th ACM Conference on, pages 1236 –1239, nov. 2010.
SIGCOMM conference on Internet measurement, IMC ’06.

14