Pervasive computing approach to energy management
Sponsored Links
This presentation is the property of its rightful owner.
1 / 55

Pervasive Computing Approach to Energy Management PowerPoint PPT Presentation


  • 55 Views
  • Uploaded on
  • Presentation posted in: General

Pervasive Computing Approach to Energy Management. PhD Dissertation by: Ahmed Abukmail 11/18/2005. Outlines. Vision Motivation and Statement of Problem Review of Proposed Research Post-Proposal Accomplishments Extended review of related work (Grid Computing)

Download Presentation

Pervasive Computing Approach to Energy Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Pervasive Computing Approach to Energy Management

PhD Dissertation by:

Ahmed Abukmail

11/18/2005


Outlines

  • Vision

  • Motivation and Statement of Problem

  • Review of Proposed Research

  • Post-Proposal Accomplishments

    • Extended review of related work (Grid Computing)

    • Extended Pseudo-parser to handle a wider range of language constructs.

    • Extended benchmarks for deeper validation of proposed approach.

    • Created the runtime support.

  • Experimental Validation

  • Conclusion and Future Work


Vision

  • Imagine walking inside of an airport terminal and your mobile computer’s battery has 2 hours left on it. But by walking inside the airport terminal, the 2 hours just became 3 or 4 (more than 2). But yet, you’ve just walked out of a cab and have not connected your computer to the wall to recharge its battery.


Vision

  • So, did the battery recharge?

    • Yes – It’s going to last longer.

    • No – It still has the same amount of charge as before (maybe even less).

  • People don’t care about how much charge the battery has; only care about how long will it last.

  • Battery got virtual charge, basically the mobile device is doing less work, so it will last longer.

  • Reason for virtual charge: entry into a smart space (good candidates: airports, bus stations, …etc)


Outlines

  • Vision

  • Motivation and Statement of Problem

  • Review of Proposed Research

  • Post-Proposal Accomplishments

    • Extended review of related work (Grid Computing)

    • Extended Pseudo-parser to handle a wider range of language constructs.

    • Extended benchmarks for deeper validation of proposed approach.

    • Created the runtime support.

  • Experimental Validation

  • Conclusion and Future Work


Motivation

  • Increased reliance on and capability of mobile devices.

    • Laptop computers, handhelds, cell phones, and even MP3 players.

  • Convenience – The less often I charge the battery the better.

  • Mobility. The longer a mobile device is plugged into the electricity to charge, the longer it is considered an immobile device.

  • Contingency – If we have limited power and we have a must finish important task.


Advancements in Battery Technology: Slow

  • Battery technology does not follow Moor’s Law.

  • Becomes a bottleneck for mobile computers.

  • Solutions must accommodate the slow advancement.


Advancements in Mobile Technology (Laptops)Can extrapolate to PDAs and cellular phones


Outlines

  • Vision

  • Motivation and Statement of Problem

  • Review of Proposed Research

  • Post-Proposal Accomplishments

    • Extended review of related work (Grid Computing)

    • Extended Pseudo-parser to handle a wider range of language constructs.

    • Extended benchmarks for deeper validation of proposed approach.

    • Created the runtime support.

  • Experimental Validation

  • Conclusion and Future Work


Related Work

  • Solutions have fallen into three categories:

    • Hardware and Architecture Level

    • Operating Systems Level

    • Application Level

  • Often involve some sort of a trade-off.


Related Work

  • Hardware Level

    • Smart Battery System

    • Energy-Aware Processors

    • Reducing Energy through the CMOS

      • Voltage

      • Frequency

      • Capacitance Load

  • Architecture design

    • Always need additional hardware components (e.g. additional cache).

    • Often augmented by a compilation strategy.


Related Work

  • Operating System

    • APM (Advanced Power Management)

    • ACPI (Advanced Configuration and Power Interface)

    • Memory management

      • Stay on-chip as much as possible

      • Reduce I/O

    • Communication techniques

      • Buffering when sending and receiving

      • Suspend and Resume based on communication patterns Scheduling (Analyze energy usage via monitors) and schedule accordingly (adjust CPU clock speed)


Related Work

  • Software Techniques

    • Application-Specific

      • Power-Aware APIs

    • Compiler based

      • Instruction Re-ordering (to reduce logical state transitions) Reduce memory operands (register allocation)

      • Code generation via pattern matching (the metric used is a power metric instead of a performance metric).

      • Remote task execution


Defining the Approach

  • This is a two part approach

    • Compile-Time Solution

      • Determine maximal CPU blocks (loops)

      • Collect Loop data (all variables)

      • Generate two versions of the program

        • Client – Install on mobile device

        • Server – Install on a surrogate server

    • Run-Time Support (Proposed)

      • Program will run in a pervasive computing environment.

        • Computation outsourcing

      • Battery monitor (includes user preference)

      • Network monitor to locate registered surrogate servers


Advantages of Approach

  • Compile-Time solution – minimal programmer power awareness required.

  • Fine Granularity solution – Looks at CPU blocks as opposed to pre-defined tasks.

    • Reduce the chance of missing energy saving opportunities.

  • Works well within a pervasive computing environment with very little run-time overhead.

  • A very good start to generalizing a compile-time strategy to outsource computation for energy saving.


Computation Outsourcing Framework


Run-time Client/Server Interaction


Compile-Time Optimization


Energy Optimization Pre-Processor

  • Identify the maximal CPU blocks (Loops)

    • Collect variables

    • Collect loop boundaries.

  • Calculate the number of loop iterations Calculate the Size of Loop Data

  • Identify loop instructions.

  • Insert outsourcing code on the client side prior to every loop.


Energy Optimization Pre-Processor

Generating the Server file:

  • Insert a while loop that is waiting for requests

  • Each request is designated by a loop to be executed.

    • Code for each loop is inserted

  • Upon receiving a request

    • Wait for data to be sent by the client

    • Execute the loop

    • Send the results back.


Initial Measurements and Results

  • Setup:

    • Sharp Zaurus (SL-5600) (PXA 250)

      • Running Embedded Linux.

    • Metrowerks Codewarrior to develop for the Zaurus.

    • Agilent Technologies 34401A multi-meter

      • Agilent Intuilink software to record measurements.

    • Linux machine running RH 7.2 was our surrogate server.


Initial Instruction-Level Energy Cost Estimation.

  • Measure the cost of an empty loop

  • Insert several instances (100) of a single instruction within the loop

  • Subtract the difference in energy which will result in the cost for the 100 instructions. Average the cost to get the per instruction cost.


Initial Instruction-Level Energy cost estimation.

Empty for loop

The ldr instruction within a loop

Subtract the cost of the empty for loop from the cost of the same loop containing the instruction


Initial Experimental Results

Matrix Multiplication

Bubble Sort


Outlines

  • Vision

  • Motivation and Statement of Problem

  • Review of Proposed Research

  • Post-Proposal Accomplishments

    • Extended review of related work (Grid Computing)

    • Extended Pseudo-parser to handle a wider range of language constructs.

    • Extended benchmarks for deeper validation of proposed approach.

    • Created the runtime support.

  • Experimental Validation

  • Conclusion and Future Work


a) Grid Computing

  • Looks very applicable to this research.

    • RPC/RMI

    • Mobile Agent technology

  • However, target problem size in Grid computing is significantly larger.

    • This research does not target such problems.


a) Grid Computing (continued)

  • Grid computing requires a middleware such as the Grid computing environment (GCE).

    • This will consume energy.

      • This is why Mobile Agent technology is questionable.

    • Our middleware (battery and network monitors) are simplistic.

  • Geographic Location


b) Extensions to Pseudo-parser

  • Must communicate with the battery and network monitors.

  • Extended benchmarks contain larger language capabilities. No longer just simple data types (int, float, char, …etc)

    • Must support structures.

  • Support library function calls.

  • Support multi-dimensional arrays.

  • I/O Function Recognition.


Communication with Monitors

  • At start of application:

    • Check the existence of a configuration file

      • If it doesn’t exist, execute in normal mode.

      • If it exists (energy-saving mode):

        • Open the file and take a look at the configuration

        • Connect to the listed server as it will be the surrogate.

      • Any error caused by: opening the file, reading it, or connecting to the server, will result in running in normal mode.


Support for Structures.

  • Recognize:

    • typedef struct {…} newType;

  • Insert the type in the type table.

    • Assign a size to the new type.

  • When a variable is declared of the new type:

    • Insert the variable in the symbol table and assign it its size.

  • When a variable of the new type is used, only collect identifiers up to the first ‘.’ operator as that is the only identifier of interest (e.g. in x.y.z[10].w, x is the only identifier that we need since it’s the variable name).


Support for Library Functions

  • Prior to recognizing in pseudo-parser, benchmarking was necessary.

    • Utilize the same approach used for instruction benchmarking (place multiple calls of the function within a loop)

  • Recognize expressions of the form:

    • <variable> = <function>(arg. list);

      • x = sqrt(y);

  • Once recognized, add the cost to that of the loop’s.


Support for Multi-dimensional Arrays.

  • Mainly 2-D arrays.

  • Support was built to handle

    • Arrays of structures

    • Structures of arrays

    • Arrays within structures.

  • Associate 3 Sizes with each array

    • Base size (e.g. sizeof(int))

    • Size of first dimension (-1 if it’s not an array)

    • Size of second dimension (-1 if it’s a 1-D array)


I/O Function Recognition

  • I/O function recognition is necessary to avoid outsourcing I/O loops.

  • C has a list of commonly used I/O functions (scanf, getchar, printf, putchar, … etc).

  • Recognize them and ignore everything following them until you reach the ‘;’

    • Once recognized within a loop, flag the loop non-outsourceable.

    • If the loop is nested, flag all loops enclosing it non-outsourceable as well.


The new pseudo-parser


c) Benchmarking

  • Initial Benchmarks: Bubble sort, and matrix multiplication demonstrate fine granularity.

  • Extended Benchmarks:

    • 3-D graphics rendering application

      • (Medical Imaging, Gaming, Graphics Design, and Scientific Computing)


Input

Screen Size

Ambient Light

Viewport

Observer:

Eye(Camera)

Background

Light

COI

Hither/Yon

View angles

Sphere 1

Sphere 2

Sphere 3


Output


d) Runtime Support

  • Battery Monitor

    • User-specified behavior

      • Automatic (look at remaining % of battery life)

      • User-control

        • Decide when to go into energy saving mode.

      • Based on battery condition, may or may not get out of energy saving mode.

      • User may decide to go into normal mode.


d) Runtime Support (continued)

  • Network Monitor:

    • Works only if energy saving mode is selected.

    • Send out a broadcast for service discovery and wait for a response back.

    • Once response is received, the surrogate server has been determined.

    • Build a configuration file indicating that energy-aware applications can run in energy-saving mode.


d) Runtime Support (continued)

  • Surrogate Service Discovery Server

    • Wait for requests for service

    • Determine the client looking for service.

    • Send back server information and indicate readiness for service to the client.

    • Wait for requests.


Outlines

  • Vision

  • Motivation and Statement of Problem

  • Review of Proposed Research

  • Post-Proposal Accomplishments

    • Extended review of related work (Grid Computing)

    • Extended Pseudo-parser to handle a wider range of language constructs.

    • Extended benchmarks for deeper validation of proposed approach.

    • Created the runtime support.

  • Experimental Validation

  • Conclusion and Future Work


Experimental Validation

  • Reran the simplistic benchmarks used before.

  • Generated results for the 3-D application using: 50x50, 100x100, and 200x200 images.

  • Generated the energy cost estimate for the network and battery monitors (they add to the energy consumed by the system).

    • Negligible cost.


Energy comparison for generating a 50x50 image

Local: 1.2 minutes

Approx. 66 Joules

Remote: 2 seconds

Approx. 4 Joules


Energy comparison for generating a 100x100 image

Local: 4 minutes

Approx. 240 Joules

Remote: 4 seconds

Approx. 4 Joules


Energy comparison for generating a 200x200 image

Local: 17 minutes

Approx. 1020 Joules

Remote: 7 seconds

Approx. 4 Joules


Measuring the energy cost of the monitors


Additional Measurements

  • Compile-time

    • Energy optimization adds 1-2 seconds for simple benchmarks, 5-7 seconds for more complex benchmark.

    • Compiling the code will double the effort as now we’re compiling 2 files instead of 1.

  • Size of the executable:

    • 3-5 times larger for simple benchmarks as the inserted code is more than the original code.

    • Only 40% increase for the complex benchmark as the inserted code is smaller with respect to the size of original code.


Outlines

  • Vision

  • Motivation and Statement of Problem

  • Review of Proposed Research

  • Post-Proposal Accomplishments

    • Extended review of related work (Grid Computing)

    • Extended Pseudo-parser to handle a wider range of language constructs.

    • Extended benchmarks for deeper validation of proposed approach.

    • Created the runtime support.

  • Experimental Validation

  • Conclusion and Future Work


Conclusion and Future Work

  • The energy dissipation problem in mobile devices is very important and needs to continue to be addressed.

  • Due to the increased capability of mobile devices, outsourcing computation within pervasive smart spaces is beneficial.

  • Our experimental validation showed significant gain using the computation outsourcing methodology.


Conclusion and Future Work (continued)

  • Useful information about behavior of the program can be obtained via high-level source code analysis.

  • Research such as real-time systems as well as automated software verification are useful in this line of research.

    • They increase the knowledge about the behavior of the software prior to execution.


Conclusion and Future Work (continued)

  • As part of our future work:

    • Currently we’re looking at applying our approach to power-aware query processing for PDAs.

    • Investigate further enhancements and implementation to augment our work:

      • RMI and RPC Support.

      • Port this work to C++ and Java

      • Investigate Mobile Agent technology as it applies to this work.

      • Look into other types of CPU blocks such as entire function (recursive and non-recursive)


Summary of Contributions

  • Identified and investigated an avenue for conserving energy in mobile devices via utilizing computation outsourcing in pervasive smart spaces.

  • Realized that utilizing areas such as real-time systems could benefit energy-saving in mobile devices by providing a priori knowledge of program behavior.

  • Showed that analyzing a source program at its various representations (low, intermediate, and high) and combining the analysis is very beneficial to predicting its runtime behavior

  • Developed a compile-time, fine-grain solution to benefit from computation outsourcing to save energy in mobile devices.

  • Validated the results of the investigation experimentally.


Publications

  • A. Abukmail and A. Helal, “Power Awareness and Management Techniques”, M Ilyas and I. Mahgoub, Editors, Mobile Computing Handbook, CRS Press, Boca Raton, FL, December 2004, pp. 731-743, ISBN 0-8493-1971-4.

  • A. Abukmail, and A. Helal, “A Pervasive Internet Approach to Fine-Grain Power-Aware Computing”, Proceedings of the IEEE/IPSJ International Symposium on Applications and the Internet (SAINT), Phoenix, Arizona, January 2006.

  • A. Abukmail, and A. Helal, “Energy Management for Mobile Devices through Computation Outsourcing within Pervasive Smart Spaces”, To be submitted to IEEE Transactions on Mobile Computing.

  • A. Abukmail, A. Helal, and someone else “Power-Aware Query Processing through Computation Outsourcing”, In progress.


Thank you very much


Questions?


  • Login