An Energy-aware Framework for Coordinated Dynamic Software Management in Mobile Computers
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
An Energy-aware Framework for Coordinated Dynamic Software Management
in Mobile Computers
Yunsi Fei, Lin Zhong, and Niraj K. Jha
Dept. of Electrical Engineering, Princeton University, NJ 08544
Email: yfei,lzhong,jha @princeton.edu
Abstract work that the system can accomplish given a battery capac-
ity constraint.
Energy efficiency is a very important and challenging Mobile computing systems provide services to their
issue for resource-constrained mobile computers. In this users through software programs, which demand different
paper, we propose a dynamic software management (DSM) hardware resources. Therefore, software and hardware form
framework to improve battery utilization, and avoid com- a pair of consumer and supplier of resources. Existing
petition for limited energy resources from multiple applica- energy efficiency research can be categorized as follows.
tions. We have designed and implemented a DSM module in Energy-efficient hardware design techniques optimize the
user space, independent of the operating system (OS), which supplier so that less energy is consumed for the same sup-
explores quality-of-service (QoS) adaptation to reduce sys- ply of resources. Most processor and circuit power opti-
tem energy and employs a priority-based preemption policy mization techniques [25, 7] fall into this category. Soft-
for multiple applications. It also employs energy macro- ware optimization techniques optimize the consumer so that
models for mobile applications to aid in this endeavor. By less energy is consumed for the same software service.
monitoring the energy supply and predicting energy de- Most compilation [14] and software transformation tech-
mand at each QoS level, the DSM module is able to select niques [22, 27, 10] fit into this category. Another cate-
the best possible trade-off between energy conservation and gory of techniques scales the supply according to demand.
application QoS. To the best of our knowledge, this is the All dynamic power management (DPM) and dynamic volt-
first energy-aware coordinated framework utilizing adapta- age/frequency scaling (DVFS) techniques [13, 21, 12, 24]
tion of mobile applications. It honors the priority desired belong to this category. It also includes OS-directed power
by the user and is portable to POSIX-compliant OSs. Our management and optimization [4]. The techniques pre-
experimental results for some mobile applications (video sented in [16, 18] use QoS-based resource reservation, in
player, speech recognizer, voice-over-IP) show that this ap- which applications pass specific resource demands to the
proach can meet user-specified task-oriented goals and im- OS, and the OS reserves the minimum required resources
prove battery utilization significantly. They also show that (fraction of CPU cycles, network bandwidth, etc.) for them
prediction of application energy demand based on energy and prevents other applications from competing.
macro-models is a key component of this framework. DPM and DVFS techniques have been shown to be quite
effective in systems where the available hardware resource
is more than adequate for the tasks being run. However, in
resource-constrained mobile computing systems, the slow
1 Introduction processors, small memory, and limited battery capacity may
not always be able to cope with the increasing demands
Mobile computing systems are constrained by scarce re- of software. In such cases, there may not be much room
sources, such as small memory, slow CPU, etc. They are for DPM and DVFS techniques to save energy. Therefore,
specially constrained by limited battery capacity owing to a number of recent works have tried a different approach:
the weight/size limits for the battery. On the other hand, scaling the demand according to supply. Our work belongs
as we enter the era of pervasive computing, users are ex- to this category.
pecting more flexible and ubiquitous services and higher
productivity from mobile computing systems. In view of 1.1 Related work
the slow battery capacity growth, it is increasingly impor-
tant to develop techniques to achieve high energy efficiency Scaling the demand usually means reducing the service
for such systems. Energy efficiency refers to the amount of the application provides to the user. For data-intensive ap-
plications, the demand can be reduced by scaling data fi-
Acknowledgments: This work was supported by DARPA under con- delity, i.e., the input to the application. The Odyssey sys-
tract no. DAAB07-02-C-P302. tem [20] adopts this approach and provides for a collabo-ration between the OS and applications to improve perfor- or number of tasks, and different applications that need
mance. Similarly, the Puppeteer system [8] filters the input to be simultaneously run. The framework automati-
content through component-based adaptation. The Odyssey cally finds the best QoS trade-off for the goal, in view
system was also extended to enable data fidelity adaptation of the available energy resource.
for energy reduction [11]. The same philosophy is used
in [26] to transform the requested network data stream to Unlike most previous work, the framework exploits
reduce receiving and decoding energy. All these approaches multiple QoS knobs that can be tuned for embedded
are OS-based and input data-centric. applications to meet the desired goals.
Another way to scale the demand is to change the QoS,
which may or may not depend on altering data fidelity. An
application adaptation framework is discussed in [5], but it To summarize, our proposed framework is energy-aware,
does not target realistic applications. A recent work [19] general, portable and user-friendly. Our experiments es-
provides examples of how the computation fidelity of mo- tablish its effectiveness for real applications, such as video
bile applications can be altered. However, it does not player, speech recognizer and voice-over-IP.
present a methodology or framework for accomplishing this The paper is organized as follows. In Section 2, we pro-
task automatically, and it targets system delay reduction in- vide background information for this work along with moti-
stead of energy saving. vational examples. We present the overall DSM framework
Another issue related to scaling the demand is how to in Section 3 and detail the design and implementation of the
coordinate multiple scalable applications. The competition coordinator and dynamic software manager in Section 4.
among multiple applications for the constrained resources We present results of experiments conducted on a Linux-
needs to be addressed. A platform is proposed in [9] to based iPAQ with our prototype implementation on several
enable coordination among applications to avoid conflict. applications in Section 5. Finally, we discuss future work
It is a general platform without specific objectives such as and conclude in Section 6.
improving performance or conserving energy. It is only tar-
geted at Windows NT-based systems.
Except for the work in [11, 26], all the above works tar- 2 Motivation and preliminaries
get non-energy related resources. Most investigate soft-
ware adaptation for communication (network bandwidth)
and computation resources (CPU cycles). The work in [11] In this section, we first motivate through an example the
actually demonstrates the difficulty of energy-aware appli- necessity and efficacy of application adaptation and coordi-
cation adaptation, since it requires extra equipment for real- nation for battery-constrained systems, and then provide the
time energy measurements and a data processing computer, rationale for an energy-aware framework for DSM.
which is impractical for mobile systems. Its predecessor
work on application adaptation to reduce network band-
width [20] was quite successful since network bandwidth 2.1 Dynamic software management for low en-
is relatively easy to estimate. Moreover, most of these ap- ergy
proaches need OS support, which is difficult to implement
for systems that use a closed-source OS. Therefore, there is Traditional DPM techniques for computers have mainly
a strong need for a practical and general DSM framework exploited various low power modes of hardware compo-
for run-time energy optimization. nents, such as active, idle, sleep, and off states for the
hard disk, display, and network card. Analogous to hard-
1.2 Paper contributions ware power modes, many software applications also have
multiple working states, which correspond to multiple en-
In this work, we propose an application adaptation ergy/power modes. Therefore, we envision automatic ad-
framework based on software energy macro-modeling tech- justment of adaptable applications to lower energy modes
niques [28], DSM, and multiple-application coordination. when the battery level is low.
The framework makes the following contributions: The multiple software working states can be exploited by
setting certain run-time parameters, or knobs. These tun-
It utilizes software energy macro-modeling and obvi- able knobs represent alternative algorithm or implementa-
ates the need for extra equipment for real-time energy tion paths during application execution. The knobs may be
measurement [11], which is impractical for handheld local to some blocks, or global throughout the whole pro-
computers. gram. The net effect perceived by the user is different out-
It is implemented as portable middleware using only put QoS for the same input. Each working state may use
POSIX compliant system application-programming a different amount of hardware resources, including CPU
interfaces (APIs). Thus, it requires no changes to the cycles, memory, bandwidth, network interface card activa-
OS. tion, etc., which leads to different energy/power consump-
tion. The DSM module determines on the fly when to scale
It is task-oriented and goal-directed. The user can the application and to what working state. Thus, energy
specify his/her goal in terms of expected task duration saving is achieved at minimal cost in quality.2.2 Motivational example Energy consumption of various video clips under different
dithering modes
1400
Color
Gray
We first need to characterize the resource usage (energy) 1200
Mono
Threshold
for each working state of the application. Adaptation of ap- 1000
plications will be futile if the energy saving is meager. We
Energy (J)
800
use a software video player application - mpeg play [1] as 600
our motivational example. It is known that changing the 400
data fidelity of an input video clip (by using different lossy 200
compression methods when encoding video clips or using 0
1 2 3 4
different display window size) will induce different energy Video clips
consumption [11]. However, changing the computation fi-
delity of applications for energy saving has not been ade-
quately explored before. We define a QoS space for the Figure 2. Energy impact of the dithering
video player application as shown in Figure 1. It has multi- method
ple parameters (dithering method, frame rate, frame display
size), where each parameter represents a QoS dimension,
which contains a finite set of discrete quality values. The
combination of quality values in each dimension is referred
to as a QoS point, which is associated with an energy cost.
2.3 Coordination among multiple applications
All possible QoS points together form the QoS space of the
application. The QoS point in Figure 1 corresponds to the In mobile computers, it is common to have several appli-
cations running concurrently (e.g., a user may enjoy music
running state consisting of a 20 fps frame speed,
pixels display size, and dithering method. using the software MP3 player, while downloading another
MP3 file and playing Solitaire at the same time). They com-
pete for the constrained resources of CPU cycles, memory,
etc., and ultimately battery. It is the responsibility of the
dithering method
threshold OS to assign and manage the resources among multiple ap-
mono plications in a fair way. However, since an OS is unaware
gray QoS point of user intention (urgency level of each application), it may
(20 fps, 100*100, monochrome)
treat concurrently-running applications equally, and cause
color
l)
10 20 30 all of them to simultaneously abort in the middle of execu-
ixe
i xe
l* p
50*50
frame rate (fps) tion when the battery goes down. To avoid this scenario, a
(p
ize 100*100 user-defined application priority should be considered when
y s 150*150
pla
dis 200*200
a new application joins the system. We propose a coordina-
e
fra
m tor as middleware, which can control the admission of a new
application according to its priority and those of currently-
Figure 1. QoS space for a video player running ones. The coordinator also decides on new adapta-
tions for the newly admitted and other applications.
2.4 Policy for dynamic software management
The video player application consists of three steps for
each frame: decode, dither, and display. Most time and For the concept of DSM to be useful, a policy is needed
energy are consumed in the first two steps. It is shown to determine what and when to adapt. A naive way to
in [6] that display size has little effect on energy consump- manage software adaptation is analogous to the time-out
tion. Also, a user may prefer to watch the video clip at a DPM technique frequently employed for hardware, where
particular frame rate. Dithering modes tune the color expo- several time thresholds are used for transitioning hardware
sition of the frame and present us with one way to adapt to lower power modes. One could similarly set a number
the application. We analyzed various dithering methods, of energy thresholds for DSM. The battery energy status
and found four modes with human-perceptible difference: could be checked periodically and the appropriate execution
color, gray, monochrome, and threshold, out of a total of mode for running applications selected accordingly. How-
19 modes. Figure 2 shows the energy consumption of four ever, this policy is ad-hoc and aggressive, and may have
video clips under different dithering methods on a Linux- the unfortunate side-effect of frequently annoying the user.
based iPAQ 3870 (this is based on current measurements on Hence, we propose an application adaptation policy which
the iPAQ). We observed that the average energy saving for is directed by certain user-defined goals and is oriented for
the lowest power mode (threshold) is 25.3% compared to each task, as discussed in Section 3.
the original full-color mode (color). This is a simple illus- In mobile systems, a user may be able to estimate the
tration of the impact of changing the computation fidelity needed duration for a task, e.g., the length of a movie, the
on system energy consumption. length of a conversation with peer mobile users, etc. Insuch cases, we set the expected duration for the task as the
Application priority User
goal. Only when the residual battery energy cannot sus-
tain the goal, application adaptation is triggered. Consider
the following scenario: the user wants to watch a 30-minute
long video clip with the energy consumption estimate of the Application Applications
video clip for the highest quality mode being 3600 Joules,
Application Description of application
whereas the residual battery energy is only 3200 Joules. meta-data modes + power model
Suppose the energy consumption under the four dithering
modes are 3600, 3400, 3150, 3000 Joules for color, gray, Registry Run-time library Middleware
monochrome and threshold, respectively. The application Demand predictor
will adapt to the monochrome mode automatically to meet Meta-data
the goal of displaying the whole video clip, thus providing Resource Coordinator Adaptation
monitor manager
the highest possible QoS. In the absence of user input on
expected application duration, the system will provide best- Residual supply
Process space
info
effort QoS.
Resource Process
manager manager OS layer
3 Framework Design
… Hardware
Battery Processor platform
To manage adaptable applications according to the bat-
tery status in order to meet the task-oriented goal, we need
an application-coordinating software manager in middle- Figure 3. A coordination framework for appli-
ware, which fuses information from the application level
cation adaptation
above and the OS and platform below, and delivers adap-
tation and coordination commands to either the application
or the underlying OS modules. In this section, we explain
the design of a user-level DSM framework geared toward
energy savings.
the same registered application, the user can specify a dif-
ferent priority level.
3.1 Overview of the framework The resource monitor module in our framework polls the
OS resource manager, acquires the battery status informa-
Figure 3 shows the overall framework for mobile sys- tion, and calculates the residual battery energy value. Based
tems. We envision the whole system to consist of several on the application meta-data, application-specific configu-
vertically communicating layers, which are categorized into rations and priority, residual battery energy value, and in-
user space and system space. The hardware platform con- formation on running processes obtained from the process
tains a set of resources, such as a processor, memory, dis- manager, the coordinator performs admission control and
play, wireless card, battery, etc. The resource manager in adaptation arbitration, and sends process operation com-
the OS layer monitors the status of each resource and man- mands to the OS process manager and adaptation decisions
ages their usage. The process manager controls the creation, to the adaptation manager. Thus, an appropriate application
execution and termination of processes, and provides infor- configuration is selected for the newly joining application,
mation on running processes to the upper modules as well. and coordination is carried out among the other running ap-
The OS also provides a set of APIs to interact with the user- plications. We describe the coordinator in detail in Sec-
space modules. Above the OS layer sits the middleware that tion 3.3.
we have developed, which consists of several modules that
can interact either with the upper application layer, or the
OS layer below.
3.2 Task-oriented goal-directed software manage-
ment
On top of the middleware lie the application and user
layers. When multiple applications are running concur-
rently and competing for resources, the user can specify We consider three different cases for task-oriented soft-
the priority level for each application if he/she so chooses. ware management, and set up corresponding goals and poli-
In our framework, on joining the system, the application cies to perform DSM, as discussed next.
first registers with an application registry and provides some In the first case, altering application modes only changes
meta-data, e.g., the name of the service, the number of low average system power while the execution time remains the
power modes, etc. Meanwhile, the description of adaptation same. This case applies to a synchronized video player. The
modes for each application is stored into a run-time library, frame rate determines the sum of processing time (includ-
along with some application-specific information, such as ing decoding, dithering and displaying) and synchroniza-
the power macro-model to estimate the average power con- tion time for each frame. The length of a video clip can
sumption for each low power mode, the inputs, etc., in order be calculated by the number of frames and frame rate be-
to aid application adaptation. For different instantiations of forehand. The task-oriented goal is set to duration of task(e.g., length of a movie). At the configuration and adapta- Coordinator
tion point, we detect the initial battery energy and calculate Process space info
Admission Reject app
the expected average system power (supply). We also eval- Application meta-data control
Accept?
uate the power consumption for each mode (demand) by the Yes Operations on
demand predictor. Then we select the adaptation level with other apps
Run-time library
average system power just under what is sustainable by the (app modes description) Task-oriented software Application
battery energy level. In this way, the goal is met with the management module configuration
least QoS degradation. Resource supply
In the second case, the execution time is variable while
the average system power is constant for different applica-
tion modes. Our goal is now set as maximizing the number Figure 4. The design and flow of the coordi-
of tasks executed. The more tasks that complete execution nator
with the same energy constraint, the higher the battery uti-
lization. A speech recognizer falls into this category. When
we make a slight sacrifice in speech recognition QoS, we
gain in terms of execution speedup (thus also reducing sys-
tem energy). brary, which contains the description of various application
In the third case, both the power and execution time vary modes, and energy macro-models for both the demanded
for different application modes. The goal now targets both QoS and other QoS levels. By default, the demanded QoS
task duration and number of tasks. The system should fin- of an application is assumed to be the highest quality level.
ish the execution of all the tasks before their deadlines, and If the demanded QoS energy is larger than the residual bat-
also before the available energy drops to zero. If the sys- tery energy, the DSM module triggers an adaptation for the
tem runs out of battery before the application finishes ex- application. If even at the lowest power mode, the residual
ecution, or if the application execution does not complete battery energy is not sufficient, the application is forced to
before its deadline, the goal is not met, and the system pro- launch at the lowest power mode. The application’s con-
vides a “best-effort” service. figuration is delivered to the adaptation manager, which in-
Each registered application can be put into the above vokes the application with an appropriate mode from the
three categories, with its corresponding software manage- run-time library.
ment policy and goal specified in the run-time library. The
coordinator prompts the user for this information to make
an adaptation and coordination decision. 3.4 Scalable adaptation block
The demand predictor is also implemented in the run-
time library and estimates the energy demand of each In our framework, the QoS level is negotiated between
software mode at the adaptation point. This module is the application and coordinator before the application is
application-specific and is described in detail in Section 4.2. launched. Adaptation is invoked at the beginning of the ap-
plication. We define an adaptation block to be the block
3.3 Coordinator design of application code that consists of a set of alternative se-
quences of execution, each associated with a different QoS
Figure 4 depicts the design and flow of the coordinator. level. The adaptation block can be the whole application
First, the meta-data of the newly registered application and when all the software knobs are global for the whole pro-
the process space information are given as input to the ad- gram. In other cases, sequential application execution can
mission control unit. The application meta-data at least con- be divided into more than one adaptation block, each with
tain the priority level and number of power modes. The pro- its local software knobs. When the application has to yield
cess space information obtained from the process manager to others, it may take one of three fallback actions. It may
covers the running processes, and their association with ap- be suspended, aborted, or rolled back. A suspended ap-
plications. We employ a preemption and reservation pol- plication resumes at the original QoS level at the suspen-
icy for coordination. When there is any application running sion point. An aborted application is dropped from the sys-
with a higher priority than the new application, the battery tem. Under rollback, an application detects which adap-
energy is reserved for the higher-priority applications, and tation block it is in, and when it resumes, it rolls back to
the remaining energy is assigned to the new application for the beginning of the adaptation block, renegotiates with the
appropriate adaptation. Otherwise, it is admitted and other coordinator, determines the new quality level for the adap-
applications with lower priority yield the resources. Sev- tation block, and executes at the new QoS level. Such scal-
eral fallback actions can be invoked for these yielding ap- ability in adaptation block size is a characteristic of adapt-
plications: suspend, abort, or rollback, which is explained able applications, which is not the focus of our paper. Our
in Section 3.4. main contribution is building a general energy-aware DSM
If the new application is admitted, it is evaluated un- framework. Therefore, we currently assume the whole pro-
der the constraint of current residual battery capacity and gram to be an adaptation block and tune the global soft-
an appropriate configuration mode is obtained. Each ad- ware knobs, although we recognize that this approach can
mitted adaptable application has a supporting run-time li- be scaled down to finer-grained adaptation blocks.4 Framework implementation it is passed on to the wrapper through the adaptation man-
ager, and the application executed at the negotiated QoS
We have built a prototype user space DSM framework level.
in middleware. The key components are the run-time li- An important module in the run-time library is the en-
brary, which provides the adaptation configuration calls ergy estimator for an application at different QoS levels.
to the applications, and the coordinator, which negoti- The Odyssey system [11] takes an on-line power/energy
ates/renegotiates with applications and assigns configura- profiling approach, which requires extra measurement hard-
tion modes or fallback operations to each application. The ware and a computer. This is not appropriate for portable
framework is implemented as a daemon server in user systems. Instead, we use software energy macro-modeling
space, the communication between the applications and the to predict required system energy. Previous work [15] has
coordinator is implemented in a client-server fashion [23], tried to predict program power using some application-level
and the communication between the coordinator and pro- software tools. Currently, we embed an application-specific
cesses is implemented with signals. We illustrate next each energy estimation module in the run-time library. Based
salient feature of the framework. on the pre-built energy macro-model for each low power
mode, the application inputs, and other specific information,
energy prediction is performed for all the QoS levels, and
4.1 Registry used by the coordinator to make a decision. We briefly de-
scribe the energy macro-model for each application - video
Each adaptable application needs to register its meta- player mpeg player, voice-over-IP RAT, and speech recog-
data in a registry, and is allocated a data structure called nizer DNN.
component. The name for the service provided by the ap-
plication is assigned to the servicename entry of compo-
nent. For example, we give the service name “video” to the 4.2.1 Energy macro-model for the video player
MPEG-1 video player, mpeg play [1], “voip” to a voice- An MPEG-1 video stream consists of three frame types:
over-IP application, RAT [2], and “speech” to a dynamic I-frame (intra-coded), P-frame (predictive-coded) and B-
neuron-network based speech recognizer, DNN [29]. The frame (bidirectional-coded). The video stream is played
application also specifies the number of low-power modes at a fixed frame rate. In each frame period (inverse of the
that it can support to the levels entry of component. frame rate), a frame is decoded and a frame is displayed on
For each service instantiation, we allocate a data struc- the screen (note that the decoded frame and the displayed
ture called service with the specified name. It inherits all one may not be the same). It takes several steps to decode
the meta-data from the registered component with the same each frame: parsing, inverse discrete cosine transformation
service name, and appends some more parameters. For ex- (IDCT), reconstruction, and dithering [17]. Among these
ample, when the user launches a service and the associated steps, the first three are CPU-intensive and frame-type-
application programs, he/she can specify the urgency level dependent (each frame type requires a different type of pro-
by filling the priority entry in the service object. Also, an cessing), while the dithering step is memory-intensive (re-
entry called goal is reserved for the user to specify either quires data movement between the processed video stream
the expected task duration or the workload expectation. and the display frame-buffer) and frame-independent (i.e.,
it is independent of the frame type). Thus, we can divide
4.2 Run-time library the frame period into several processes: decode, dither, dis-
play and idle. Hence, the energy consumption of the video
"! #$% &"! #'
The run-time library provides the functionalities required player can be obtained from Equation (1).
)(*%+,%- . )(*%+,%- / + 0% + 21 (1)
by the application to interact with the coordinator. Interac-
tion between the application and the coordinator is struc-
tured as follows. The coordinator (on the server side) lis-
"! # , number
4(*%+,- ,ofandthe frames
+ repre-in
tens to the requests from clients at a default port. Upon
startup (a client issuing commands), the server receives the where 3' the
denotes total
5 6 average
"! #3 'power
6 4(*%+,consumption
- , and + for
represent
request, parses it, and executes corresponding commands. the stream, ,
When the user launches an application, he/she issues a com- 'the
sent each step, and
spent in each step in frame 7 , respectively. The * # of, satis-
mand specifying the service name, service priority, and ex- the time
ecution goal, etc. The coordinator loads the correspond- sum exe-
ing run-time library for the application, which evaluates cution times for each step in a frame period,
* # 89 "! #' / 4(*%+,- : + (2)
energy/power/execution-time for all possible QoS levels, fies the relationship in Equation (2).
along with other application-specific information and han-
dlers. The coordinator negotiates with the new application
and other running applications and makes admission con-
trol, adaptation configuration, and fallback operation deci- We first need to characterize the energy macro-model for
sions based on information from the run-time library. The the video player. We adopt the standard regression analysis
run-time library can be viewed as a wrapper for each appli- method for this purpose. We ran a set of test programs, mea-
cation. When an adaptation configuration is decided upon, sured the total energy consumption and execution time for, ,
&"! # 4(*%+,-
each step, and calculated the average power consumption
coefficients, such as , and .
+ 12
simpsons
Estimation error (%)
mcbain
"! #
10
Note that for this application, we tune the software knob
8
corresponding to dithering. Therefore, we obtain a vector 6
)( *+),-
for with four different values for the color, gray,
4
monochrome and threshold modes. Similarly, we also ob- 2
tained a vector with four values for and , 0
color gray monochrome threshold
respectively.
3'
Dithering method
"! # 4(*%+,- +
When using the energy macro-model for each applica-
tion mode, we need to estimate the execution times ,
, and , in each frame. The only avail- Figure 5. Accuracy evaluation of energy
able input is the video clip. A software package that comes macro-models for different QoS levels
with this application, mpeg play, contains a module called
mpeg stat, which can extract some statistical information
for the video, such as the frame rate, encoding resolution
(in pixels), frame structure, type and size (in bytes) of each
values compose the QoS space for RAT. For different QoS
frame, etc. We derived relationships between the processing
points, there are different active sending power and receiv-
time and video characteristics for each processing step. It
ing power consumptions.
has been shown in a prediction model [3] that the decoding
Note that RAT is a real-time interactive system, and there
time of each frame is linearly dependent on the frame size:
also exists idle time between sending and receiving audio.
Thus, we need to consider the idle power as well. If a
is the frame size in bytes, denotes the type of
(3)
user specifies the duration goal for the conversation, two
frame (I/P/B) of frame 7 , represents
where time values are considered: total duration and an approxi-
the type of dithering mate conversation time (assuming the sending and receiving
method taken, and and are constants. Similarly, times are equal). The energy macro-model is as shown in
Equation (6).
9 ( ( #5 #3 + 5 +
the dithering time and display time are linearly dependent
on the frame resolution, and independent of frame size and
"! #'
type. Equations (4) and (5) show this relationship. (6)
)(*%+,%-
(4)
Figure 6 shows the average power measurement on the
(5) iPAQ for sending audio, when running RAT, under different
6 6 size of a frame in pixels, is the
settings and QoS levels. Idle represents the wireless card-on
where is the horizontal state, with RAT not running; Active is the state after launch-
vertical size, and , and are constants dependent ing RAT, but without audio communication. The other four
on the dithering method. states indicate different sampling rates and channel options.
For each frame, the idle synchronization time can be cal- For example, Mono16 uses a mono channel at a sampling
culated from Equation (2). For some mobile computer sys- rate of 16KHz, while Stereo48 uses a stereo channel at a
tems, the calculated idle time may be less than zero, which sampling rate of 48KHz. We observe that power consump-
shows that the computer does not have enough computing tion is more sensitive to the sampling rate than the channel
capability to run the video at the given frame rate. option. The power differences among the states can be ex-
The impact of our energy macro-model and execution ploited for energy saving by choosing a lower sampling rate.
time estimation techniques is shown for two video clips,
each with four dithering methods, in Figure 5. In this fig-
ure, the absolute energy estimation error is plotted for dif- 3.2
ferent dithering modes. The error is calculated with respect 3
to measured results on an iPAQ. The overall error is under 2.8
Power (w)
12% with the average error being 7.6%, which is acceptable 2.6
for on-line application adaptation. 2.4
2.2
4.2.2 Energy estimation for RAT 2
Idle Active Mono16 Stereo16 Mono48 Stereo48
Different states
We can use a similar procedure for energy estimation for
a voice-over-IP application, RAT [2]. The application can
execute under different audio quality settings, which con-
Figure 6. Variation of power for different
tains a set of parameters, such as mono or stereo channels,
audio sample rate, received sample conversion quality, au- states
dio encoding algorithms, channel transmission encoding al-
gorithms, etc. These parameters and their corresponding4.2.3 Energy estimation for the speech recognizer Since the current advanced power management interface in
Familiar Linux can report residual battery capacity only at a
The dynamic neural network based speech recognizer, very coarse-grained level (the basic unit is 1%), we used an
DNN [29], is an application with rich configurations (adap- external power supply with the battery fully charged to ob-
tation opportunities) for the neural network. It contains two tain the system energy dissipation (note that this measure-
integrated parts: training and recognition. At the front end, ment is done only for validation purposes, the framework
a set of speech utterances is used to extract speech features actually uses the macro-models described earlier).
for training proposes, and the neural network parameters When issuing a service command, the user should pro-
are stored in a file. At the back end, when a new utter- vide the execution goal together with the service name, and
ance is provided as input, the recognizer loads the neural other service-specific parameters. For example, the typical
network parameters and outputs the recognized text for this video player service command looks like “service
utterance. name=video goal=1400 priority=0
There are a number of tunable parameters for the neu- filelist=/home/user/playlist.” Here
ral network structure, such as the time window size for the service refers to command type, name indicates
hidden layer, size of the input feature window, number of which service to call (the eligible service must be in the
hidden layers, etc. Figure 7 shows the impact of one tun- registry), goal specifies the expected duration in seconds,
able parameter, number of hidden layers, on the recogni- and priority the urgency level. The mpeg player also
tion time. It shows a linear relationship. With an increase needs the list of video files (filelist).
in the number of hidden layers, the recognition time and When the client receives a command, it passes it on to
corresponding energy (power remains roughly constant) in- the server. The server first parses the command. If it is a
crease. However, increasing the number of hidden layers service request, it determines the application configuration
also improves the speech recognition accuracy, i.e., QoS (QoS level) and delivers it to the application. The pseudo-
level. code for QoS level configuration is shown in Algorithm 1.
At each adaptation point, the coordinator on the server side
Recognition accuracy (%)
80 94 evaluates the service, estimates the average power and ex-
Recognition time (s)
Time
70 Accuracy 93 ecution time for each QoS level, and selects the best QoS
60
y= 37.205 + 0.68x 92
level to meet the user-specified goal. The service ends ei-
50
R= 1 ther when the duration goal is met, or when the residual
91
40 energy drops to zero, or the specified deadline is reached.
30 90 The first case represents a successful completion of the ap-
0 4 8 12 16 20 24 28 32 36 40 44 48 52
Number of hidden layers
plication, while the others represent a failure. At the end of
the experiment, the larger the residual energy, the more con-
servative software management may be, and the QoS level
Figure 7. Variation of recognition time/quality can be set higher.
The iPAQ can use AC or DC power. The battery that sup-
for different parameter values plies the latter is the Danionics Lithium-Ion Polymer battery
(#DLP 345794). Its capacity is 1400mAH, and its voltage
range is specified as 3.7 to 4.3 V. For our experiment, we
used an initial energy value of 2876 J. As an illustrative
example, for a particular video clip (simpsons), the battery
5 Evaluation of the DSM framework lasts 22 iterations when the video player is at the highest
QoS level, and 32 iterations at the lowest QoS level. This
In this section, we establish the efficacy of our frame- represents a 45.5% extension in battery lifetime. We se-
work in meeting required goals and increasing system en- lected a small initial energy value for experimental conve-
ergy efficiency. We first discuss the experimental setup and nience. When extrapolated to the full capacity of the bat-
then present the experimental results. tery, we can run 179 iterations at the highest QoS level and
261 iterations at the lowest QoS level.
5.1 Experimental setup To evaluate our coordination framework, we designed
several scenarios with a new application joining the system
To validate our goal-directed application adaptation that contains other concurrently-running applications. The
framework, we used the three applications described in Sec- priority of the new application and other existing applica-
tion 4. However, for brevity, we describe the experimen- tions determines their coordination policy. The results are
tal setup using the video player application.We evaluated described in Section 5.2.2.
our framework for 24 video clips, and used each com-
plete video clip as an adaptation block. QoS adaptation is 5.2 Experimental results
achieved through a change in the dithering mode. We used
an iPAQ HP H3870 (with Intel StrongARM microproces- In this section, we first present the experimental results
sor SA-1110 at 206MHz, 64MB DRAM and 32MB flash), on adaptation of single applications, then we evaluate the
running under Familiar Linux, as our evaluation platform. coordination framework.7
Algorithm 1
6 6 7 7 6
1
1: initialize service( ); 3500
(0,3322.5) Expected
3000 (0, 2876)
2: detect residual energy( );
Measured
2500 Unmanaged
3: "!$#&%'
)( *+,.- ; //average system power for the speci-
Energy (J)
2000
fied duration 1500
4: 0/ "12 %43 ; //average power for the last adaptation block 1000
5: 56/ 871 6:9;%@ & 5A6B/ $71 6B9&>C*+,.- & EDF3 ) do
0
6: 200 400 600 800 1000 1200 1400 1600
7: evaluate( GH-I+KJMLNOQ R P O5E
P OSUT ); /*estimate the power/time Time (s)
vector for different QoS levels, SUTV is the number of lev-
els*/ (a) Energy dissipation rate of video player with and without goal-directed
8: W787 6BX =min(YZQ !$# O8[\ZQ "!$#^]_ 0/ 1B2 ); DSM
9: if ( a` TVb]@cMdADe W787 6BX ) then
10: -fg,-%hTVi]Cc ; w/ management
w/o management
11: else Max
for jH%43 to SUTV do
1356.2s 1561.2s
QoS level
12:
13: if ( a` jKd >F W787 6BX ) then
14: -fg,-%Cj ; Min
15: break;
0 200 400 600 800 1000 1200 1400 1600
16: end if Time (s)
17: end for
18: end if
(b) Variation of QoS in the two cases
19: k%Table 1. Knobs and effects of application adaptation
Applications Tunable parameter Resource Range of variation Possible energy saving
Video player Dithering mode CPU time for dithering 1.34-24.93 ms 30.2%
Power 1.5-3.6 W
Speech recognizer Number of hidden layers CPU time for recognition 39.92-69.81 s 54.1%
Voice-over-IP Sampling rate of audio device Power 2.90-3.21 W 9.1%
for the same task from the highest QoS level to the low-
est QoS level. Note that the adaptation policy and goal
Algorithm 2
7 7 7 6
K 7 1
&
1: V ,= +K ;%4 ,g = J" K = +,K = ;
for each application differ slightly according to the asso- 2: if K= +, =high then
ciated variable resource. For the voice-over-IP application, 3: Kg = J"^% ,g = J" -I= ;
RAT, the goal is set to the expected conversation time. Un- 4: while ,g = JM !=NULL do
der the constraint of battery residual energy, we configure 5: if ,g = JM V ,= +K ,= =low then
the appropriate running environment for RAT, and launch 6: send pause signal( ,g = J" J = - K );
it with the corresponding audio device sampling rate. We 7: end if
have trained the speech recognizer with different numbers 8: Kg = JM % Kg = J" ;
of network layers and stored the network parameters into 9: end while
different dictionary files. For the same set of utterances, 10: evaluate(A ,g = J"OJ$TV K K M ); /*evaluate the
the recognition time is shortened greatly by using a smaller appropriate working state, competing with other high-
dictionary corresponding to fewer network layers. Thus, the priority applications*/
energy consumption is reduced greatly and the recognition 11: else
rate is increased. Our experimental results show that the ap- 12: V-I * =search( Kg = J" -I= );
plications can meet their user-specified goal only with goal-
13: if V-l* =high then
directed DSM, and the battery utilization can be improved
14: evaluate( Kg = J"O KU= * ); //energy re-
greatly.
served for high-priority applications
15: else
5.2.2 Coordination among multiple applications 16: evaluate( Kg = J"OJ$TV K K M ); //compete
with low-priority applications
We performed another experiment to evaluate the efficacy 17: end if
of coordination among multiple applications. Applica- 18: end if
tions are classified into two categories according to their
user-specified priority. When a service with a high pri-
ority is called, we check the service list that contains the
concurrently-running applications. The applications with a marked on the figure. We can see from Figure 9(b) that the
low priority yield the resources to the new service, and other existing low-priority video player yields to the new high-
high-priority applications keep running and competing for priority speech recognizer when the latter arrives at time
the battery with the new one. When the new service has a 64.9 s. Figure 9(c) shows that with coordination, the speech
low priority, we still check the service list. If there are high- recognizer can finish under the battery energy constraint.
priority applications running, we reserve battery energy for The video clip is not able to finish even though the video
them and the remaining energy is assigned to the new ser- player resumes execution when the speech recognizer fin-
vice for appropriate adaptation. Otherwise, each low prior- ishes. We guarantee the execution of the more urgent appli-
ity application views itself as the only one using the battery, cation first.
and all of them compete for the battery energy on a fair ba- If there is no coordination, multiple applications com-
sis. Algorithm 2 describes this coordination policy in detail. pete for the battery simultaneously. Figure 10 represents
the experimental results for this case. Figure 10(a) shows
The coordinator acts as a user-level coarse-grained the energy dissipation rate and the starting point for the
scheduler. It is energy-aware and enables multiple applica- speech recognizer. Due to competition from the existing
tions to run efficiently. It favors urgent applications and pre- video player application, the speech recognizer does not fin-
vents other low-priority applications from competing. Con- ish, as shown in Figure 10(c). Neither does the video player.
sider the following scenario. The user is watching a video We also notice that without coordination the battery drains
clip using the video player, which is a low-priority service. faster, even though it starts with the same residual battery
In the middle, an urgent request comes for recognizing a energy.
set of speech utterances. Figure 9 shows the experimental We performed another similar experiment in which the
result under this scenario with system coordination. Fig- existing video player application is of high priority while
ure 9(a) shows the energy dissipation rate. The starting the newly-joining speech recognizer is of low priority.
and finishing time points for the speech recognizer are also When the speech recognizer joins the system, the system400 400
With coordination Without coordination
350 350
300 300
Energy (J)
Energy (J)
250 250
200 200
150 150
100 100
50 50
0 0
0 20 40 60 80 100 120 140 160 180 0 20 40 60 80 100 120 140 160 180
Time (s) Time (s)
(a) Energy dissipation rate of the two applications (a) Energy dissipation rate of the two applications
Low-priority application Low-priority application
Running Running
Running state
Running state
Stop Stop
0 20 40 60 80 100 120 140 160 180 0 20 40 60 80 100 120 140 160 180
Time (s) Time (s)
(b) Running state of the existing low-priority application (b) Running state of the existing low-priority application
High-priority application High-priority application
Running Running
Running state
Running state
Stop Stop
0 20 40 60 80 100 120 140 160 180 0 20 40 60 80 100 120 140 160 180
Time (s) Time (s)
(c) Running state of the newly-joining high-priority application (c) Running state of the newly-joining high-priority application
Figure 9. System coordination when a high- Figure 10. The case of a high-priority applica-
priority application joins the system tion joining the system without coordination
knows the currently running QoS level of the video player through use of a user-specified priority. It is implemented
and its estimated energy from the energy macro-model. in the user space, with no changes needed in the underlying
With coordination, the system reserves the energy for the OS. It is also portable to any OS and mobile platform that is
video player, thus executing the speech recognizer at the POSIX-compliant. It increases the energy efficiency of the
fourth QoS level instead of first (the highest). Both the mobile computer system at the expense of acceptable QoS
video player and speech recognizer complete their execu- degradation. It is complementary to other low-level energy
tion. Without coordination, the speech recognizer checks efficiency techniques (such as those at the OS and compiler
the residual battery energy and views itself as the only one levels, and DVFS, etc.) and exploits the new concept of
that is using the battery. Thus, it is executed at the highest software low power modes.
QoS level, and competes with the high-priority application Our framework does have some limitations. It relies
for the battery more avariciously. Consequently, the bat- greatly on the application being adaptable. In practice,
tery drains faster and neither of the two applications finish however, we found many mobile applications have adapt-
execution. These experiments show the efficacy of both co- able features. In the future, adaptability could be built into
ordination among multiple applications and adaptation for the application to further exploit our framework. Future
each single application. work will focus on cross-layer adaptation, which will ex-
ploit DVFS for each low power mode as well, i.e., both
the resource demand and supply can be scaled in an inter-
6 Conclusions and future work dependent manner. For example, under different dither-
ing methods, the dithering time may vary and create dif-
We have proposed and implemented a DSM framework, ferent slacks in a frame period, so that different frequen-
which not only meets user-specified goals under battery cies/voltages can be used for the same video clip under dif-
energy constraints, but also abides by the user’s intention ferent modes. In such a case, the framework may be ableto direct application-specified information to the underly- [16] C. Lee, J. Lehoczky, D. Siewiorek, R. Rajkumar, and
ing OS and platform for further energy savings. J. Hansen. A scalable solution to the multi-resource QoS
problem. In Proc. Real-Time Systems Symp., pages 315–
Acknowledgments: The authors would like to thank 326, Dec. 1999.
Dr. Johan Pouwelse from Delft University of Technology, [17] J. Mitchell, W. Pennebaker, C. Fogg, and D. LeGall. MPEG
The Netherlands, for his kind offer of the source code for Video Compression Standard. Chapman & Hall, London,
the client-server communication mechanism. 1996.
[18] K. Nahrstedt, D. Xu, D. Wichadukul, and B. Li. QoS-aware
References middleware for ubiquitous and heterogeneous environments.
IEEE Communications, 39(11):140–148, Nov. 2001.
[19] D. Narayanan and M. Satyanarayanan. Predictive resource
[1] MPEG player. http://bmrc.berkeley.edu/frame/research/mpeg/. management for wearable computing. In Proc. Int. Conf.
[2] Robust Audio Tool. http://internet2.motlabs.com/ipaq/rat.htm. Mobile Systems, Applications, & Services, pages 113–128,
[3] A. Bavier, A. Montz, and L. Peterson. Predicting MPEG ex- May 2003.
ecution times. In Proc. Int. Conf. Measurement & Modeling [20] B. D. Noble, M. Satyanarayanan, D. Narayanan, J. E. Tilton,
of Computer Systems, pages 131–140, June 1998. J. Flinn, and K. R. Walker. Agile application-aware adapta-
[4] L. Benini, M. Kandemir, and J. Ramanujam, editors. Com- tions for mobility. In Proc. ACM Symp. Operating Systems
pilers and Operating Systems for Low Power. Kluwer Aca- Principles, pages 276–287, 1997.
demic Publishers, Boston, MA, Oct. 2003. [21] T. Pering, T. Burd, and R. Brodersen. The simulation and
[5] V. Bharghavan and V. Gupta. A framework for applica- evaluation of dynamic voltage scaling algorithms. In Proc.
tion adaptation in mobile computing environments. In Proc. Int. Symp. Low Power Electronics & Design, pages 76–81,
Computer Software & Application Conf., pages 573–579, Aug. 1998.
Nov. 1997. [22] A. Peymandoust, T. Simunic, and G. De Micheli. Low
[6] S. Chakraborty and D. K. Y. Yau. Predicting energy con- power embedded software optimization using symbolic al-
sumption of MPEG video playback on handhelds. In Proc. gebra. In Proc. Design Automation & Test Europe Conf.,
Int. Conf. Multimedia & Expo, pages 317–320, Aug. 2002. pages 1052–1059, Mar. 2002.
[7] A. P. Chandrakasan, W. J. Bowhill, and F. Fox. Design [23] J. Pouwelse. Power Management for Portable Devices.
of High-Performance Microprocessor Circuits. Wiley-IEEE PhD thesis, Faculty of Information Technology and Sys-
Press, 2000. tems, Delft University of Technology, The Netherlands, Oct.
[8] E. De Lara, D. S. Wallach, and W. Zwaenepol. Pup- 2003.
peteer: Component-based adaptation for mobile computing. [24] J. Pouwelse, K. Langendoen, and H. Sips. Dynamic volt-
In Proc. USENIX Symp. Internet Technologies & Systems, age scaling on a low-power microprocessor. In Proc. Int.
pages 159–170, Mar. 2001. Conf. Mobile Computing & Networking, pages 251–259,
[9] C. Efstratiou, A. Friday, N. Davies, and K. Cheverst. A plat- July 2001.
form supporting coordinated adaptation in mobile systems. [25] J. M. Rabaey and M. Pedram, editors. Low Power Design
In Proc. Wkshp. Mobile Computing Systems & Applications, Methodologies. Kluwer Academic Publishers, Boston, MA,
pages 128–137, June 2002. 1995.
[10] Y. Fei, S. Ravi, A. Raghunathan, and N. K. Jha. Energy- [26] P. Shenoy and P. Radkov. Proxy-assisted power-friendly
optimizing source code transformations for OS-driven em- streaming to mobile devices. In Proc. SPIE/ACM Conf.
bedded software. In Proc. Int. Conf. VLSI Design, pages Multimedia Computing & Networking, pages 177–191, Jan.
261–266, Jan. 2004. 2003.
[11] J. Flinn and M. Satyanarayanan. Energy-aware adaptation [27] T. K. Tan, A. Raghunathan, and N. K. Jha. Software ar-
for mobile applications. In Proc. ACM Symp. Operating Sys- chitectural transformations: A new approach to low energy
tems Principles, pages 48–63, Dec. 1999. embedded software. In Proc. Design Automation & Test Eu-
[12] T. Ishihara and H. Yasuura. Voltage scheduling problem rope Conf., pages 1046–1051, Mar. 2003.
for dynamically variable voltage processors. In Proc. Int. [28] T. K. Tan, A. Raghunathan, G. Lakshminarayana, and N. K.
Symp. Low Power Electronics & Design, pages 197–202, Jha. High-level energy macro-modeling of embedded soft-
Aug. 1998. ware. IEEE Trans. Computer-Aided Design, 21(9):1037–
[13] N. K. Jha. Low power system scheduling and synthesis. 1050, Sept. 2002.
In Proc. Int. Conf. Computer-Aided Design, pages 259–263, [29] L. Zhong, Y. Shi, and R. Liu. A dynamic neural network
Nov. 2001. for syllable recognition. In Proc. Int. Joint Conf. Neural
[14] M. Kandemir, N. Vijaykrishnan, and M. J. Irwin. Compiler Networks, pages 2997–3001, July 1999.
optimizations for low power systems. In R. Melhem and
R. Graybill, editors, Power Aware Computing. Kluwer Aca-
demic Publishers, Boston, MA, 2002.
[15] C. Krintz, Y. Wen, and R. Wolski. Predicting program power
consumption. Technical Report 2002-20, Department of
Electrical and Computer Engineering, University of Califor-
nia at Santa Barbara, July 2002.You can also read
