clean up

Scott Haseley
1 parent 0fe5268b
Showing 4 changed files with 17 additions and 17 deletions
badwords
design.tex
introduction.tex
paper.tex
@@ -6,7 +6,7 @@ Challen
 challen
 edu
 Haseley
-HotMobile
+MobiSys
 ondemand
 pdfinfo
 prioritization
@@ -18,14 +18,14 @@ without developer participation.
  
 As principle, if a user is waiting for something, priority should be given to
 any task that contributes to that end. This priority must extend across
-multiple shared components, namely CPUs, disks, networks, batteries.
+multiple shared components, such as CPUs, disks, networks, and batteries.
 %
 To achieve this goal, the OS must be designed in such a way that gives it
-the visiblity it currently lacks into how its actions will affect QoE.
+the visibility it currently lacks into how its actions will affect QoE.
 %
 To further improve QoE for apps that use the network, this visibility should
-extend past the device and into the network so priority decisions can be made
-by the network to improve QoE.
+extend past the device and into the network so priority can be given to
+QoE-sensitive network traffic.
 %
 The design of QoE-centric operating systems may require deep and fundamental
 changes in order to measure QoE, understand its effect on various components,
@@ -6,7 +6,7 @@ users care more about resources such as time, battery life, and money, that are
 unmanaged or poorly managed by today's smartphone platforms.
 When apps slow down our typing, they waste our time. When apps download
 unnecessary resources, they waste battery life and potentially money, if using
-a metered data plan. It is the degree two which mobile devices effectively
+a metered data plan. It is the degree to which mobile devices effectively
 manage these human-facing resources that determines a user's
 \textit{quality of experience} (QoE), and it is QoE which should drive not just
 policy, but decisions on mobile devices.
@@ -16,12 +16,12 @@ While modern operating systems such as Android make decisions based on policies
 meant to improve QoE, it is unclear that these static policies always result
 in the right decisions. For example, Android uses two mechanisms to control the
 underlying task scheduling in Linux: thread priority and control groups (cgroup).
-Background threads -- any thread running in another app, or low priority threads
+Background threads -- threads running in another app, or low priority threads
 running in the foreground app -- are placed in a cgroup that receives a very
 limited share of the processor, \( \approx \) 5\% on Nexus 5 running stock
-Android 5.1.1. Furthermore, the scheduler considers priority for tasks withing
+Android 5.1.1. Furthermore, the scheduler considers thread priority for tasks within
 the same cgroup. However, thread priorities can be set by app developers both 
-directly through the API, and indirectly by creating an \texttt{AsyncTask}.
+directly through the API, and indirectly by using an \texttt{AsyncTask}.
 While this policy was created based on the assumed effect on QoE, it is still
 possible to negatively affect QoE by assigning the wrong priority to a thread
 or by inappropriately using \texttt{AsyncTasks}.
@@ -29,15 +29,15 @@ or by inappropriately using \texttt{AsyncTasks}.
  
 The \texttt{ondemand} CPU frequency governor that is enabled in Android
 Linux is another example of where static policy meant to improve QoE may not
-result in correct decisions being made. This governor changes the CPU frequency
+result in correct decisions. This governor changes the CPU frequency
 depending on the current CPU load with the goal of improving performance.
 However since running at higher frequencies is less efficient, this increased
 performance comes at the cost. If QoE would not be improved by increasing the
 frequency, such as for time-insensitive background tasks or when the performance
-increase would not be perceivable, negative QoE may manifest itself through a
-quicker draining battery.
+increase would not be perceivable, negative QoE may manifest itself through
+poor battery life.
  
-Static policies can lead to resource allocation decisions that are less than
-optimal in terms of QoE. To remedy this, we propose designing QoE-centric
-mobile operating systems that can accurately quantify QoE and use it as feedback
-to drive resource allocation decisions.
+In terms of QoE, static policies can lead to resource allocation decisions that
+are less than optimal. To remedy this, we propose designing QoE-centric
+mobile operating systems that use QoE as input to drive resource allocation
+decisions.
 \input{./include/start.tex}
  
-\def\theconference{HotMobile'16}
+\def\theconference{MobiSys'16}
 \def\thetitle{Poster: QoE-centric Mobile Operating System Design}
 \def\theauthors{Scott Haseley, Geoffrey Challen}
 \def\theemails{\{shaseley,challen\}@buffalo.edu}