[maemo-users] [maemo-users] Battery Benchmarking?

From: Igor Stoppa igor.stoppa at nokia.com
Date: Wed Jan 10 11:32:48 EET 2007
Hi Tim!

On Tue, 2007-01-09 at 19:07 +0100, ext Tim Teulings wrote:
> Hello!
> > the apps you have installed are buggy and generate activity
> > and i mean any type of activity, 1% CPU load is still too much:
> > if the app is idle, it must have 0% CPU activity
> What does that exactly mean (especially for non GTK-based applications
> like mine that cannot expect some GTK magic)?
First of all my deepest and most sincere thanks for this question.
So maybe for once it won't look like i just rant against application

> Say for example I have an editor with has a blinking cursor. The GUI
> library internally uses select with a timer as main event loop. Does
> above statement mean, that my application is still running and select
> still lopping and timer can run out and the cursor still blinks while I
> put the cover on the device?

Let's take the editor example and see it throughthe whole sw stack.

*First of all the timer you are using from userspace is mapped to a
queue in the kernel, which in turns uses a hw timer.

*The kernel has _NON_ periodic system tick timer, meaning that system
ticks are skipped when there is no activity scheduled.

(So that means that if nothing perturbs the state of the system, it
won't wake up, even if the cover is not present and you are looking at a
static image of the text in your editor.
As a matter of fact it does wake up every now and then, but the number
of times can be approximated with 0, when compared to a system where
there is a interrupt every tick.)

*select will be (hopefully) implemented in a sane way that doesn't busy
loop, but rather relies again on asynchronous events (notification from
the kernel that the timer has expired) and therefore the library code
shouldn't generate unnecessary activity.

*finally the editor application: personally i consider blinking cursors
to be evil, however putting aside personal feelings, in general it makes
sense to do screen updates only when they are visible. So if the cover
is on, what good is to update the blinking cursor? Same applies to cover
off (open) but screen blanked. Again nobody will enjoy your nice
blinking effect but that will cause the processor to periodically wake
up. Certainly not for long, but if I may quote Depeche Mode,
	 "Everything Counts in a Large Amount"

> I always assumed that it goes in some kind
> of hibernate mode where machine state is (nearly) completely frozen,
Yes and no:
-yes because it does go to hw specific power saving states
-no because it is transparent to sw (well, most of it and certainly user
space stuff) and if the sw doesn't keep quiet, the power saving state
won't be reached. (Actually there are significant differencies between
omap1710 and omap2420, with the latter having finer granularity of what
hw blocks can sleep and how.)

> but
> your statement sounds like it just switches of some stuff of while CPU
> is still running?

I consider the "OFF" button on your everyday PDA just smoke in the eyes.
Many people have compleined for the absence of a hybernate
They have not understood that we are already doing it dynamically. All
the time, at _runtime_, not just when the user presses the "OFF" button.

Of course it takes more effort, but that's the way to go, since modern
mobile processors would have ridiculous use-times if they were running
constantly at full power.
Or the size of the battery would become incredibly large.

> How can I work around this?
*Don't do unnecessary stuff
*Don't poll
*Don't busyloop
*Check system state (by listening for events, again, never poll)
*Keep updates at minimum
*Do updates only if your application is visible, otherwise completely
stop updating the UI till you become again king of the hill

> Do I need to catch DBus events to get
> informed that I have to go in some application specific low power mode?

Yes, screen blanked should be enough.
Also because N800 doesn't have a cover, but certainly that doesn't
prevent us to do the very same power saving that was already available
on 770. :-D

The cover would just be the cause for an _immediate_ rather than timed
screen blanking.

Cheers, Igor

Igor Stoppa <igor.stoppa at nokia.com>
(Nokia M - OSSO /Helsinki Finland)

More information about the maemo-users mailing list