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 1.Active: seek, read, write on 2.Idle: no seek, read or write, but motor spinning platter 3.Standby: only controller is on 4.Sleep: interface is off, cache off, but can detect reset signal/new requests 5.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? 1.Increase disk memory cache  Up to 50% savings in power by increasing cache size (if the cache size was small) 2.Increase dirty block timeout value  Also 50% gain going from 0 to 30s 3.Prefetching (in conjunction with spin down?)  Similar to hoarding/disconnected operation in CODA 4.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 V 2 f (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: 1.Reduce backlight intensity 2.Turn display off 3.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 1. 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?