Power Modeling for Smartphones Based on paper and presentation by: Abhinav Pathak, Y. Charlie Hu, Ming Zhang Paramvir Bahl, Yi-Min Wang Damian Rodziewicz
Smartphone Capabilities
Smartphone Capabilities Camera
Smartphone Capabilities Camera GPS
Smartphone Capabilities Camera Wi-Fi GPS
Smartphone Capabilities Camera GPS Wi-Fi Games and applications
Smartphone Capabilities Camera GPS Wi-Fi Games and applications
Smartphone Constraints Energy one of the most critical issues in smartphones. Smartphone capabilities are growing rapidly. Battery capacity has only doubled through 10 years. "According to unpublished research by the Boston Consulting Group, the amount of energy that a battery can store (its energy density) is growing by 8% a year. Mobile-device power consumption, meanwhile, is growing at more than three times this rate, as backlit colour screens, high-speed wireless networks and more powerful microprocessors draw ever-larger amounts of power."
Key issue How can we measure energy consumption in our applications? Power meter Online power models for mobile devices Utilization-based power model System call tracing power model
Measuring Energy Consumption Power meter High cost (~700$) Requires performing surgery on your phone Only whole energy usage Stationary cannot move with Very accurate (every 200 ms exact power usage)
Online power model Źródło: http://eurosys2011.cs.uni-salzburg.at/pdf/eurosys2011-pathak-slides.pdf
Utilization-based approach State-of-art creating model Energy usage Ep = Energy used by 1 second of processor En = Energy used by 1 packet of data sent Ed = Energy used by writing/reading 1 byte same for GPS, camera, and so on...
Utilization-based approach State-of-art predicting Read data every second (something like proc in Linux): %Up = % of used Processor Nn = number of packets sent Nd = number of bytes read / written Result = %Up * Ep + Nn * En + Nd * En
Utilization-based approach State-of-art wrong assumptions Active utilization is the only trigger of power state change File open/close, socket open/close also consume energy Several components have tail energy states (even few seconds) Linear estimation Sending 100 packets does not cost 2 as much energy as sending 50 Quantitative utilization Cannot measure energy consumption of camera / GPS The interval can be too large to collect data, or the sampling can become too costly, if done at fine granularity.
Utilization-based approach Examples of power usage Źródło: http://eurosys2011.cs.uni-salzburg.at/pdf/eurosys2011-pathak.pdf
Observations System calls provide the only means via which applications gain access to the hardware (I/O) components. Names and parameters give clear indication of components and level of utilization. (Encapsulation of utilization-based approach) System call can be naturally related back to the calling subroutine and the hosting thread and the process.
Problems Tail energy states How much do they consume? How long do they last? Device drivers are closed source (no source / no information given). Power consumption does not add linearly. Energy does not scale linearly.
Problems non linear additivity
Problems non linear scalability
Idea Use system calls as triggers in power modelling. Reverse engineer power logic in device drivers. Use Finite-State-Machine (FSM) to model the power states and transitions between them in components. Nodes: Power States (Either productive state or tail state) Edges: Transitions between states Can be system call, timeout, other condition. We assume that these drivers implement very simple logic We use Linear Regression to connect workload with power usage in states.
Creating FSM Create an FSM for one system call. Model all system calls for one component. Shuffle the system calls in a C program, look for new power states. Model one huge FSM for the phone from the components.
Finite State Machine step 1
Creating FSM step 2 - Wi-Fi
Creating FSM step 3
Combinatorial issue Usualy one component has about 2 productive states and 1 tail state. It is done manually at this time. Applications are run, FSM models are created. States are binded together manually. Soon the process will be automated.
Evaluation CPU, Disk, Wi-Fi
Evaluation Entire Phones
Implementation Tracing system calls in whole phone, to predict energy usage. Windows Mobile 6 CeLog logging mechanism for CPU, memory, TLB, interrupt. Wrappers that log system calls in libraries. Thunking system call made to invalid address prefetch abort trap. Android Three levels kernel, Dalvik Virtual Machine, framework. SystemTap logging system calls in kernel. Logging library from Android to log framework calls.
Implementation - Eprofiler Currently being worked on. Mannualy annotating system calls in the source code to log the entry and exit points.
Estimation
Estimation
What is next? Implementing eproof Releasing modified Android image to public Releasing tools for Android to predict energy usage Detailed classification of power behaviour of different OSes and handsets
Thank You