Pervasive Computing Approach to Energy Management

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.