An APM system maps the computer system (OS and hardware) activity and the user activity into power management actions as shown in Figure 2. The goal of such a system is to maximize battery life while minimizing the impact on the user. In this section, we describe the state-of-the-art in APM solutions and our proposition for explicit consideration of the user's context and perception.

Past approaches

Currently used power management techniques are based on timeout policies. These policies shut down a component after it is not used for some predefined time. The aggressiveness of the scheme is reflected by the length of the timeout before a specific component is shut down. For example, Windows* OS has several built-in power management schemes that allow the user to choose between different levels of aggressiveness. The user is expected to switch manually between these schemes. Timeout policies are fairly simple and robust. They are, however, non-adaptive and may be too fast or too slow to react.

Applying machine-learning techniques to the APM problem is in its infancy. In [16] a simple predictive approach for deciding if to turn a component on or off was investigated. The authors attempt to predict the length of the idle period and claim that typically a short idle time is followed by a long active time and vice-versa (i.e., the prediction is based on the recent history). The decision rule eventually recommended that the component be shut down if it was used for less than some threshold value. They explored two approaches: a threshold value that is determined using regression and a threshold value that is manually obtained from data. In both approaches, the threshold parameters were obtained based on data in a non-adaptive manner. The approach of [7] is to predict the future delay as an exponentially weighted sum of recent delays. Our work uses learning techniques that focus more on the adaptive and dynamic aspects of power management.

Several papers considered policy optimization in the context of power management ([1], [14], [15]). According to this approach, a single Markov Decision Process (MDP) or a Semi-Markov Decision Process (SMDP) is constructed and solved using linear programming. An MDP is a stochastic process model of the state of the world and costs of actions (see Figure 6). An SMDP is an MDP where the next state does not only depend on the current state but also on how long the current state has been active. The Markov property, which states that the current state is sufficient for predicting the next state, is violated, hence the semi-Markov terminology. The Markov models used in these works are extremely simple and their state space is mostly an active/not active indication. State transitions are estimated from data and the optimization is done off-line. A somewhat more complex stochastic optimization model is presented in [12]. The model used in this work is a non-stationary process where there are several modes. For each mode, the process is a Markov decision process. In general, these models are not realistic because they assume that the state variables can be directly observed from sensors. Our work differs from this line of work in that we explicitly take into consideration the user activity (usually not directly observable) and also consider the perceived performance.

User-based APM

The papers mentioned above attempt to use dynamic models estimated from data. To the best of our knowledge, they are all based on relatively small and simulated amounts of data. Most importantly, these works do not model user state in their decision making, which we believe to be essential.

Monitoring user activity (i.e., context) from sensor observations is a well-studied problem, e.g., see [6]. However, there are relatively few instances where activity monitoring is linked to decision making, which is the goal of APM. In this paper, we focus on making the actual decision: which component to turn off and when. With this goal in mind, we introduce a novel representation of context, namely the idleness duration variable, to describe the state of the user. Though simple, this is an effective way to characterize context for this decision problem in the power management domain. We also address the issue of how the user perceives the performance degradation (a measure we call annoyance).

Reducing the power consumption to the bare minimum can be easily done by moving to standby mode on every occasion. This, however, is not very useful since a power management system applying such a policy will not be very usable. It is clear that a "good" policy should minimize power consumption. Therefore, one has to consider the tradeoff between the power savings and the perceived performance degradation, i.e., the annoyance. In order to examine this tradeoff, we look at tradeoff-type plots, where one axis shows the power saving and the other shows the level of annoyance. With no power savings, all the components are on all the time and the annoyance is assumed to equal zero. As the annoyance increases, the power savings may increase. Still, the power savings will never be more than the minimal power consumption level needed to perform the required operations. Figure 3 demonstrates a power-saving annoyance curve. Different users may choose different points on the power-saving annoyance curve according to their desired tradeoff.

Figure 3: A tradeoff curve for power savings versus annoyance. The power savings cannot pass a certain threshold as shown with the converging curve to be approximately 80%. This curve was produced from a real trace, where the points on the curve represent various timeout policies. The furthest top right point represents a timeout parameter of 1 second and the furthest lower left, a timeout parameter of 600 seconds.
 

Quantifying the power savings is straightforward and it can be done in Watts per second, or the proportion of time a component is off. In our experiments, we considered four components: turning off the LCD, turning off the WLAN, running the CPU in low frequency, and placing the laptop in standby mode. When the laptop is turned on or in standby mode, it consumes 18.5 and 0.7 Watts per second, respectively. Turning off the LCD, or the WLAN, or switching the CPU into its low-frequency mode, results in the consumption of 14, 17.5, and 15 Watts per second, respectively.

Quantifying the annoyance is trickier. Essentially, the problem is that annoyance is a subjective measure and different users may feel a different level of annoyance for the same sequence of actions. Based on interviews with users, we decided to measure the annoyance as follows. If the system decided by mistake to turn off the CPU, WLAN, and LCD, it leads to annoyance of 1, 3, and 7, respectively. Moving to a standby mode by mistake leads to annoyance of 10. We know if turning off a component was a mistake since we can detect if this component is needed or not after it was turned off. For example, if we turn the LCD off and after a few seconds the user opens a new application and clicks the mouse we can safely assume that turning the LCD off was a mistake. The different annoyance coefficients represent a collective and subjective estimate of how much more annoying is turning off one component compared to turning off another.