Commit 7421f257e193d93f90199095381c4938f5c3b956

Authored by Geoffrey Challen
1 parent 8c858076

New.

Showing 1 changed file with 5 additions and 6 deletions
usage.tex
@@ -38,10 +38,9 @@ each user enjoys whichever approach is most effective for them. @@ -38,10 +38,9 @@ each user enjoys whichever approach is most effective for them.
38 \subsection{\texttt{\large PhoneLab} Conductor} 38 \subsection{\texttt{\large PhoneLab} Conductor}
39 39
40 \PhoneLab{} is a large scale smartphone platform testbed at the University at 40 \PhoneLab{} is a large scale smartphone platform testbed at the University at
41 -Buffalo~\cite{phonelab-sensemine13}. We leverage the Android  
42 -\texttt{logcat} subsystem as a data collection mechanism---experiment apps  
43 -write their data into a system-wide log buffer and we collect and upload this  
44 -data on their behalf. 41 +Buffalo~\cite{phonelab-sensemine13}. We leverage the Android \texttt{logcat}
  42 +subsystem as a data collection mechanism---experiments log their data into a
  43 +system-wide log buffer and we collect and upload this data on their behalf.
45 44
46 We developed an app called the \PhoneLab{} Conductor for this purpose which 45 We developed an app called the \PhoneLab{} Conductor for this purpose which
47 provides a good example of custom \texttt{maybe} evaluation logic. The goal 46 provides a good example of custom \texttt{maybe} evaluation logic. The goal
@@ -50,7 +49,7 @@ storage usage, and metered data usage. With the \texttt{maybe} statement @@ -50,7 +49,7 @@ storage usage, and metered data usage. With the \texttt{maybe} statement
50 branching between multiple policies for uploading data---such as always 49 branching between multiple policies for uploading data---such as always
51 waiting until the user reaches a plug, or always initiating an upload once 50 waiting until the user reaches a plug, or always initiating an upload once
52 the storage allocated is 50\% full---the evaluation logic would provide the 51 the storage allocated is 50\% full---the evaluation logic would provide the
53 -lowest possible score if data had been lost, or otherwise a score combining 52 +worst possible score if data had been lost, or otherwise a score combining
54 the multiple attributes the app is trying to minimize. 53 the multiple attributes the app is trying to minimize.
55 54
56 Due to the uncertainties we faced during development, we implemented a 55 Due to the uncertainties we faced during development, we implemented a
@@ -63,7 +62,7 @@ proven essential after deployment---for example, when an upload policy that @@ -63,7 +62,7 @@ proven essential after deployment---for example, when an upload policy that
63 worked previously abruptly stopped working on a newer Android version. 62 worked previously abruptly stopped working on a newer Android version.
64 Development of this app would have been considerably easier using 63 Development of this app would have been considerably easier using
65 \texttt{maybe}, which could automate the process of pushing policies to 64 \texttt{maybe}, which could automate the process of pushing policies to
66 -clients in an energy-efficient way, and enable per-user goal-driven 65 +clients in an energy-efficient way, and enabling per-user goal-driven
67 adaptation. 66 adaptation.
68 67
69 68