Power Considerations in Mobile Devices

1. Power Considerations in Mobile Devices

2. Discussing two Papers • Every Joule is Precious: The Case for Revisiting Operating System Design for Energy Efficiency, Vahadat et al, 2000 • Software Strategies for Portable Computer Energy Management, Lorch and Smith, 1998 • Both these papers are high level “position” papers discussing approaches/opportunities for energy management

3. Battery power as a managed resource • Little change in basic technology • store energy using a chemical reaction • Battery capacity doubles every 10 years • Energy density/size, safe handling are limiting factor • Other: Li Ion 0.16, NiCad 0.05, NiMH 0.07 • Other factors: energy/size, energy/$, recharge cycles, operating conditions, recharge time...

4. Energy Management Opportunities Energy consumed = time * power • Application: Can reduce consumption by changing the application demands and allowing lower modes to be used • OS: The OS can reduce energy consumption by reducing the time spent in high energy consumption states • HW: Hardware can reduce energy consumption by reducing the power consumed by high energy consumption states

5. Hardware advances • Lower power CPUs • disable idle units in CPU to save power • e.g. transmeta crusoe chip • Architecture group at BU • lower clock frequency to conserve battery • e.g. intel speedstep • Lower voltage levels • Displays • active matrix LCD • reflective displays (uses ambient light for lighting) • Memory • RAMBUS RDRAM provides various power modes • Batteries not constant source of power • pulsed mode is better

6. Example -- RDRAM

7. Discussion • Is it better if my computer consumes energy at a slower rate? • Rate of consumption of energy, or total energy consumed? • Balance between power and responsiveness?

8. Categories of Energy Related Software Problems (Lorch) “Hardware features not enough – need software that takes advantage of them” • Transition: when should a component switch between modes? • Load-change: how can a component’s functionality be modified so it can be put in low-power modes more often • Adaptation: how can software permit novel, power-saving uses of components • For each component, how do we come up with such policies? • Who controls? End-to-end principle?

9. Power consumptions for various Mobile computers (Lorch)

10. Disk Characteristics • Five power modes • Active: seek, read, write on • Idle: no seek, read or write, but motor spinning platter • Standby: only controller is on • Sleep: interface is off, cache off, but can detect reset signal/new requests • Off

11. Battery power - disk • Problem: • disk spinup,seek/flash memory erase costs (power values for IBM travelstar) • Predictive spin-ups • Caching/prefetching

12. Other Disks

13. Policies for Disks • Transition strategies: mostly, when to go to sleep, standby or off modes • Sleep mode most common strategies • Less power than standby • Standby relatively new • Transition cost is similar (spin-up dominates) • Fixed inactivity threshold • 1—10 seconds works well • But user delay increased (8—30 sec per hour) • Stop – start behavior shortens disk lifetime • Dynamic threshold and Access prediction have also been tried

14. Load change disk policies • Can we change the disk’s workload? • Increase disk memory cache • Up to 50% savings in power by increasing cache size (if the cache size was small) • Increase dirty block timeout value • Also 50% gain going from 0 to 30s • Prefetching (in conjunction with spin down?) • Similar to hoarding/disconnected operation in CODA • Reducing paging activity

15. Adaptation Strategies • Several discussed, for example: • Use wireless network as a disk • Disk can be on plugged in server that is fast and power hungry • Client gets data over the network instead of paying for the disk cost • Remember broadcast disks? • What do you think of this idea? • Discussion

16. Also, Flash RAM is used • Non-volatile memory that does not consume energy while storage • Energy consumed when reading/writing 0.15—0.47 Watt; much better than disk • Speed of reading 85ns (close to DRAM), but for writing it is 4-10 micro second per bytes (much slower than disk) • Cannot erase a byte: full segment at a time -- expensive (time, power). Also, can only erase a limited number of times before it breaks • Cost is high

17. Processor • Power = C V2f (C=capacitance, V=voltage, f=frequency) • Lower power can be obtained by: • Reducing V or f (but there are limitations) • Turning off portions that are not in use • Resizing some portions (e.g., register file) • Using less power hungry architectures • Turn the CPU off… • Transition strategies: when to turn CPU off? When to change speed/voltage? When to resize components?

18. Load change approaches • Can we change the load demands of processes on the CPU? • Reducing times taken by tasks • Using low power instructions • Reducing the number of tasks • Energy aware OS and compiler • Eliminating “busy waiting” to enable more transitioning to standby state

19. Battery power - memory • power aware memory hierarchy - e.g. Rambus (power values for 128 Mb PC800 RDRAM) • each chip can be put into different power modes • Initial page placement, power transition, page migration

20. Battery power - network • Transmit, listen, idle costs (power values for Lucent wavelan 2 Mbps) • Power consumed when device is active • Receiver does not know when sender has data to be sent - continuous wait is expensive • Transmission power often constant

21. Display and Backlight • Major consumers of power, but.. • Few energy saving features: • Reduce backlight intensity • Turn display off • Reduce refresh rate (reduces colors…) • Can think of transition strategies along these lines • What about load change strategies?

22. Discussion • Common theme: need external control of mode transitions • Agree with Vahadat about importance of OS support for power as a first class commodity

23. Battery power – application level • Application aware adaptation to manage high power energy states • Managing the power states in a palm • Managing battery in a digital camera using image transcoding • Application level adaptation to manage energy • Client/server computation split

24. Hypothesis: OS should manage power • Typical Operating Systems are designed to hide latency (caching), fairly share resources (CPU, memory, network, etc.) • What about power? If two processes are runnable and one is expected to consume more power, which do you run? • Do you run cleanup daemon when the battery power is low?

25. OS Support

26. Discussion

27. Third paper • Quantifying the Energy Consumption of a Pocket Computer and a Java Virtual Machine • Keith Farkas (DEC WRL), Jason Flinn (CMU), Godmar Back (Univ. of Utah), Dirk Grunwald (Univ of Colo. Boulder), Jennifer Anderson (Vmware) Energy consumed (Joules) = time * power consumed (Watts)

28. Goals • Energy usage characteristics of the Itsy • Itsy is a prototype PDA built at DEC (Compaq) SRC • 200 MHz StrongARM SA-1100 microprocessor • 320x200, 0.18mm, 15 level gray scale display • Touchscreen, microphone, speaker, serial and irda • 64MB RAM, 32MB flash • 2 AAA battery • Precursor to the iPAQ

29. Itsy

30. Itsy battery power tricks • Can change the CPU clock to 206 MHz, 133 MHz and 59 MHz) • It can scale the voltage to 1.5V and 1.23V • 30 minutes in high power mode • 2 hours in high power “Idle” mode • 18 hours in low power (59 MHz) Idle mode

31. Comparison between Itsy and laptop • Compared Thinkpad (233 Mhz, 64 MB) and Itsy • Laptops consume a lot more overall power • Itsy allows more power states • Certain subsystems have lot higher relative power costs (because other systems consume less power) • E.g. on a laptop • 68% - display, 20% - disk, 12% CPU and memory • Itsy consumes less for display, but adding a backlight has a much higher relative cost • Memory subsystem has impact on Itsy

32. JVM • Java Virtual machine • Interesting to look at Java on a PDA because it is simpler to expect apps to be downloaded to the PDA than expect them to be installed all the time • Looked at the power characteristics of: • Single JVM vs multiple JVM • Compressed vs Uncompressed class files • Class loading vs JIT compilation • Cache flushing after code generation

33. Results • Single JVM less power than multiple JVM • Reliability issues • Compressed vs uncompressed class files: not much difference • Class loading vs JIT Compilation • Preloading works, but have to be careful on what to preload • Cache flushing after code generation • Little impact; only 16 KB I and 8KB D cache • Interpreting and JIT • JIT has dramatic gain; maybe because of KAFFE for JVM • AWT polling frequency – slight difference

34. Discussion • Power consumption has to be investigated closely for each underlying architecture • There are few “generic” tricks for every hardware • What is the view point of the three different papers? How are they related to each other?