`
`Jason Flinn and M. Satyanarayanan
`School of Computer Science
`Carnegie Mellon University
`
`Abstract
`
`In this paper, we demonstrate that a collaborative relation(cid:173)
`ship between the operating system and applications can be
`used to meet user-specified goals for battery duration. We
`first show how applications can dynamically modify their be(cid:173)
`havior to conserve energy. We then show how the Linux op(cid:173)
`erating system can guide such adaptation to yield a battery(cid:173)
`life of desired duration. By monitoring energy supply and
`demand, it is able to select the correct tradeoff between en(cid:173)
`ergy conservation and application quality. Our evaluation
`shows that this approach can meet goals that extend battery
`life by as much as 30%.
`
`1 Introduction
`
`Energy is a vital resource for mobile computing. There is
`growing consensus that advances in battery technology and
`low-power circuit design cannot, by themselves, meet the
`energy needs of future mobile computers -
`the higher levels
`of the system must also be involved [1, 7].
`In this paper, we explore how applications can dynam(cid:173)
`ically modify their behavior to conserve energy. To guide
`such adaptation, the operating system monitors energy sup(cid:173)
`ply and demand. When energy is plentiful, application be(cid:173)
`havior is biased toward a good user experience; when it is
`scarce, the behavior is biased toward energy conservation.
`To validate the energy benefits of adaptation, we present
`results from a detailed study of applications running on the
`Odyssey platform for mobile computing. Our results show
`energy reductions in the range of 7% to 72%, with a mean
`of 36%. Combined with hardware power management, we
`achieve overall reductions between 31 % and 76%, with a
`mean of 50% -
`in effect, doubling battery life.
`
`lbis research was supported by the National Science Foundation (NSF) under grant
`number CCR-9901696, and the Air Force Materiel Command (AFMC) under DARPA
`contract number Fl9628-96-C-0061. Addition support was provided by IBM. The
`views and conclusions contained here are those of the authors and should not be inter(cid:173)
`preted as necessarily representing the official policies or endorsements, either express
`or implied, of NSF, AFMC, DARPA, IBM, CMU, or the U.S. Government.
`Permission to make digital or hard copies of all or part of this work for
`personal or classroom use is granted without fee provided that copies are
`not made or distributed for profit or commercial advantage, and that copies
`bear this notice and the full citation on the first page. To copy otherwise, to
`republish, to post on servers or to redistribute to lists, requires prior specific
`permission and/or a fee.
`
`SOSP-17 12/1999 Kiawah Island, SC
`
`@1999 ACM l-58113-140-2/99/0012 . . . $5.00
`
`Our measurements also suggest a novel approach to re(cid:173)
`ducing the energy drain of the display, an important but dif(cid:173)
`ficult challenge. Using this approach, we project a further
`energy reduction ranging from 7% to 29%.
`Finally, we show how the operating system can con(cid:173)
`trol adaptation by concurrent applications to give a battery
`life of user-specified duration. To perform this control, we
`have extended Odyssey to predict future energy demand
`from measurements of past usage. When there is substantial
`mismatch between predicted demand and available energy,
`Odyssey notifies applications to adapt. Using this approach,
`we demonstrate that Odyssey can extend battery-life to meet
`user-specified goals that vary by as much as 30%.
`We begin with brief overviews of PowerScope, a tool we
`built to profile energy usage, and Odyssey. Three major sec(cid:173)
`tions follow: Section 3, on energy savings through adapta(cid:173)
`tion; Section 4, on reducing display energy usage; and Sec(cid:173)
`tion 5, on achieving a desired battery life. We close with a
`summary of related work and future plans.
`
`2 Background
`2.1 The PowerScope energy profiler
`PowerScope is a tool for mapping energy consumption to
`specific software components. Its functionality and design
`are inspired by CPU profilers such as prof and gprof that
`help expose code components wasteful of processor cycles.
`Using PowerScope, one can determine what fraction of the
`total energy consumed during a certain time period is due
`to specific processes. Further, one can determine the energy
`
`Data
`Collec11on
`Comp;1er
`
`[)gitd
`M.Jttmeter
`
`FC/AD
`Somples
`
`This hardware setup is used during PowerScope data col(cid:173)
`lection. A data collection computer distinct from the profiling
`computer controls the multimeter and stores samples from it.
`Later, program counter and process id samples are correlated
`offline with current levels to yield energy profiles.
`
`Figure 1. Data collection in PowerScope
`
`48
`
`Apple Ex. 1022
`Apple Inc. v. Firstface Co. Ltd.
`IPR2019-00613
`Page 00001
`
`
`
`ProceBS
`
`CPU
`Average
`Total
`Time(s) Energy(J) Pover(II)
`
`/uar/odyasay/bin/xanim
`/uar/l111l6/bin/l
`Kernel
`Interrupta-WaveLAll
`/uar/odyssey/bin/odyasey
`
`66.67
`35.72
`50.89
`18.62
`12.19
`
`643.17
`331.68
`328.71
`166.88
`123.40
`
`9,66
`9.28
`6.46
`8.91
`10.12
`
`Total
`
`183.99
`
`1692.76
`
`8.66
`
`Energy Usage Detail for process /usr/odyssey/bin/odyssey
`
`Procedure
`-----------------------
`_Dispatcher
`_IOKGR_CheckDeecriptors
`_aftp_DataArrived
`_rpc2_RecvPacket
`_Examin(cid:127) Packat
`
`Total
`CPU
`Time(s) Energy(J)
`----------
`2,63
`1.74
`1.68
`1.67
`1.66
`
`0.25
`0.17
`0.16
`0.16
`0.16
`
`Average
`Pover(II)
`
`10.11
`10.23
`10.48
`10.41
`10.35
`
`This figure shows a sample energy profile. The first table sum(cid:173)
`marizes the energy usage by process, whlle the table below
`shows a portion of the detailed profile for a single process.
`Only part of the full profile is shown.
`
`Figure 2. Example of an energy profile
`
`consumption of individual procedures within a process. By
`providing fine-grained feedback, PowerScope helps expose
`system components most responsible for energy consump(cid:173)
`tion. Since PowerScope was recently described in detail [8],
`we only provide a brief overview here.
`PowerScope uses statistical sampling to profile the en(cid:173)
`ergy usage of a computer system. To reduce overhead, pro(cid:173)
`files are generated in two stages. During the data collection
`stage, shown in Figure 1, the tool samples power consump(cid:173)
`tion as well as the program counter (PC) and process identi(cid:173)
`fier (PID) of the code executing on the profiling computer. A
`digital multimeter, currently a Hewlett Packard 3458a, sam(cid:173)
`ples the current drawn by the profiling computer through its
`external power input. Since the input voltage on computers
`is well-controlled (to within 0.25% in our measurements),
`current samples alone are adequate to infer energy consump(cid:173)
`tion. The output of this stage consists of a sequence of cur(cid:173)
`rent level samples and a correlated sequence of PC/PID sam(cid:173)
`ples. In a later off-line stage, PowerScope combines these
`sequences with symbol table information from binaries and
`shared libraries on the profiling computer. The result is an
`energy profile such as that shown in Figure 2.
`
`2.2 The Odyssey platform for adaptation
`The design rationale and architecture of Odyssey were pre(cid:173)
`sented in an earlier paper [17). Adaptation in Odyssey in(cid:173)
`volves the trading of data quality for resource consumption.
`For example, a client playing full-color video data from a
`server could switch to black and white video when band(cid:173)
`width drops, rather than suffering lost frames. Similarly, a
`map application might fetch maps with less detail rather than
`suffering long transfer delays for full-quality maps.
`Odyssey captures this notion of data degradation through
`an attribute called fidelity, that defines the degree to which
`data presented at a client matches the reference copy at a
`
`Application
`
`Kernel
`
`Figure 3. Odyssey architecture
`
`server. Fidelity is a type-specific notion since different kinds
`of data can be degraded differently. Since the minimal level
`of fidelity acceptable to the user can be both time and appli(cid:173)
`cation dependent, Odyssey allows each application to spec(cid:173)
`ify the fidelity levels it currently supports.
`Odyssey supports concurrent adaptation by diverse ap(cid:173)
`plications. The client architecture providing this support is
`shown in Figure 3. Odyssey is conceptually part of the op(cid:173)
`erating system, even though it is implemented in user space
`for simplicity. The viceroy is the Odyssey component re(cid:173)
`sponsible for monitoring the availability of resources and
`managing their use. Code components called wardens en(cid:173)
`capsulate type-specific functionality. There is one warden
`for each data type in the system. We have built four adap(cid:173)
`tive applications on top of Odyssey: a video player, a speech
`recognizer, a map viewer, and a Web browser. Such multi(cid:173)
`media and speech-enabled applications are of growing im(cid:173)
`portance in mobile computing, although they are not yet as
`common as spreadsheets and word processors. Relevant de(cid:173)
`tails of these applications are presented later.
`Odyssey is integrated into Linux as a new VFS file sys(cid:173)
`tem, along with a set of API extensions for expressing re(cid:173)
`source expections. If resource levels stray beyond an appli(cid:173)
`cation's expectation, Odyssey notifies it through an upcall.
`The application then adjusts its fidelity to match the new re(cid:173)
`source level, and communicates a new set of expectations
`to Odyssey. Some applications, such as our Web browser
`and map viewer, use a proxy to avoid modifications to appli(cid:173)
`cation source code. Other applications, such as our video
`player and speech recognizer, are modified to interact di(cid:173)
`rectly with Odyssey.
`The initial Odyssey prototype only supported network
`bandwidth adaptation. The work reported here extends
`Odyssey to support energy adaptation.
`
`3 Energy impact of fidelity
`
`Does lowering data.fidelity yield significant energy savings?
`This was the crucial question facing us when we began this
`work. Incorporating support for energy-aware adaptation
`into Odyssey is futile if the potential savings are meager.
`
`49
`
`IPR2019-00613 Page 00002
`
`
`
`We were also keen to confirm that the energy sav(cid:173)
`ings from lowering fidelity could enhance those achiev(cid:173)
`able through well-known hardware power management tech(cid:173)
`niques such as turning off the disk or slowing the CPU [6, 13,
`16]. Although these distinct approaches to energy savings
`seem composable, we wanted to verify this experimentally.
`
`3.1 Methodology
`To answer these questions, we measured the energy used by
`the Odyssey video player, speech recognizer, map viewer,
`and Web browser. We first observed the applications as they
`operated in isolation, and then as they operated concurrently.
`To maintain fidelity constant throughout an experiment, we
`disabled Odyssey's dynamic adaptation capability.
`We explored sensitivity of energy consumption to data
`content by using four data objects for each application: that
`is, four video clips, four speech utterances, four maps, and
`four Web images. We first measured the baseline energy us(cid:173)
`age for each object at highest fidelity with hardware power
`management disabled. Next, we measured energy usage
`with hardware-only power management. Then, for each
`lower fidelity level we measured energy usage with hard(cid:173)
`ware power management enabled.
`This sequence of measurements is directly reflected in
`the format of the graphs presenting our results: Figures 6,
`8, 10 and 13. Since a considerable amount of data is con(cid:173)
`densed into these graphs, we explain their format here even
`though their individual contents will not be meaningful until
`the detailed discussions in Sections 3.3 through 3.6.
`For example, consider Figure 6. There are six bars in
`each of the four data sets on the X axis; each data set cor(cid:173)
`responds to a different video clip. The height of each bar
`shows total energy usage, and the shadings within each bar
`show energy usage by software component. The component
`labelled "Idle" aggregates samples that occurred while ex(cid:173)
`ecuting the kernel idle procedure -
`effectively a Pentium
`hl t instruction. The component labelled "WaveLAN" ag(cid:173)
`gregates samples that occurred during network interrupts.
`For each data set, the first and second bars, labelled
`"Baseline" and "Hardware-Only Power Mgmt.", show en(cid:173)
`ergy usage at full fidelity with and without hardware power
`management. Each of the remaining bars show the energy
`usage at a different fidelity level with hardware power man(cid:173)
`agement enabled. The difference between one of these bars
`and the first bar ("Baseline") gives the combined benefit of
`hardware power management and fidelity reduction. The
`difference between one of these bars and the second one
`("Hardware-Only Power Mgmt.") gives the savings directly
`attributable to reduction in fidelity.
`The measurements for the bars labelled "Hardware-Only
`Power Mgmt." were obtained by powering down as many
`hardware components as possible for each application. For
`example, we placed the disk in standby mode after 10 sec(cid:173)
`onds of inactivity. Further, we modified the network commu-
`
`WaveLAN
`
`Component State
`Bright
`Displ~y
`Dim
`Idle
`Standby
`Idle
`Standby
`Idle
`
`Disk
`
`Other
`
`Power (W)
`4.54
`1.95
`1.46
`0.18
`0.88
`0.24
`3.20
`
`Background (display dim, WaveLAN & disk standby)= 5.6W.
`
`This figure shows the measured power consumption of com(cid:173)
`ponents of the IBM 560X laptop. Power usage is slightly but
`consistently superlinear; for example, the laptop uses 10.28 W
`when the screen is brightest and the disk and network are idle
`- 0.21 W more t111an the sum of the individual power usage of
`each component. The last row shows the power used when
`the disk, screen, and network are all powered off. Each value
`is the mean of five trials -
`in all cases, the sample standard
`deviation is less than 0.01 W.
`
`Figure 4. Power consumption of IBM ThinkPad 560X
`
`nication package used by Odyssey to place the wireless net(cid:173)
`work interface in standby mode except during remote proce(cid:173)
`dure calls or bulk transfers. Finally, we turned off the display
`during the speech application. To ensure good experimental
`control, we disabled BIOS-level hardware power manage(cid:173)
`ment. While these hardware power management techniques
`are simple, they combine to yeild up to a 34% reduction in
`energy usage.
`
`3.2 Experimental setup
`All measurements'reported in this paper were obtained on a
`233 MHz Pentium IBM ThinkPad 560X laptop with 64 MB
`of memory, running the Linux 2.2 operating system. This
`machine was configured as an Odyssey client and communi(cid:173)
`cated with servers over a 2 Mb/s wireless WaveLAN network
`operating at 900 MHz. The servers were 200 MHz Pentium
`Pro desktop computers with 64 MB of memory.
`We profiled energy usage on the client with PowerScope,
`sampling approximately 600 times per second. To avoid
`confounding effects due to non-ideal battery behavior, the
`client used an external power supply. Further, to eliminate
`the effects of charging, the client's battery was removed.
`Figure 4 shows the power usage of several hardware
`components of this laptop. To obtain these measurements,
`we used PowerScope to measure the change in power us(cid:173)
`age as we ran benchmarks which varied the power states of
`individual hardware components.
`
`3.3 Video player
`3.3.1 Description
`We first measured the impact of fidelity on the video ap(cid:173)
`plication shown in Figure 5. Xanim fetches videos from a
`server through Odyssey and displays them on the client. It
`supports two dimensions of fidelity: varying the amount of
`
`50
`
`IPR2019-00613 Page 00003
`
`
`
`2500
`
`2000
`
`S00
`
`0
`
`Oldie
`lr.l.!Xanim
`X Server
`•odyssey
`~WaveLAN
`•Kernel
`
`Video 1
`
`Video2
`
`Video3
`
`Video4
`
`This figure shows the energy used to display four QuickTime/Cinepak videos from 127 to 226 seconds in length, ordered from right
`to left above. For each video, the first bar shows energy usage without hardware power management or fidelity reduction. The
`second bar shows the impact of hardware power management alone. The next two show the impact of lossy compression. The
`fifth shows the impact of reducing the size of the display window. The final bar shows the combined effect of lossy compression
`and window size reduction. The shadings within each bar detail energy usage by software component. Each value is the mean
`of five trials -
`the error bars show 90% confidence intervals.
`
`Figure 6. Energy impact of fidelity for video playing
`
`: · · · · · · · · · · · · · c1iani· · · · · · · · · · · · ·:
`.
`.
`.
`.
`.
`~--~.
`
`Video
`Server
`
`.
`.
`··································
`Figure 5. Odyssey video player
`
`lossy compression used to encode a video clip, and varying
`the size of the window in which it is displayed. There are
`multiple tracks of each video clip on the server, each gen(cid:173)
`erated off-line from the full-fidelity video clip using Adobe
`Premiere. They are identical to the original except for size
`and the level of lossy compression used in frame encoding.
`
`3.3.2 Results
`Figure 6 shows the energy used to display four videos at dif(cid:173)
`ferent fidelities. At baseline fidelity, much energy is con(cid:173)
`sumed while the processor is idle because of the limited
`bandwidth of the wireless network- not enough video data
`is transmitted to saturate the processor. Most of the remain(cid:173)
`ing energy is consumed by asynchronous network interrupts,
`the Xanim video player, and the X server.
`For the four video clips, hardware-only power manage(cid:173)
`ment reduces energy consumption by a mere 9-10%. There
`is little opportunity to place the network in standby mode
`since it is nearly saturated. Most of the reduction is due
`to disk power management -
`the disk remains in standby
`mode for the entire duration of an experiment.
`
`The bars labelled Premiere-B and Premiere-C in Figure 6
`show the impact of lossy compression. Premiere-C, at the
`highest compression, consumes 16-17% less energy than
`hardware-only power management. Note that these gains
`are understated due to the bandwidth limitation imposed by
`our wireless network. With a higher-bandwidth network, we
`could raise baseline fidelity and thus transmit better video
`quality when energy is plentiful. The relative energy savings
`of Premiere-C would then be higher.
`By examining the shadings of each bar in Figure 6, we
`see that compression significantly reduces the energy used
`by Xanim, Odyssey and the WaveLAN device driver. How(cid:173)
`ever, the energy used by the X server is almost completely
`unaffected by compression. We conjecture that this is be(cid:173)
`cause video frames are decoded before they are given to the
`X server, and the size of this decoded data is independent of
`the level of lossy compression.
`To validate this conjecture, we measured the effect of
`halving both the height and width of the display window,
`effectively introducing a new dimension of fidelity. As Fig(cid:173)
`ure 6 shows, shrinking the window size reduces energy con(cid:173)
`sumption 19-20% beyond hardware-only power manage(cid:173)
`ment. The shadings on the bars confirm that reducing win(cid:173)
`dow size significantly decreases X server energy usage. In
`fact, within the bounds of experimental error, X server en(cid:173)
`ergy consumption is proportional to window area.
`Finally, we examined the effect of combining Premiere(cid:173)
`C encoding with a display window of half the baseline height
`and width. This results in a 28-30% reduction in energy us(cid:173)
`age relative to hardware-only power management. Relative
`to baseline, using all the techniques (hardware, Premiere-C,
`and reduced window) together yields about a 35% reduction.
`
`51
`
`IPR2019-00613 Page 00004
`
`
`
`:·············c,iani'············
`
`Viceroy
`
`:! Speech
`;\....._ __ _,/
`:: Front-End
`
`Remote
`Janus
`Server
`
`-·]
`
`Local
`Janus
`Server
`
`(
`
`'-
`.
`.
`··································
`Figure 7. Odyssey speech recognizer
`
`From the viewpoint of further energy reduction, the
`rightmost bar of each data set in Figure 6 offers a pessimistic
`message: there is little to be gained by further efforts to re(cid:173)
`duce fidelity. Virtually all the energy used at this fidelity is
`in the idle state, with the display consuming a large share.
`Turning off the display is, of course, not an option when
`watching video. We will return to this point in Section 4.
`
`3.4 Speech recognizer
`3.4.1 Description
`Our second application is an adaptive speech recognizer. As
`shown in Figure 7, it consists of a front-end that generates
`a speech waveform from an utterance and submits it via
`Odyssey to a local or remote instance of the Janus speech
`recognition system [23].
`Local recognition avoids network transmission and is
`unavoidable if the client is disconnected. In contrast, re(cid:173)
`mote recognition incurs the delay and energy cost of net(cid:173)
`work communication but can exploit the CPU, memory and
`energy resources of a remote server that is likely to be op(cid:173)
`erating from a power outlet rather than a battery. The sys(cid:173)
`tem also supports a hybrid mode of operation in which the
`first phase of recognition is performed locally, resulting in
`a compact intermediate representation that is shipped to the
`remote server for completion of the recognition. In effect,
`the hybrid mode uses the first phase of recognition as a type(cid:173)
`specific compression technique that yields a factor of five
`reduction in data volume with little computational overhead.
`Fidelity is lowered in this application by using a reduced
`vocabulary and a less complex acoustic model. This substan(cid:173)
`tially reduces the memory footprint and processing required
`for recognition, but degrades recognition quality. The sys(cid:173)
`tem alerts the user of fidelity transitions using a synthesized
`voice. The use of low fidelity is most compelling in the case
`of local recognition on a resource-poor disconnected client,
`although it can also be used in hybrid and remote cases.
`Although reducing fidelity limits the number of words
`available, the word-error rate may not increase. Intuitively,
`this is because the recognizer makes fewer mistakes when
`
`52
`
`choosing from a smaller set of words in the reduced vocab(cid:173)
`ulary. This helps counterbalance the effects of reducing the
`sophistication of the acoustic model.
`
`3.4.2 Results
`Figure 8 presents our measurements of client energy usage
`when recognizing four pre-recorded utterances using local,
`remote and hybrid strategies at high and low fidelity. The
`baseline measurements correspond to local recognition at
`high fidelity without hardware power management. Since
`speech recognition is compute-intensive, almost all the en(cid:173)
`ergy in this case is consumed by Janus.
`Hardware-only power management reduces client en(cid:173)
`ergy usage by 33-34%. Such a substantial reduction is pos(cid:173)
`sible because the display can be turned off arid both the net(cid:173)
`work and disk can be placed in standby mode for the en(cid:173)
`tire duration of an experiment. This assumes that user inter(cid:173)
`actions occur solely through speech, and that disk accesses
`can be avoided because the vocabulary, language model and
`acoustic model fit entirely in physical memory. More com(cid:173)
`plex recognition tasks may trigger disk activity and hence
`show less benefit from hardware power management.
`Lowering fidelity by using a reduced speech model re(cid:173)
`sults in a 25-46% reduction in energy consumption relative
`to hardware-only power management. This corresponds to a
`50-65% reduction relative to the baseline.
`Remote recognition at full fidelity reduces energy us(cid:173)
`age by 33-44% below that obtained by using hardware-only
`power management. If fidelity is also reduced, the corre(cid:173)
`sponding savings is 42-65%. These figures are comparable
`to the energy savings for remote execution reported in the lit(cid:173)
`erature for other compute-intensive tasks [18]. As the shad(cid:173)
`ings in the fourth and fifth bars of each data set in Figure 8
`indicate, most of the energy consumed by the client in re(cid:173)
`mote recognition occurs with the processor idle - much of
`this is time spent waiting for a reply from the server. Lower(cid:173)
`ing fidelity speeds recognition at the server, thus shortening
`this interval and yielding additional energy savings.
`Hybrid recognition offers slightly greater energy savings
`than remote recognition: 47-55% at full fidelity, and 53-
`70% at low fideUty, both relative to hardware-only power
`management. Hybrid recognition increases the fraction of
`energy used by the local Janus code; but this is more than
`offset by the reduction in energy for network transmission
`and idle time.
`Overall, the net effect of combining hardware power
`management wit!) hybrid, low-fidelity recognition is a 69-
`80% reduction in energy usage relative to the baseline. In
`practice, the optimal strategy will depend on resource avail(cid:173)
`ability and the user's tolerance for low-fidelity recognition.
`
`IPR2019-00613 Page 00005
`
`
`
`150
`
`Idle
`~Janus
`•odyssey
`~WaveLAN
`•Kernel
`
`i 100
`
`"3
`0
`
`""") ->. e> Q)
`
`C: 50
`w
`
`0
`
`Utterance 1
`
`Utterance2
`
`Utterance3
`
`Utterance4
`
`This figure shows the energy used to recognize four spoken utterances from one to seven seconds in length, ordered from right to
`left above. For each utteranc~. the first bar shows energy consumption without hardware power management or fidelity reduction.
`The second bar shows the impact of hardware power management alone. The remaining bars show the additional savings
`realized by adaptive strategies. The shadings within each bar detail energy usage by activity. Each measurement is the mean of
`five trials -
`the error bars show 90% confidence intervals.
`
`Figure 8. Energy impact of fidelity for speech recognition
`
`3.5 Map viewer
`3.5.1 Description
`The third application that we measured was an adaptive map
`viewer named Anvil. As shown in Figure 9, Anvil fetches
`maps from a remote server via Odyssey and displays them on
`the client. Fidelity can be lowered in two ways: filtering and
`cropping. Filtering eliminates fine detail and less important
`features (such as secondary roads) from a map. Cropping
`preserves detail, but restricts data to a geographic subset of
`the original map. The client annotates the map request with
`the desired amount of filtering and cropping. The server per(cid:173)
`forms any requested operations before transmitting the map
`data to the client.
`
`=·············c,itii-ii··············=
`.
`.
`.
`.
`.
`.
`: ---- ~---- :
`.
`.
`.
`.
`.
`.
`
`· '--A-nv_i_l _,,
`
`·
`
`Map
`Server
`
`.
`.
`··································
`Figure 9. Odyssey map viewer
`
`3.5.2 Results
`We measured the energy used by the client to fetch and dis(cid:173)
`play maps of four different cities. Viewing a map differs
`from the two previous applications in that a user typically
`needs a non-trivial amount of time to absorb the contents of
`a map after it has been displayed. This period, which we re(cid:173)
`fer to as think time, should logically be viewed as part of the
`
`application's execution since energy is consumed in keeping
`the map visible. In contrast, the user needs negligible time
`after the display of the last frame or the recognition of an
`utterance to complete use of the video or speech application.
`Think time is likely to depend on both the user and the
`map being displayed. Our approach to handling this vari(cid:173)
`ability was to use an initial value of 5 seconds and then per(cid:173)
`forming sensitivity analysis for think times of 0, 10 and 20
`seconds. For brevity, Figure 10 only presents detailed results
`for the 5 second case; for other think times, we present only
`the summary information in Figure 11.
`The baseline bars in Figure 10 show that most of the en(cid:173)
`ergy is consumed while the CPU is idle; a significant portion
`of this goes to keeping the display backlit during the five
`second think time. The shadings on the bars indicate that
`network communication is a second significant drain on en(cid:173)
`ergy. The comparatively larger confidence intervals for this
`application result from variation in the time required to fetch
`a map over the wireless network.
`Hardware-only power management reduces energy con(cid:173)
`sumption by about 9-19% relative to the baseline. Although
`there is little opportunity for network power management
`while the map is being fetched, the network can remain in
`standby mode during think time. Since the disk is never
`used, it can always remain in standby mode.
`The third and fourth bars of each data set show the effect
`of fidelity reduction through two levels of filtering. One fil(cid:173)
`ter omits minor roads, while the more aggressive filter omits
`both minor and secondary roads. The savings from the mi(cid:173)
`nor road filter range from 6-51 % relative to hardware-only
`power management. The corresponding figure for the sec(cid:173)
`ondary road filter is 23-55%.
`
`53
`
`IPR2019-00613 Page 00006
`
`(cid:143)
`
`
`ISO
`
`j 100
`"5
`0
`3
`>, e (l)
`SO w
`C
`
`Oldie
`r:ilJAnvil
`X Server
`•odyssey
`~WaveLAN
`•Kernel
`
`San Jose
`
`Allentown
`
`Boston
`
`Pittsburgh
`
`This figure shows the energy used to view four U.S.G.S. maps. For each map, the first bar shows energy usage without hardware
`power management or fidelity reduction, with a 5 second think time. The second bar shows the impact of hardware power
`management alone. The remaining bars show the additional savings realized by degrading map fidelity. The shadings within each
`bar detail energy usage by activity. Each measurement is the mean of ten trials-the error bars are 90% confidence intervals.
`
`Figure 10. Energy impact of fidelity tor map viewing
`
`we repeated the a~ove experiments at think times of 0, 10
`and 20 seconds. At any given fidelity, energy usage, E1 in(cid:173)
`creases with think time, t. We expected a linear relationship:
`E, = Eo + t ·PB, where Eo is the energy usage for this fidelity
`at zero think time and PB is the background power consump(cid:173)
`tion on the client (5.6 W from Figure 4).
`Figure 11 confirms that a linear model is indeed a good
`fit. This figure plots the energy usage for four different val(cid:173)
`ues of think time for three cases: baseline, hardware-only
`power manageme11t, and lowest fidelity. The divergent lines
`for the first two cases show that the energy reduction from
`hardware-only power management scales linearly with think
`time. The parallel lines for the second and third cases show
`that fidelity reduction achieves a constant benefit, indepen(cid:173)
`dent of think time. The complementary nature of these two
`approaches is thus well illustrated by these measurements.
`
`3.6 Web browser
`3.6.1 Description
`Our fourth application is an adaptive Web browser based on
`Netscape Navigator, as shown in Figure 12. In this applica-
`
`250
`
`~ 200
`Cl)
`Q)
`:5
`~ 150
`>.
`~
`l00
`Q)
`C w
`
`50
`
`• Baseline
`• Hardware-Only Power Mgmt.
`• Lowest Fidelity
`
`...
`
`.•.
`
`...
`
`15
`IO
`Think Time (seconds)
`
`20
`
`25
`
`This figure shows how the energy used to view the San Jose
`map from Figure 10 varies with think time. The data points
`show measured energy usage. The solid, dashed and dotted
`lines represent linear models for energy usage for the base(cid:173)
`line, hardware-only power management and lowest fidelity
`cases. The latter combines filtering and cropping, as in the
`rightmost bars of Figure 10. Each measurement is the mean
`of ten trials -
`the error bars are 90% confidence intervals.
`
`Figure 11. Effect of user think time tor map viewing
`
`The fifth bar of each data set shows the effect of lower(cid:173)
`ing fidelity by cropping a map to half its original height and
`width. Energy usage at this fidelity is 14--49% less than with
`hardware-only power management. In other words, crop(cid:173)
`ping is less effective than filtering for these samples. Com(cid:173)
`bining cropping with filtering results in an energy savings
`of 36-66% relative to hardware-only power management, as
`shown by the rightmost bars of each data set. Relative to the
`baseline, this is a reduction of 46-70%. There is little sav(cid:173)
`ings left to be extracted through software