Less is more, system level software centric power analysis
AchimNohl
quality criteria for this software. According to Google, a simple
application that is waking up the phone every ten minutes for only 8
seconds is cutting the standby time of the phone, which would be
sleeping otherwise, to 50% [Source: Google, Youtube, „Coding for
life“, 2009]. A fifty percent reduction of the stand-by time just by a
single software module! It becomes obvious that with the numerous
layers of the Android software stack and the multitude of software
processes, energy management becomes a huge software challenge. The
underlying hardware often provides extensive power management
capabilities to the software such as shutting off parts or allowing
dynamic frequency and voltage scaling. However, it is key that those
features are vertically integrated in the software stack to get
controllable by the power management software modules. The kernel and
drivers need to support idle-standby, deep sleep, LCD backlight
control, modem power control etc. to the hardware adaptation layer
(HAL). The HAL need to integrate and support those services for the
Java layers (Native and Application). This way the Android power
management heuristics in the middleware can get to work such as dim
down the LCD after 30 seconds and go to deep sleep after two minutes.
The Android power management extends the Linux power management with
various features such as wake-locks. This way, the application
developer can prevent the ARM going suspend, or the LCD brightness
going to 50%. These wakelocks have to be used carefully, as not
releasing them by accident would have a tremendous impact on the
battery. Also the way software is implemented impacts power. Using
active waits instead of passive waits would change the CPU load from a
50% average to 100% and doubling the power consumption. However,
altogether the CPU consumes ~20% of the power in a typical usage
scenario where the LCD is bright, 3G modem and GPS is on according to
Google. Thus, from a software perspective, it is all about optimizing
the power control of components for such usage scenarios. Therefore,
it is important to measure and power during those scenarios. Here, it
needs to be measured which component is consuming what amount of
energy. For the analysis, one need to know at which time that happens
(e.g. after the modem goes on), and based on what software action
(e.g. because periodic software access to the internet). Second, after
changing the software it is important measure the impact of the
changes on power. To enable this comparison, it is required that
scenarios can be repeated in a deterministic way.
In the coming days I will post information on how Virtual Platforms
can be used to analyze and optimize power from a software centric
system level stand-point.
AchimNohl
consumption over time and per component. The measurement is performed
using a characterization of either software functions (such as idle,
non-idle) or components (frequency, state) with power levels. The
characterization is under control of the user and performed using the
Virtual Platform TCL scripting interface. Here, power formulas
implemented in TCL can be registered with events in hardware and
software that trigger a state change. The overall power level is
traced and can be further analyzed., The entire power analysis has
been enabled on an end-user level solely using VP TCL scripting
without any changes of the Virtual Platform model or tools. The
mechanisms are the ones discusses in this group earlier such as
watchpoint triggers, callback functions and tracing views.
I have recorded a quick screenscast showing the power analysis
framework analyzing an Android Boot. The items of interest in this
‘demo’ are just the CPU’s and backlight-lcd’s contribution to power:
http://screenr.com/lOg
I am planning to explain more about how the power analysis framework
is working as well as give examples for meaningful real-life use-cases
(e.g. Comparing the tickless Linux kernel vs. a ticking kernel,
analyzing Android applications etc.)
It is important to understand that the framework is targeting the
software developer to understand the software impact on power.
Therefore, the numbers should be used for relative trend based
optimization and should not be considered as accurate in terms of
absolute power numbers. The capabilities provided by the framework
target to implement and analyze software power optimizations such as
described in LessWatts.org. It is not the goal of the framework to
provide accurate numbers for making architectural design decisions. Of
course, the more fine granular the characterization is, the more
accurate the absolute number will get. But, the focus of this
framework is on the components that are under control of the software.
Next to the measurement, the software developer can control scenarios
to stimulate the Virtual Development Board. This can be done by
providing stimuli via the board interfaces such as UARTs, GPIOs,
Keyboard, Touchscreen, Ethernet. In case of a Virtual Platform those
interfaces are controllable via APIs as well as a commands available
on the Virtual Platform scripting shell. This way a car-driving
scenario can be created as the modem connected to UART 1 is signaling
cell changes, and the GPS is updating location information via UART 2.
As said, more information and examples to come.
Best regards,
Achim
AchimNohl
tickles kernel. In this post we will evaluate the impact of this
feature on power savings for an Android based phone. A Qualcomm
presentation lists the tickless kernel as one suggestion for power
saving " Tips: Use tickless kernel and deferred timers" [http://
www.docstoc.com/docs/25349111/Microsoft-PowerPoint, Linux World 2008]
Controversy opinions which I have found on the web about this feature:
"The tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer
interrupts: if there is no timer to be expired for say 1.5 seconds
when the system goes idle, then the system will stay totally idle for
1.5 seconds. This should bring cooler CPUs and power savings” [http://
kerneltrap.org/node/6750]
“By not having a regular timer tick when the processor is idle, it is
theoretically possible to have really long periods of idle as long as
there are no future timers planned. Unfortunately, in practice in a
current Linux distribution, both the kernel and userspace applications
set so many timers that it is not uncommon to have 500 or more of such
events per second. The system can go to one millisecond sleep time to
an approximately two millisecond sleep time. This would obviously
provide only minimal power gain over the kernel with the regular tick.
[ “Absolute Power”, Arjan Van De Ven, Intel
http://software.intel.com/sites/oss/pdfs/absolute_power.pdf]
Which opinion does now apply to our Android software stack and with
its own dynamics?
In order to evaluate what the tickles feature delivers for Android, we
will analyze the power trace during phone idle scenario. Phone idle:
No user is interacting with the phone and no application has been
launched by the user. How does the tickless kernel impact the power
consumption during this idle time? We select an idle period using a
tickless (1) and ticking (2) kernel.
Tickless:
i_ARM926EJS_0> calc_energy_from_selection 1
Power analysis for graph 1:
Consumed energy total : 1041.0 uWh
Average power total : 325814.08966 uW
Average time to empty with full battery: 16.5738688761 h
Details:
Consumed energy POWER_CPU : 1.86233333333 uWh
Average power POWER_CPU : 582.876503019 uW
Peak power POWER_CPU : 200000.0 uW
Consumed energy POWER_BACKLIGHT_LCD : 1038.39892361 uWh
Average power POWER_BACKLIGHT_LCD : 325000.0 uW
Peak power POWER_BACKLIGHT_LCD : 325000.0 uW
Ticking:
i_ARM926EJS_0> calc_energy_from_selection 2
Power analysis for graph 2:
Consumed energy total : 1100.0 uWh
Average power total : 325657.653707 uW
Average time to empty with full battery: 16.5818304546 h
Details:
Consumed energy POWER_CPU : 2.413 uWh
Average power POWER_CPU : 714.374471269 uW
Peak power POWER_CPU : 200000.0 uW
Consumed energy POWER_BACKLIGHT_LCD : 1097.77859028 uWh
Average power POWER_BACKLIGHT_LCD : 325000.0 uW
Peak power POWER_BACKLIGHT_LCD : 325000.0 uW
As you can see, during phone idle, the CPU power consumption is
negligible if the LCD is still turned on (here full bright). But, the
CPU shows only 30% less power consumption in the tickles mode! This is
a surprise, as we would expect the CPU being almost 100% idle.
However, this is not the case as can be seen in the frequent wake-ups
during idle in the tickles graph. These wake-ups are a known problem
with multi-tasking operating systems and mobile devices and a result
from the fact that often user space applications in the background
have timers to periodically perform certain tasks.
“…Many desktop programs behave very badly and have a large number of
timers that aren't really needed. The most frequent scenario is that
code polls for something, but could simply opt for an event if the
programmer had bothered. In defense of the user-space programmers,
until the kernel went tickless, this behavior not only was not
affecting the system negatively, it wasn't even possible to see what
was happening.
The environment has changed with the tickless kernel. Programs that
poll frequently hurt power consumption.”
[ “Absolute Power”, Arjan Van De Ven, Intel
http://software.intel.com/sites/oss/pdfs/absolute_power.pdf]
This quote also seem to hold true for our scenario. In order to
optimize the CPU power consumption, it needs to be determined which
application wakes up the CPU and how often this happens. I will show
how-to do this in the next post.
The result is interesting: It is the battery dis-charging animation
that wakes up the phone every second and prevents the tickless kernel
from doing power saving:)!
AchimNohl
I want to follow up on our analysis of the tick-less kernel for
Android. As posted earlier, we did not see an impact of the tick-less
kernel vs. the ticking kernel during idle. We would have expected that
when the phone is idle, the tick-less feature could fully exploit its
capabilities. Now, we have to find out why that has not been the case.
In my earlier post you can read similar analysis reports e.g. from
Intel, but in a different application domain. We want to get clarity
on Android, and this is pure debugging. However, we are not looking
for a functional defect but a power efficiency problem. Thus, we do
record a context trace (OS processes), to see if the CPU is in low-
power idle mode and if not, what makes it wake up. I have put the
screenshot of the trace here:
http://virtual-platform-users.googlegroups.com/web/android_idle_analysis.png?hl=en
In the upper half of the screenshot we see the analysis of OS
processes over time. Each row corresponds to a different process and
the blue markers show when the process is active or not. In a ticking
kernel we would observe a 1Khz timer via the process “kernel/irq”
being fired 1000 times per second (timer interrupt). This is not the
case, thus obviously the tick-less thing is working. However, we get
regular wakeups from idle at least 2 -3 times a second. Thos wake-ups
are coming from the user-space software where software timers are
running to e.g. process and update things. E.g. have a look at the
ServerThread process. It is waking up the CPU in a periodic fashion
which indicates a software timer. This process in coming from the
internals of Android, and we have no clue what it is doing and why.
We could choose to re-compile this process with more debug and verbose
information, but this would distract our measurements. E.g. if we add
logging we will impact the scheduling of processes, but this is what
we want to analyze. Thus, we ideally want to get more details in a non-
intrusive fashion. This is possible using Virtual Platforms. In our
case I have chosen to log what is going in within the Dalvik Virtual
Machine, e.g. show which Java functions are called, which Java
processes are doing what etc. You can see the results in the lower
half of the window. I have simply created a trigger at the function in
the VM that handles a Java function call and hijacked the string
function name from memory (see also
http://groups.google.com/group/virtual-platform-users/browse_thread/thread/ca7f4b60fc001043,
I will add the info for this Dalvik VM trace soon).
My Virtual Platform log messages have a time-stamp and are fully
synchronized with the rest of the analysis data. We can nicely see in
the dots of top-most row that logs are created when the CPU is woken
up from the serverthread. If we focus such a dot, the time-cursor will
adjust and we see my message below “dvmObjectWait: Landroid/os/
MessageQueue” (here: VM function: Java object). It indicates the Java
object is woken up. In the following messages we see the Java
functions that are called in the object Landroid/graphics/Paint etc.
Now it is an easy step to open the source-code of the serverthread and
relate that to the update method for the battery statistics (not shown
here). Now we can go and decide to play around with different update
intervals and evaluate what that does to power or user-experience. The
dynamics of such a complex SW stack are full of surprises and the
effect and causes not always logical as we have seen with the tickless
kernel. A Virtual Platform enables you to understand the dynamics.
AchimNohl
I still wanted to comment on the instrumentation that is required for
the system level, software centric power analysis.
Our Virtual ARM Development Board in the cloud allows to measure
energy consumption over time and per component. The measurement is
performed using a characterization of both software functions (such as
idle, non-idle) and components (frequency, state) with power levels.
The characterization is under control of the software developer and
performed using the Virtual Platform scripting interface. Here, power
formulas implemented in TCL can be registered with events in hardware
and software that trigger a state change. The overall power level is
traced and can be further analyzed as discussed earlier.
The user has the ability to register power formulas which get computed
on either a hardware a software event. A hardware event can be a
signal or register change such as the GPIO output that drives the LEDs
is changing. A software event can be a breakpoint on a function such
as the CPU idle function in Linux. Thus the overall power of the
system at a moment in time is defined through the result of the user’s
power formulas. The consumed energy is computed by measuring the time
the system remains at a certain power level.
The user has the ability to apply a very coarse or fine granular
characterization depending on his design goals. Meaning, the user can
characterize as many hardware or software components as he want to
tune the measurement towards greater accuracy. Using the TCL scripting
API, the characterization is independent from the Virtual Platform
models.
Details: See chapter 9.8.1 of "CoWare ARMTM RealViewTM Baseboard
Virtual Platform User’s Guide" available on the desktop in the cloud:
http://www.coware.com/solutions/vp_saas.php
It is important to understand that the framework is targeting the
software developer to understand the software impact on power.
Therefore, the numbers should be used for relative trend based
optimization and should not be considered as accurate in terms of
absolute power numbers. Of course, the more fine granular the
characterization is, the more accurate the absolute number will get.
But, the focus should be on the components that are under control of
the software. Thus, you need ballpark numbers from data-sheets. Here
is an example on mA measurements done by Google which they have
presented in http://code.google.com/events/io/2009/sessions/CodingLifeBatteryLife.html
Wifi Full: 275 mA
3G Full: 150 mA
GPS: 85 mA
Sensors: 80 mA
LCD: 90 mA
CPU: 100 mA
3G Idle: 5 mA
Wifi Idle: 12 mA
Next to the measurement, the software developer can control scenarios
to stimulate the Virtual Development Board. This can be done by
providing stimuli via the board interfaces such as UARTs, GPIOs,
Keyboard, Touchscreen, Ethernet. In case of a Virtual Platform those
interfaces are controllable via APIs as well as a commands available
on the Virtual Platform scripting shell. This way a car-driving
scenario can be created as the modem connected to UART 1 is signaling
cell changes, and the GPS is updating location information via UART 2.
(See also my post on "Enabling deterministic/repeatable (Android) GUI
testing by record and replay of user input", http://screenr.com/5Kh,
http://groups.google.com/group/virtual-platform-users/browse_thread/thread/3208b43c8318fe64)
Let me know if you have comments or questions.
Best regards,
Achim
AchimNohl
recently I have read a blog post from Mentor's Collin Walls on "OS
influence on power consumption". The article describes an interesting
case where an mp3 player application is compared with regard to power
on an RTOS vs Linux. The link to the article can be found here:
http://www.mentor.com/products/embedded_software/blog/post/os-influence-on-power-consumption-2e7ff8a2-ff71-4ba0-a638-6cca68e08dc8
What catched my eyes was the following statement: "There is also an
increase in power consumption of another 20% [between about 3000 and
4000 on the plot] when running Linux. What caused this? We do not
know. Obviously Linux was doing something in this time frame, which
affected it CPU load.". I was wondering if a VP (even if representing
no the same HW, not exactly the same SW) could put light on this with
interesting results. Using system level software analysis I have been
able to show potential reasons for this effect. I have posted a
comment to the blog that describes what I have done.
In order to get there I have used the VP in the cloud, Vanilla skin
and the mplayer application.
Screenshot: http://groups.google.com/group/virtual-platform-users/web/mplayer100Hz_linux26_fig1.png
Best regards,
Achim