Commit 0b3876341e709b7e7304744d14905e5e6d1be8b8
1 parent
f092c4d9
New.
Showing
5 changed files
with
78 additions
and
62 deletions
abstract.tex
| 1 | \begin{abstract} | 1 | \begin{abstract} |
| 2 | 2 | ||
| 3 | -While great strides have been made in measuring energy consumption through | ||
| 4 | -accurate energy models, measures of energy consumption alone are not | ||
| 5 | -sufficient to enable effective energy management on battery-constrained | ||
| 6 | -mobile devices. What is urgently needed is a way to put energy consumption in | ||
| 7 | -context by measuring the value delivered by mobile apps. An accurate value | ||
| 8 | -measure would enable cross-app comparison, app improvement, energy virus | ||
| 9 | -detection, and effective runtime energy allocation and prioritization. Given | ||
| 10 | -that gains in modeling will be lost without a measure of value, we believe | ||
| 11 | -that this is the most important open problem in energy management. Our paper | ||
| 12 | -motivates the problem, describes requirements for a candidate value measure, | ||
| 13 | -discusses possible inputs to such a metric, and presents result from a | ||
| 14 | -preliminary (unsuccessful) attempt to formulate a value measure. | 3 | +While great strides have been made in measuring energy consumption, these |
| 4 | +measures alone are not sufficient to enable effective energy management on | ||
| 5 | +battery-constrained mobile devices. What is urgently needed is a way to put | ||
| 6 | +energy consumption into context by measuring the \textit{value} delivered by | ||
| 7 | +mobile apps. While difficult to compute, an accurate value measure would | ||
| 8 | +enable cross-app comparison, app improvement, energy virus detection, and | ||
| 9 | +effective runtime energy allocation and prioritization. Our paper motivates | ||
| 10 | +the problem, describes requirements for a value measure, discusses and | ||
| 11 | +evaluates several possible inputs to such a measure, and presents results | ||
| 12 | +from a preliminary (unsuccessful) attempt to formulate one. | ||
| 15 | 13 | ||
| 16 | \end{abstract} | 14 | \end{abstract} |
conclusion.tex
| 1 | \section{Conclusions} | 1 | \section{Conclusions} |
| 2 | \label{sec-conclusion} | 2 | \label{sec-conclusion} |
| 3 | 3 | ||
| 4 | -% \section*{Acknowledgments} | 4 | +To conclude, we have argued that our inability to estimate app value is a |
| 5 | +critical weakness that is threatening our successes at accurately estimating | ||
| 6 | +and attributing energy consumption. We have motivated the need for a value | ||
| 7 | +measure by describing the multiple ways in which it would aid in the | ||
| 8 | +management of energy and other resources on battery-powered smartphones. | ||
| 9 | +Using an energy consumption dataset collected on \PhoneLab{} we have explored | ||
| 10 | +separately several potential inputs to a value measure and determined how | ||
| 11 | +they weight energy consumption. And finally, we have presented results from a | ||
| 12 | +failed effort to formulate an effective value measure. While this first | ||
| 13 | +attempt was unsuccessful, we hope to engage the mobile systems community in | ||
| 14 | +this effort so that more sophisticated and successful value measures can be | ||
| 15 | +developed. |
include/start.tex
| @@ -26,8 +26,8 @@ | @@ -26,8 +26,8 @@ | ||
| 26 | 26 | ||
| 27 | \usepackage[all]{hypcap} | 27 | \usepackage[all]{hypcap} |
| 28 | 28 | ||
| 29 | -\setlist[itemize]{leftmargin=*,partopsep=5pt} | ||
| 30 | -\setlist[enumerate]{leftmargin=*,partopsep=5pt} | 29 | +\setlist[itemize]{leftmargin=*,partopsep=0pt,topsep=5pt,itemsep=1pt} |
| 30 | +\setlist[enumerate]{leftmargin=*,partopsep=0pt,topsep=5pt,itemsep=1pt} | ||
| 31 | 31 | ||
| 32 | \input{.xxxnote} | 32 | \input{.xxxnote} |
| 33 | \input{.draft} | 33 | \input{.draft} |
introduction.tex
| 1 | \section{Introduction} | 1 | \section{Introduction} |
| 2 | 2 | ||
| 3 | -Measuring app energy consumption\footnote{To avoid confusion between device | ||
| 4 | -usage and energy usage, we use \textit{consumption} exclusively when | ||
| 5 | -referring to energy usage and \textit{usage} exclusively when referring to | ||
| 6 | -user interaction with the device or apps.} on mobile devices is close to | ||
| 7 | -being a solved problem, due to the great strides made in both generating and | ||
| 8 | -validating energy models that can deliver accurate runtime energy consumption | ||
| 9 | -estimates~\cite{mansdi, vedge-nsdi13} and in accurately attributing energy | ||
| 10 | -consumption---even for asynchronous and shared | ||
| 11 | -resources~\cite{cinder-eurosys11,osdi08-quanto}. | ||
| 12 | -Previous work on component-based power modelling~\cite{dong2011, zhang2010, | ||
| 13 | -jung2012} has mapped energy consumption to system-components like cpu, wifi chip, screen etc. | ||
| 14 | -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. | ||
| 15 | -Accurate energy models bring | ||
| 16 | -us one step close to the goal of effective energy management on smartphones | ||
| 17 | -and other battery-constrained mobile devices, while also providing developers | ||
| 18 | -with useful feedback as they build their mobile apps. | ||
| 19 | - | ||
| 20 | -But accurate energy measurement alone is not enough to enable these goals. | ||
| 21 | -Even perfectly-accurate measurements of energy consumption are insufficient | ||
| 22 | -to answer critical questions about app energy consumption faced by users and | ||
| 23 | -developers, including: | 3 | +Measuring app energy consumption\footnote{\small To avoid confusion between |
| 4 | +app and energy usage, we use \textit{consumption} exclusively when referring | ||
| 5 | +to energy usage and \textit{usage} exclusively when referring to user | ||
| 6 | +interaction with apps.} on mobile devices is close to being a solved problem, | ||
| 7 | +due to the great strides made in both generating and validating energy models | ||
| 8 | +that can deliver accurate runtime energy consumption | ||
| 9 | +estimates~\cite{mansdi,vedge-nsdi13,pathak2011,pathak2012,yoon} and in | ||
| 10 | +accurately attributing energy consumption, even for asynchronous and shared | ||
| 11 | +resources~\cite{cinder-eurosys11,osdi08-quanto}. Accurate energy models bring | ||
| 12 | +us closer to the goal of effective energy management on battery-constrained | ||
| 13 | +devices. | ||
| 24 | 14 | ||
| 15 | +But accurate energy measurement alone is not enough, because even | ||
| 16 | +perfectly-accurate measurements of energy consumption are insufficient to | ||
| 17 | +answer critical energy-related questions faced by users and developers, | ||
| 18 | +including: | ||
| 19 | +% | ||
| 25 | \begin{itemize} | 20 | \begin{itemize} |
| 26 | 21 | ||
| 27 | \item Which of the following two apps is more energy efficient? | 22 | \item Which of the following two apps is more energy efficient? |
| 28 | 23 | ||
| 29 | -\item Will this change to an apps code make it more energy efficient or not? | 24 | +\item Will this change to an app make it more energy efficient? |
| 30 | 25 | ||
| 31 | -\item Is a particular app an energy virus, and what does it even mean for an app | ||
| 32 | -to be an energy virus? | 26 | +\item Is a particular app an energy virus? |
| 33 | 27 | ||
| 34 | \item How should the limited energy resources on a given app be prioritized? | 28 | \item How should the limited energy resources on a given app be prioritized? |
| 35 | 29 | ||
| 36 | \end{itemize} | 30 | \end{itemize} |
| 37 | 31 | ||
| 38 | -What unifies all of these questions is one missing component: a measure of | ||
| 39 | -the \textit{value} delivered by an app, which can be used alone combined with | ||
| 40 | -energy consumption to compute energy \textit{efficiency} over any time | ||
| 41 | -interval: | 32 | +Unifying all of these questions is one missing component: a measure of |
| 33 | +app \textit{value}, which can be used alone or combined with | ||
| 34 | +energy consumption to compute energy \textit{efficiency}: | ||
| 42 | % | 35 | % |
| 43 | \[\frac{value}{energy} \] | 36 | \[\frac{value}{energy} \] |
| 44 | % | 37 | % |
| @@ -62,13 +55,12 @@ patterns. It must also work across a variety of different users with | @@ -62,13 +55,12 @@ patterns. It must also work across a variety of different users with | ||
| 62 | different usage patterns. It must be efficient to compute, since it should | 55 | different usage patterns. It must be efficient to compute, since it should |
| 63 | not compete for the same limited energy resources that it is intended to help | 56 | not compete for the same limited energy resources that it is intended to help |
| 64 | manage. Ideally it should require little to no user input, since this will | 57 | manage. Ideally it should require little to no user input, since this will |
| 65 | -make it burdensome and error-prone. And to make matters worse, unlike | ||
| 66 | -measuring energy consumption there is no easy way to measure ground truth to | ||
| 67 | -compare against---even in the lab. Despite all these challenges, however, | ||
| 68 | -even a semi-accurate value measure would greatly benefit energy management on | ||
| 69 | -battery-constrained smartphones. Given that users have continued to report | ||
| 70 | -battery lifetimes as their top concern with today's | ||
| 71 | -models~\cite{jdpowerbatterylife-url}, we believe that this effort is | 58 | +make it burdensome and error-prone. And to make matters worse, there is no |
| 59 | +obvious way to measure ground truth to compare against---even in the lab. | ||
| 60 | +Despite all these challenges, however, even a semi-accurate value measure | ||
| 61 | +would greatly benefit energy management on battery-constrained smartphones. | ||
| 62 | +With users continuing to report battery lifetime as their top concern with | ||
| 63 | +smartphones~\cite{jdpowerbatterylife-url}, we believe this effort is | ||
| 72 | worthwhile. | 64 | worthwhile. |
| 73 | 65 | ||
| 74 | In this paper we motivate the idea of a value measure and describe an early | 66 | In this paper we motivate the idea of a value measure and describe an early |
results.tex
| @@ -119,15 +119,30 @@ redraws. | @@ -119,15 +119,30 @@ redraws. | ||
| 119 | 119 | ||
| 120 | \end{figure*} | 120 | \end{figure*} |
| 121 | 121 | ||
| 122 | -To evaluate our efficiency metric against usage based metric, we sent out a | ||
| 123 | -survey to our participants asking to answer if they would remove the 3 top | ||
| 124 | -energy inefficient apps suggested by both metrics to improve the battery-life | ||
| 125 | -of the smartphones by choosing one of the three options: yes, may be, no 47 | ||
| 126 | -participants responded to the survey. Figure~\ref{fig-survey} shows that our | ||
| 127 | -efficiency metric did not do a better job than the usage based metric. This | ||
| 128 | -negative result points out that our content metric design is too simplistic | ||
| 129 | -to be effective. Only screen time or audio time is not enough to evaluate the | ||
| 130 | -different types of rich content delivered by apps. For example, our metric | ||
| 131 | -cannot distinguish between video content and interactive content. We also | ||
| 132 | -need to be careful about how we assign weight to the multiple components that | ||
| 133 | -consume energy to deliver the content. | 122 | +To continue the evaluation of our simple content-based value measure, we |
| 123 | +prepared a survey for the 107~\PhoneLab{} participants who contributed data | ||
| 124 | +to our experiment. Our goal was to determine if users would be more willing | ||
| 125 | +to remove inefficienct apps, as defined using our content-based measure. As a | ||
| 126 | +baseline, we also asked users about the apps that consumed the most energy. | ||
| 127 | +We used each participants data to generate a custom survey containing | ||
| 128 | +questions about 9 apps: the 3 least efficient apps as computed by our | ||
| 129 | +content-based value measure, the 3 apps that used the most energy on their | ||
| 130 | +smartphone during the experiment, and 3 apps chosen at random. For each we | ||
| 131 | +asked them a simple question: ``If it would improve your battery life, would | ||
| 132 | +you uninstall or stop using this app?'' To compute an aggregate score for | ||
| 133 | +both the content-based and usage based measures, we give each measure 1~point | ||
| 134 | +for a ``Yes'', 0.5~points for a ``Maybe'' and 0~points for a ``No''. | ||
| 135 | +47~participants completed the survey, and the results are shown in | ||
| 136 | +Figure~\ref{fig-survey}. | ||
| 137 | + | ||
| 138 | +Overall the results are inconclusive, with the content-delivery measure not | ||
| 139 | +clearly outperforming the straw-man usage measure at predicting which apps | ||
| 140 | +each user would be willing to remove to save battery life. Given the crude | ||
| 141 | +nature of our metric, this is not particularly surprising, and can be | ||
| 142 | +interpreted as a clear sign that we need a more sophisticated value measure | ||
| 143 | +incorporating several of the potential inputs we have previously discussed. | ||
| 144 | +However, on one level the results are very encouraging: most users were | ||
| 145 | +willing to consider removing one or more apps if that app would improve their | ||
| 146 | +battery lifetime. Clearly users are making this decision based on some idea | ||
| 147 | +of each app's value---the challenge is to replicate their choices using the | ||
| 148 | +information we have available to us. |