Re: Methods for determining battery drainage / cause
 

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.

Re: Methods for determining battery drainage / cause
 

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.

Re: Methods for determining battery drainage / cause
 

SpeedEvil: Pleas explain about the i2c_omap too.

Re: Methods for determining battery drainage / cause
 

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

Re: Methods for determining battery drainage / cause
 

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.

Re: List of Apps known to drain battery?
 

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.

Re: List of Apps known to drain battery?
 

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.

Re: List of Apps known to drain battery?
 

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..

Re: List of Apps known to drain battery?
 

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.

Re: List of Apps known to drain battery?
 

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:eek: