1 / 55

Pervasive Computing Approach to Energy Management

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)

huyen
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pervasive Computing Approach to Energy Management PhD Dissertation by: Ahmed Abukmail 11/18/2005

  2. 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

  3. 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.

  4. 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)

  5. 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

  6. 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.

  7. 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.

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

  9. 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

  10. 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.

  11. 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.

  12. 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)

  13. 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

  14. 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

  15. 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.

  16. Computation Outsourcing Framework

  17. Run-time Client/Server Interaction

  18. Compile-Time Optimization

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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

  24. Initial Experimental Results Matrix Multiplication Bubble Sort

  25. 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

  26. 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.

  27. 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

  28. 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.

  29. 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.

  30. 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).

  31. 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.

  32. 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)

  33. 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.

  34. The new pseudo-parser

  35. 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)

  36. Input Screen Size Ambient Light Viewport Observer: Eye(Camera) Background Light COI Hither/Yon View angles Sphere 1 Sphere 2 Sphere 3

  37. Output

  38. 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.

  39. 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.

  40. 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.

  41. 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

  42. 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.

  43. Energy comparison for generating a 50x50 image Local: 1.2 minutes Approx. 66 Joules Remote: 2 seconds Approx. 4 Joules

  44. Energy comparison for generating a 100x100 image Local: 4 minutes Approx. 240 Joules Remote: 4 seconds Approx. 4 Joules

  45. Energy comparison for generating a 200x200 image Local: 17 minutes Approx. 1020 Joules Remote: 7 seconds Approx. 4 Joules

  46. Measuring the energy cost of the monitors

  47. 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.

  48. 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

  49. 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.

  50. 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.

More Related