Active Topics
-
[HOWTO] Comprehensive Firmware Flashing Guide for N9 (1,580)
to Nokia N9 / N950 by aspergerguy - 9 hrs, 48 mins ago -
Nokia N9-00 Prototype Build S1.12 (RM-680 codename "Dali") (250)
to Nokia N9 / N950 by en0s - 3 days, 6 hrs ago -
[Announce] Maebble - Pebble support for Maemo (118)
to Applications by glo-worm - 3 days, 18 hrs ago -
Possible to flash Leste to eMMC? (6)
to Maemo 7 / Leste by Eri - 4 days, 8 hrs ago - more...
 |
|
2010-08-03
, 09:41
|
|
Posts: 70 |
Thanked: 410 times |
Joined on Sep 2009
@ Fife, Scotland.
|
#32
|
Originally Posted by AlMehdi
It doesn't.
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.
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.
| The Following 6 Users Say Thank You to SpeedEvil For This Useful Post: | ||
|
|
2010-08-03
, 09:48
|
|
Posts: 1,751 |
Thanked: 844 times |
Joined on Feb 2010
@ Sweden
|
#33
|
SpeedEvil: Pleas explain about the i2c_omap too.
|
|
2010-08-03
, 11:19
|
|
Posts: 69 |
Thanked: 18 times |
Joined on Apr 2010
|
#34
|
Originally Posted by AlMehdi
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.
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.
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
|
|
2010-08-03
, 12:55
|
|
Posts: 1,751 |
Thanked: 844 times |
Joined on Feb 2010
@ Sweden
|
#35
|
Originally Posted by rexii23
Nothing is random
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
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.
|
|
2010-08-03
, 13:01
|
|
Posts: 1,224 |
Thanked: 1,763 times |
Joined on Jul 2007
|
#36
|
Originally Posted by ndi
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.
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.
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.
__________________
My repository
"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".
No more Nokia devices for me.
My repository
"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".
No more Nokia devices for me.
 |
|
2010-08-03
, 14:24
|
|
Posts: 365 |
Thanked: 98 times |
Joined on Nov 2009
|
#37
|
Originally Posted by Matan
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 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.
The only way an app can claim it doesn't use power, is when it's not being reported in your list of processes.
|
|
2010-08-03
, 20:48
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#38
|
Originally Posted by 2disbetter
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.
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.
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..
 |
|
2010-08-03
, 21:33
|
|
Posts: 186 |
Thanked: 192 times |
Joined on Jan 2010
@ Finland
|
#39
|
Originally Posted by s33
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.
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
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.
__________________
Trout have underwater weapons.
Trout have underwater weapons.
Last edited by juise-; 2010-08-03 at 21:36.
|
|
2010-08-03
, 23:09
|
|
Posts: 142 |
Thanked: 8 times |
Joined on Jul 2010
|
#40
|
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
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.