introduction.tex
4.87 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
\section{Introduction}
Measuring app energy consumption\footnote{To avoid confusion between device
usage and energy usage, we use \textit{consumption} exclusively when
referring to energy usage and \textit{usage} exclusively when referring to
user interaction with the device or apps.} on mobile devices is close to
being a solved problem, due to the great strides made in both generating and
validating energy models that can deliver accurate runtime energy consumption
estimates~\cite{mansdi, vedge-nsdi13} and in accurately attributing energy
consumption---even for asynchronous and shared
resources~\cite{cinder-eurosys11,osdi08-quanto}.
Previous work on component-based power modelling~\cite{dong2011, zhang2010,
jung2012} has mapped energy consumption to system-components like cpu, wifi chip, screen etc.
On the other hand, efforts like Eprof~\cite{pathak2011,pathak2012}, AppScope~\cite{yoon} traces system calls and monitors kernel activities to answer how much energy is consumed in an application level.
Accurate energy models bring
us one step close to the goal of effective energy management on smartphones
and other battery-constrained mobile devices, while also providing developers
with useful feedback as they build their mobile apps.
But accurate energy measurement alone is not enough to enable these goals.
Even perfectly-accurate measurements of energy consumption are insufficient
to answer critical questions about app energy consumption faced by users and
developers, including:
\begin{itemize}
\item Which of the following two apps is more energy efficient?
\item Will this change to an apps code make it more energy efficient or not?
\item Is a particular app an energy virus, and what does it even mean for an app
to be an energy virus?
\item How should the limited energy resources on a given app be prioritized?
\end{itemize}
What unifies all of these questions is one missing component: a measure of
the \textit{value} delivered by an app, which can be used alone combined with
energy consumption to compute energy \textit{efficiency} over any time
interval:
%
\[\frac{value}{energy} \]
%
Armed with a measure of value we can return to the difficult questions posed
above. By computing efficiency users can perform apples-to-apples comparisons
of apps in order to evaluate two video conferencing tools, web browsers, or
email clients. Developers can determine whether a new feature delivers value
more or less efficiently than the rest of their app and better understand
differences in energy consumption across different users. Measuring value
allows a rigorous definition of energy virus as an app that delivers little
or no value per joule, and for systems to reward efficient apps by
prioritizing limited resources based on app value or energy efficiency. After
all the progress we have made in computing the denominator---energy
consumption---we believe that the search for the missing numerator is the
most important open challenge in energy management.
Developing such a measure, however, is difficult. To be effective it must
work across almost the entire spectrum of smartphone apps, which represent an
incredible diversity of different goals, interfaces, and interaction
patterns. It must also work across a variety of different users with
different usage patterns. It must be efficient to compute, since it should
not compete for the same limited energy resources that it is intended to help
manage. Ideally it should require little to no user input, since this will
make it burdensome and error-prone. And to make matters worse, unlike
measuring energy consumption there is no easy way to measure ground truth to
compare against---even in the lab. Despite all these challenges, however,
even a semi-accurate value measure would greatly benefit energy management on
battery-constrained smartphones. Given that users have continued to report
battery lifetimes as their top concern with today's
models~\cite{jdpowerbatterylife-url}, we believe that this effort is
worthwhile.
In this paper we motivate the idea of a value measure and describe an early
failure at developing one based on measuring content delivery. We begin in
Section~\ref{sec-usage} by describing how useful such a measure would be and
the results of being able to answer questions like those posed above, as well
as formulating design requirements for the value measure itself.
Section~\ref{sec-measure} presents an overview of possible inputs into such a
measure and discussion of how each could be measured and how useful it might
be. In Section~\ref{sec-results} we present at formulating a value measure
based on content delivered through the video display and audio output---an
attempt that we consider a failure based on the result of a user survey, but
one that we hope sheds light on how difficult this challenge may be. After
discussing the implications of our results, in Section~\ref{sec-conclusion}
we briefly present our future work before concluding.