Methods for determining battery drainage / cause

[AlMehdi]

Originally Posted by rexii23

Over the past week or 2 I've also had battery problems. I ended up reflashing and thought it was all good and started installing apps. but the problem started again.

I can't help but think its the titan's kernel doing something OR conflicting with something cos ever since I uninstalled it 3 days ago, the mysterious battery drain disappeared.

I used powertop to see what's going on. It turns out that the kernel is doing something weird. The process:
<kernel core> with function tick_nohz_restart_sched_tick kept the phone in C0 state all the time. Battery drains to 0 in a few hrs. It's completely random and it takes a few restart for the problem to go away.

Anyone else have the same problem?

I'm gonna have another crack at reflashing and installing apps one by one and testing it slowly this time.

On a side note the scim package used for for chinese input also drains battery.

Once I start scim-panel-gtk, it keeps n900 from sleeping fully and keeps waking the n900 up. This can be confirmed by running powertop. n900 will spend approximately 30% of the time in C3 state and cannot go fully into C4 state.

The process cannot be killed, it just respawns. A restart is needed to unload it. If anyone can figure out a good way to stop it from respawning let me know!

I have titans kernel and got about 90% on C4 and 1,5-2% on C0 so i am not sure it is the oc-kernel. Though i can confirm that tick_nohz_restart_sched_tick is one with the most wakeups.

Have never seen the scim-panel-gtk causing problems.. but that process must be pretty deep and if turned of cause instability.. thus it starts up again. Maybe if you remove it from init.d but that would probably cause even bigger problems.

Ohh.. and i forgot to say that powertop needs to be run with root or it segfaults.

[SpeedEvil]

Originally Posted by AlMehdi

I have titans kernel and got about 90% on C4 and 1,5-2% on C0 so i am not sure it is the oc-kernel. Though i can confirm that tick_nohz_restart_sched_tick is one with the most wakeups.

It doesn't.
This is exactly backwards.

I'm trying to write a page explaining power use - this is not done yet.

http://wiki.maemo.org/N900_Software_Power_management
In a couple of days I hope to have it polished, including how to use tools.

Of an idle system.

PID# | Activity | Name | Function Entry (Expire)
--------+------------+----------------+---------------------------
0 | 15 | <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)

This is only called when something happens, to reschedule when the next tick happens.
0 | 10 | <kernel core> | hrtimer_start (tick_sched_timer)
Similarly.

37 | 8D| awk | cpufreq_governor_dbs (delayed_work_timer_fn)
This is a kernel bug - the awk is bogus - as is the process number, this is really the CPU governor code being called - again after something else happens - to change the CPU speed.

From here on are 'real' wakeups.

743 | 7 | bme_RX-51 | sys_timer_settime (posix_timer_fn)
BME timer timing out 7 times in 30s.

475 | 3 | wl12xx | schedule_timeout (process_timeout)
wireless card timeouts.
1 | 3D| <kernel core> | queue_delayed_work (delayed_work_timer_fn)
I think this is to process delayed events.
475 | 2 | wl12xx | schedule_timeout (process_timeout)
475 | 2 | wl12xx | queue_delayed_work (delayed_work_timer_fn)
wireless card again.

[AlMehdi]

SpeedEvil: Pleas explain about the i2c_omap too.

[rexii23]

Originally Posted by AlMehdi

I have titans kernel and got about 90% on C4 and 1,5-2% on C0 so i am not sure it is the oc-kernel. Though i can confirm that tick_nohz_restart_sched_tick is one with the most wakeups.

Have never seen the scim-panel-gtk causing problems.. but that process must be pretty deep and if turned of cause instability.. thus it starts up again. Maybe if you remove it from init.d but that would probably cause even bigger problems.

Ohh.. and i forgot to say that powertop needs to be run with root or it segfaults.

On the occasion that things behave nicely. I can get up to 97% on C4 on a complete idle system. As I have said previously, it was randomly keeping the device out of C4 and into C0. Will have another try on a completely flashed system on the weekend and see if what SpeedEvil describles will happen on a fresh system.

The scim-panel-gtk is not really that integral to the system. On a fresh boot it doesnt kick in. only when I click on the screen for the virtual keyboard the scim input box then pops up and the process stays. So I don't see why it can't be killed.

@SpeedEvil, can't wait for the full article

[AlMehdi]

Originally Posted by rexii23

On the occasion that things behave nicely. I can get up to 97% on C4 on a complete idle system. As I have said previously, it was randomly keeping the device out of C4 and into C0. Will have another try on a completely flashed system on the weekend and see if what SpeedEvil describles will happen on a fresh system.

The scim-panel-gtk is not really that integral to the system. On a fresh boot it doesnt kick in. only when I click on the screen for the virtual keyboard the scim input box then pops up and the process stays. So I don't see why it can't be killed.

@SpeedEvil, can't wait for the full article

Nothing is random

If i where you i would try to find out the reason before you flash. And i guess you will.. have you installed sysklogd? It might help you further in your investigation. Also the MicroSD card can be cause for some wake ups. I guess that is the "mmcqd" and "mmc1" processes.

[Matan]

Originally Posted by ndi

All apps that do something when not started drain. battery-eye, e.g. is one. As is battery-graph. To log battery, one needs to run. Also, shotcutd, camkeyd, etc are all daemons. All servers.

The fact that a program is a daemon does not mean that it causes any battery drain. Take camkeyd, for example. All it does is sleep, waiting for a specific d-bus event. It does not run and therefore does not consume battery except for very short time when the camera key is pressed. Unless you spend all time pressing and releasing the camera key, it has absolutely no effect on battery life.

Shortcutd, on the other hand, might activate the proximity sensor which does draw non negligible amount of power, but it's CPU consumption is meaningless.

[2disbetter]

Originally Posted by Matan

The fact that a program is a daemon does not mean that it causes any battery drain. Take camkeyd, for example. All it does is sleep, waiting for a specific d-bus event. It does not run and therefore does not consume battery except for very short time when the camera key is pressed. Unless you spend all time pressing and releasing the camera key, it has absolutely no effect on battery life.

Shortcutd, on the other hand, might activate the proximity sensor which does draw non negligible amount of power, but it's CPU consumption is meaningless.

Good point. But still even as it sleeps isn't it still pulling power? An app not recieving any processing power will not be able to tell the event occured. At least not in any computer architecture I'm aware of. While the power I'm talking about to make this happen is negligible it is still power being drawn. I'm not sure how the operating memory of the N900 functions in comparison to desktop RAM, (I know how the my documents and sd card portion work) but I'm assuming even being loaded into this space still requires power to keep it there.

The only way an app can claim it doesn't use power, is when it's not being reported in your list of processes.

[shadowjk]

Originally Posted by 2disbetter

Good point. But still even as it sleeps isn't it still pulling power? An app not recieving any processing power will not be able to tell the event occured. At least not in any computer architecture I'm aware of. While the power I'm talking about to make this happen is negligible it is still power being drawn. I'm not sure how the operating memory of the N900 functions in comparison to desktop RAM, (I know how the my documents and sd card portion work) but I'm assuming even being loaded into this space still requires power to keep it there.

The only way an app can claim it doesn't use power, is when it's not being reported in your list of processes.

An app waiting for an event doesn't consume any processing power. If no apps and drivers have requested to be woken up in X amount of time, the CPU goes to sleep indefinitely. Some peripherals might remain powered, and some minimal amount of circuitry is powered to detect if you opened up the keyboard slide, pressed any buttons and so on. That then generates an IRQ that wakes up the processor. The kernel's driver and the kernel itself then checks what apps need to be notified of this event. Typically on the N900 most things end up going out through dbus, which sends a notification to the apps, which causes the kernel to schedule them for time on the processor.

Polling behaviour, an app doing something like checking if a condition exists, sleeping for a second or two, checking again, and so on, is very bad behaviour and not battery friendly.

Heck, even PCs are capable of this to some extent. Suspend to ram leaves the CPU powered off, RAM remains powered. The OS might elect to retain some hardware, to for example detect if user presses powerbutton or types on the keyboard.. It can program itself to be woken up by the RTC, and the RTC is capable of running years on the single lithium coin battery on the motherboard... It can even switch the entire system off. Of course, on a PC entering and leaving such low power modes takes ages and aren't a practical thing to do behind the user's back.. Exception here being OLPC where they threw out the BIOS and managed to program the computer to suspend while leaving the screen on, and managed to make it fast enough that it 's transparent to the user..

[juise-]

Originally Posted by s33

But battery eye & battery graph doesnt record the battery activity when its idle right?

these two apps only use cpu when they are opened.it takes 5-8secs to load since it needs to get the details so that the graph/percentage left can be shown.

so i think they dont drain battery unless you use them

Both of the battery logging apps mentioned come with a background process that is "on" whenever the phone is. They do listen for changes in the values they record, and when they do, they write the observations to disk. This functionality will inevitably use some power.

However, data collection processes for both apps are pretty well behaved in that they will only do something when things change i.e. they do not poll (I think though that BatteryGraph has to do some very infrequent polling, maybe 10min interval, in order to record system load). I've been running both of these apps for about 5 months now, and dare to claim that neither of them should be causing measureable idle drain.

That said, if one doesn't want or need battery stats recording, there's no reason to keep these apps installed.

[s33]

Originally Posted by juise-

Both of the battery logging apps mentioned come with a background process that is "on" whenever the phone is. They do listen for changes in the values they record, and when they do, they write the do some very infrequent polling, maybe 10min interval, in order to record system load). I've been running both of these apps for about 5 months now, and dare to claim that neither of them should be causing measureable idle drain.

That said, if one doesn't want or need battery stats recording, there's no reason to keep these apps installed.

so what u are saying is that these apps dont drain much battery...but they do upto some extend....

if so how much % does it use?
how much battery life do you get?
can u give a brief analysis??

i enabled VDD1 by editing "pmconfig" file...but now am getting less battery life than before.....sometimes less than 10hrs with slight usage