From 8ca4e169221528ce22a3649643223b841677ba1d Mon Sep 17 00:00:00 2001 From: Geoffrey Challen Date: Wed, 24 Dec 2014 17:23:08 -0500 Subject: [PATCH] Done. --- .ispell_english | 32 ++++++++++++++++++++++++++++++++ old/utility.tex | 69 --------------------------------------------------------------------- related.tex | 21 --------------------- 3 files changed, 32 insertions(+), 90 deletions(-) create mode 100644 .ispell_english delete mode 100644 old/utility.tex delete mode 100644 related.tex diff --git a/.ispell_english b/.ispell_english new file mode 100644 index 0000000..3ee4c9b --- /dev/null +++ b/.ispell_english @@ -0,0 +1,32 @@ +Android +Android's +app +app's +apps +AudioFlinger +clickable +ESPN +Facebook +foregrounded +IRB +kbps +OTA +overvalue +overweighting +pedometer +pedometers +realtime +Skype +smartphone +smartphones +Snapchat +Sportscenter +SurfaceFlinger +testbed +touchscreen +UI +undervalue +uninstall +WhatsApp +Yahoo +YouTube diff --git a/old/utility.tex b/old/utility.tex deleted file mode 100644 index 26598b2..0000000 --- a/old/utility.tex +++ /dev/null @@ -1,69 +0,0 @@ -\section{Computing Energy Efficiency} -\label{sec-utility} - -Based on the results from the previous section, we can formulate design -requirements for an energy efficiency metric to apply to smartphone apps. -First, it must scale with usage, respecting the differences in baseline -consumption between users identified in Section~\ref{subsec-uservariation} -and the temporal variation of apps identified in -Section~\ref{subsec-timevariation}. Second, it must try to avoid targeting -top apps, even if they tend to consume a great deal of energy as described in -Section~\ref{subsec-consumption}, as these may not be apps that users are -willing to uninstall. Finally, we use the analysis of background energy -consumption in Section~\ref{subsec-background} as a hint about where to -start, given that background energy consumption should match foreground usage -in most cases. - -In the section we walk through several ways of characterizing app energy -consumption: via the total amount, by consumption rate, and scaled against -foreground energy consumption and a new content-delivery metric we design -that incorporates use of both the display and the audio device. In each case -we examine the app consumption data generated by our usage monitoring study -and use each metric to shed light on app energy consumption. - -\subsection{Total Consumption} - -\input{./figures/tables/tableTOTAL.tex} - -Clearly, ranking apps by total energy consumption over the entire study says -much more about app popularity than it does about anything else. -Table~\ref{table-total} shows the top and bottom energy-consuming apps over -the entire study. As expected, popular apps such as the Android Browser, -Facebook, and the Android Phone compunent consume the most energy, while the -list of low consumers is dominated by apps with few installs. This table does -serve, however, to identify the popular apps in use by \PhoneLab{} -participants. - -\subsection{Consumption Rate} - -\input{./figures/tables/tableRATE.tex} - -Computing the rate at which apps consume energy by scaling their total energy -usage against the total time they were running, either in the background or -foreground, reveals more information, as shown in Table~\ref{table-rate}, The -results identify Facebook Messenger, Google+, and the Super-Bright LED -Flashlight as apps that rapidly-consume energy, while the Bank of America and -Weather Channel apps consume energy slowly. Differences between apps in -similar categories may begin to identify apps with problematic energy -consumption, such as contrasting the high energy usage of Facebook Messenger -with the low usage of WhatsApp, Twitter, Android Messaging, and even Skype. - -\subsection{Foreground Energy Efficiency} - -\input{./figures/tables/tableFOREGROUND.tex} - -Consumption rate alone, however, is insufficient to answer important -questions about how efficient smartphone apps are. Pandora, for example, may -consume a great deal of energy either because it is poorly written, or -because it is delivering a great deal of content. Given the observations -about background usage presented earlier, we were interested in using an apps -foreground time as a utility metric to compute energy efficiency. In this -conceptual framework, smartphone apps deliver utility through screen time -with users, and should consume energy in proportion to the amount of time -users spend actively interacting with them. - -\subsection{Content Energy Efficiency} - -\input{./figures/tables/tableCONTENT.tex} - -\subsection{Discussion} diff --git a/related.tex b/related.tex deleted file mode 100644 index 8d5a9cf..0000000 --- a/related.tex +++ /dev/null @@ -1,21 +0,0 @@ -\section{Related Work} -\label{sec-related} -One of the main activities on these mobile devices is \textbf{content -consumption}. A large number of applications for mobile devices are -content-delivery applications such as browsers, e-book readers, video players, -audio players, and photo viewers. Surveys have shown that consuming mobile -content such as video, books, news, etc. is the most popular activity among -mobile device users~\cite{mobile-content1, mobile-content2}. - -But high app usage will often translate to high energy consumption and lack of longevity -in battery life is reported to be the least satisfying aspect of smartphone ~\cite{battery-complaint1}. -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. -There has also being an impressive body of work to provide accurate energy measurement techniques -like by using either external hardware~\cite{carroll, -cignetti} or device-provided, built-in mechanisms such as smart -battery interfaces and voltage information~\cite{mansdi, vedge-nsdi13}. -But there has been no work as per our knowledge about identifying how much energy is consumed in providing -utility to the user. There exists a gap in our understanding what part of energy consumption by an app is -necessary to provide useful content to the user and what part of it is lost in inefficiency. -- libgit2 0.22.2