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 components 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
• 110 seconds works well
• But user delay increased (830 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 disks 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.150.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 (Ccapacitance, Vvoltage,
  ffrequency)
• 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?