Database Info

[HOWTO] Improving Battery Life for CM 5.0.7 and other 2.1 ROMS [upd 06/04]

I had seen one too many posts about people asking and complaining about battery drain issues on their G1 phones and it gets tiring to read it every 5-10 posts. So I decided to create this thinktank to pool in ideas from the community and create a set of best practices to maximize mileage of our phones. I'm currently using a HTC Dream with stock battery and my battery life is pretty good with light to medium usage. I would like to contribute to the community by creating this thinktank thread. I hope this can help as a guide for myself and for people who have been having numerous battery drain issues on 5.0.7-DS and variants of this distribution.
This is NOT the ultimate end-all solution for your battery problems. These are just steps to tackle the problem. If you want minimum to no battery drain keep it plugged to socket or plug it in a car battery.
If you would like to contribute your experience, or make any corrections please do not hesitate to post and I'll include them if they seem fit and attach your name as reference. I'll also do my best to give credit where credit is due. Please see the references at the bottom part of the post. Please do not clutter this thread by doing "I'll try this" or "It doesnt work" post. Its more important for all of us to know WHY it work/didnt work. Stick to topic, and be constructive. Be intelligent. Think first.
0. Update your Radio
Updating your G1's radio to the currently-latest version (2.22.23.02) should give you better battery life as well as signal reception (you can always switch back to 2.22.19.26I if it doesn't work out for you)
1. Recalibrate
Take note that BATTERY STATS ARE WIPED whenever you flash a new rom. (since full wipes are required whenever changing ROMS, and /data is where the battery info is.) This usually leads to inaccurate battery readings.
Here's how you recalibrate properly:
- Charge your phone till the GREEN LED shows up. Leave it for another hour.
- While plugged, go to recovery and wipe your battery stats.
- Right after the phone is booted up and settled, unplug and use as per normal till it shuts off. Then charge as per normal.
2. Disabling some basic phone hardware functionality
Turn off GPS, WIFI when not in use. And brightness set to manageable levels. Even loudspeaker. This is self-explanatory. Automation software like LOCALE can be useful, but usually all it takes for you to turn off your ringer, or turn on wifi when you're at a specific area is just a press on the Power control widget.
3. Overclocked kernels
Running on full overclock speed (by default is 528mhz or even higher on some kernels) will drain your battery faster and you'll notice significant heat increase when you're using your phone along with 3G.
Although im using pershoots 576mhz overclock kernel, I do not max it to 576 unless needed. The reason why I use his kernel is due to its UNDERVOLT capability. I have set up my phone using SetCPU
MAXFREQ: 480,
MINFREQ: 176
CPU Governor : ONDEMAND.
Click to expand...
Click to collapse
Usually I would set my phone to 384mhz if im going to stay on it longer (texting/long browsing etc). On the sleep mode I set it to 122mhz to 384mhz.
4. Tame your widgets, minimize using them.
Widgets that constantly connect to the internet, or constantly refreshing on the screen to update data being shown on the screen at extremely small intervals would also give you battery drain. Minimizing widgets can help minimize applications running in the background (free up memory) and avoiding your phone going on "partial sleep". Also tweak your widgets to update as less as manageably possible. If for some reason you can't see the next suggestion.
Aside from that you might want to disable Background syncing and do manual syncing. Aside from saving your data plan, it also saves battery life. You can disable it by doing the following:
Menu > Settings > Accounts & Sync > Background Data - OFF
Click to expand...
Click to collapse
manually update your facebook widget or contacts/gmail by
Menu > Accounts & Sync > Facebook (or GMail) > Sync.
Click to expand...
Click to collapse
5. 3G, 2G, switch off, or automate it.
You'll notice that inside the default settings for mobile networks. Setting to 2G will "save battery" which is actually true. The connection will definitely be slower, but if you like your phone to last longer throughout the day, either switch to 2G or turn it off altogether.
Also, similar to juice defender, I use 2g/3g toggle and toggle data as and when needed.
Another suggestion that I just found out recently is the use of Juice Defender app [d]. It automatically turns on or off your APN settings at intervals. You might want to try to look at that app if you cannot do #4
6. Disable live wallpapers. Auto Updating Sense
Remember that 2.1 isnt actually built for our old phones. and livewallpapers do require cpu/gpu processes. These are also running in the background and may run while your phone is asleep. So turning them off will benefit you.
7. Refrain from using Automated task killers and choose what you kill.
If you see that the app you had been trying to kill a few times keeps coming back. Stop killing it. Everytime you do, and whenever it respawns, CPU flies to 100%. Go back to #4.
8. Disable Market notifications.
- Open the Market application.
- Select the Menu key.
- Select Downloads.
- Select the Menu key again.
- Select Notifications.
- Select the Do not notify me radio button. press [Ok]
Click to expand...
Click to collapse
9. Make your phone sleep.
Open your spareparts application, Go to End button behavior. Select "Go to sleep"
10. Under the hood tweaks
10.1 Extending Wifi scan intervals
Edit the wifi scan interval in /system/build.sapphire.prop (or build.trout.prop if you have a G1)
# Time between scans in seconds. Keep it high to minimize battery drain.
# This only affects the case in which there are remembered access points,
# but none are in range.
wifi.supplicant_scan_interval = 45
Click to expand...
Click to collapse
Changing this number to just 90 second will half your wifi scans. Obviously larger numbers can mean less wifi scans which means more battery life, though it may take a little longer for your phone to pick up a remembered access point when in range. This is not just a CM/Eclair thing, it can also work for Donut phones.
This setting needs a reboot after editing the file. Edit it with Root Explorer, or nano as root if you have CM5, or pull the file with adb then edit it then push it back.
11. Remove your phone from your pocket whenever you can.
Body heat deteriorates battery life no kidding! there had been already studies to back it. I keep my phone either on my hand or outside of my pocket to keep it cool. Do whatever is manageable in your environment. If you're using your phone as a music player streaming using streamfurious and stuff. dont let your body heat add to the heat already been generated by your phone itself.
References / Updates :
[a] cyanogen recalibrating batteries : http://wiki.cyanogenmod.com/index.php/Troubleshooting#Battery_recalibration
thanks to mejorguille for correction on /data and wiping.
pershoot UV kernel: http://forum.xda-developers.com/showthread.php?t=666850
[c] SetCPU main site : http://www.pokedev.com/setcpu/ - Thanks also to ShadowCH for tip.
[d] JuiceDefender : http://www.latedroid.com/2010/01/juicedefender.html -
- Thanks to shohid1234 for 3G-2G toggle
[e] Thanks to Jaymzz for tip on disabling market: http://forum.cyanogenmod.com/index.php?/topic/94-i-fixed-my-battery-drain/
[06/02] thanks to Arkain2k for tip #0
[06/04] Thanks to Foo_Blyat's tip for disabling background sync and manual updates for fb/gmail (item 4) http://forum.xda-developers.com/showpost.php?p=6670907&postcount=36
[06/04] Thanks to Super Jamie for tip 10.1 extending wifi scans http://forum.xda-developers.com/showpost.php?p=6684954&postcount=49

reserved in case something nice comes up

10. Remove your phone from your pocket whenever you can.
Body heat deteriorates battery life no kidding! there had been already studies to back it. I keep my phone either on my hand or outside of my pocket to keep it cool. Do whatever is manageable in your environment. If you're using your phone as a music player streaming using streamfurious and stuff. dont let your body heat add to the heat already been generated by your phone itself.
Click to expand...
Click to collapse
really? isnt warmth charging batterys? in my old gameboy years i always put my batteries on the heater when the drained completely and after an hour i could play again with the old batteries.

1. Recalibrate [a]
Take note NOT TO WIPE BATTERY STATS whenever you flash a new rom and your battery is less than 90%. This usually leads to inaccurate battery readings. If you already wiped your battery during one of your flashes, here's how you recalibrate properly:
- Charge your phone till the GREEN LED shows up. Leave it for another hour.
- While plugged, go to recovery and wipe your battery stats.
- Right after the phone is booted up and settled, unplug and use as per normal till it shuts off. Then charge as per normal.
Click to expand...
Click to collapse
This is true, but since battery stats are stored on the data partition, a data wipe also deletes the battery stats. A lot of rom's require a full wipe, meaning data and dalvik, so battery stats are deleted whether you select the option or not.

Since001 said:
really? isnt warmth charging batterys? in my old gameboy years i always put my batteries on the heater when the drained completely and after an hour i could play again with the old batteries.
Click to expand...
Click to collapse
Hi!
Yes Im very familiar with that practice because i do that too. The reason might be because of the composition of the battery (alkaline, non alkaline). Usually we put it under the sun so that the heat will help change the composition of the compound inside the battery in order for it to lower down its resistance. Leading to a "charge".
But now we are using Li-Ion batteries, and I do not suggest putting them under the sun because it will deteriorate your battery capacity holding charge and its lifecycle.
reference: http://www.batteryuniversity.com/parttwo-34.htm see figure 1.

samaral said:
Hi!
Yes Im very familiar with that practice because i do that too. The reason might be because of the composition of the battery (alkaline, non alkaline). Usually we put it under the sun so that the heat will help change the composition of the compound inside the battery in order for it to lower down its resistance. Leading to a "charge".
But now we are using Li-Ion batteries, and I do not suggest putting them under the sun because it will deteriorate your battery capacity holding charge and its lifecycle.
reference: http://www.batteryuniversity.com/parttwo-34.htm see figure 1.
Click to expand...
Click to collapse
Thanks, that makes sense.
Made me lol to see that there actually is a "battery university"

Thank you! this post is noted
mejorguille said:
This is true, but since battery stats are stored on the data partition, a data wipe also deletes the battery stats. A lot of rom's require a full wipe, meaning data and dalvik, so battery stats are deleted whether you select the option or not.
Click to expand...
Click to collapse
Noted. I have edited the guide to reflect your insight.
Thank you very much

how about going to setting - about phone - battery use?
there you can find out exactly whats killing your battery and take appropiate action.
Also, similar to juice defender, I use 2g/3g toggle and toggel data as and when needed. Using these two widgets i have no battery issues.

Post noted and added on top
shohid1234 said:
how about going to setting - about phone - battery use?
there you can find out exactly whats killing your battery and take appropiate action.
Also, similar to juice defender, I use 2g/3g toggle and toggel data as and when needed. Using these two widgets i have no battery issues.
Click to expand...
Click to collapse
Noted. Your suggestion is added on top.

change preferred network type helped for me increasing battery life
Hello all,
as describe in post
forum.xda-developers.com/showpost.php?p=6432560&postcount=1
changing preferred network type worked for me.
default setting: WCDMA preferred drains my battery in a few hours, crazy
within CM 5.0.7-test7 I was able to change to: GSM/CDMA auto and it worked
But now in the final release 5.0.7-DS I can not select this setting. Perhaps it correlates to the this (PRL) info in brackets.
It seems that no "auto" setting want be working so I am trying WCDMA only right now and will see if I have a network in 2G networks too.
Bye morT

Hhmm let me think…
Running a prrocessor that's massively overclocked with software that was never meant to run on our g1's I have an idea.
****** off back to stock or get over it
I mean seriously people come on, we have set cpu for power profile management, basic battery usage which is dim screen, turn off wifi and 3g when not in use blah blah blah same **** written in every guide about battery life for ANY roms from cupcake to eclair.
As I said, get over it or go back to stock.
[highlight]Mod Edit: Please watch your language and don't flame others.[/highlight]

im sorry does turning on "display battery status" in spare parts still effect battery life? TIA

Ive noticed that bluetooth is killlllling battery life, but dont know if its normal. I charged to 100% and turned everything on, leaving screen on the whole time and what not.
While I was actively using the net over WiFi, I had nothing using the bluetooth, and both seem to eat up 20%..
This might be normal, might not be, but thought it was odd that it being on, but not in use, ate up just as much as functioning, in use, wifi.

whats funny to me is as soon as my phone dies i plug it up reboot it a few times and my battery is at 70%
.... i think its not reading correctly .. i mean fully charged play talk text browse till it shuts off .. plug it in turn it right back on then reboot ..
and my battery is back at 70% which is weird ... anyone else notice that???
also wifi, gps is on screen brightness is standard !!!

batteries really seem to be the least developed technology in our high tech phones. feels like a sportscar with a one gallon tank...the fun's over quickly...
turned off my 3G and got a lot of additional battery life. with bad 3G reception (like in the place I live in) the phone was sometimes sucked empty in just a few hours, now I get two days.
another thing that really helped me extend my battery life was turning on airplane mode when I went to bed.

how about dont use overclock or any other cpu speed up tool....maybe the speed they are factory set to is there for a reason...Hmmmmmmm

dcowboys2184 said:
whats funny to me is as soon as my phone dies i plug it up reboot it a few times and my battery is at 70%
.... i think its not reading correctly .. i mean fully charged play talk text browse till it shuts off .. plug it in turn it right back on then reboot ..
and my battery is back at 70% which is weird ... anyone else notice that???
also wifi, gps is on screen brightness is standard !!!
Click to expand...
Click to collapse
You should go through a battery recalibration - steps on the first page.

Best Practices for Improving Battery Life for CM 5.0.7 (and variant ROMS) is to use this ROM, Thanks.
Do whatever you like, show or hide battery status in the Spare parts, calibrate or not....the battery remains....for loOng....enough time....

hot/cold controversy
Since001 said:
really? isnt warmth charging batterys? in my old gameboy years i always put my batteries on the heater when the drained completely and after an hour i could play again with the old batteries.
Click to expand...
Click to collapse
Since I have a background in electrical theory and chemistry, let me end this debate once and for all: heat makes atoms (and therefore molecules) move faster. Lack of heat (cold) makes them move slower. In general, fast-moving atoms in batteries mean MORE power, not less. The reason your car doesn't want to start when temperatures are subzero is that the battery acid (electrolyte) molecules are moving too slowly to oxidize (give off e-, electrons) and turn back into positive ions. The same is true for the ol' Gameboy AAs -- put them on the heater, the dry cell warm up, and more electrons are transferred to the anode by anions, the positive ions (cations) are more able to travel to travel back to the cathode (in the case of dry/wet-cell rechargeable storage batteries). Heat acts as a catalyst to produce electricity. Some of you may have even taken your car battery indoors if the electrolyte froze in the winter. Some of your cars may have battery blankets or even battery heaters if you live really far up north. In addition, the process of charging a Li-Ion, Ni-mH, or even lead acid battery will produce heat, because chemical conversion is bi-directional, but anyway . . . you charge the G1, it gets hot. You use it heavily, it gets hot. You know you're spending electrons somewhere when it gets hot period. Keeping the phone cool will not increase battery life or make it charge fast. What lower battery temperatures will do is lengthen the battery's overall life. What happens if you leave meat out in 100F/30C temperatures? It goes bad quickly. Same principle in Li-ion. The rechargeable battery is ideally an efficient, closed system of ion exchange that should work for many (hundreds) of duty cycles, but eventually heat plays a role in deterioration of the electrolyte and chemical catalysts inside.
So put your extra charged batteries (but you don't want a Li-ion or Ni-mH battery to sit very long in an discharged state, so be careful here) in the refrigerator in an airtight bag (rotating on a daily basis) if you really want them to last a long time, but don't charge them frozen (ka-boom!) and remember cold batteries charge slowly. Car batteries in sub-tropical areas are replaced at a rate of about once every 24 months, but in Sweden? Maybe every five or six years. Cold temperatures slow down chemical deterioration just like cold keeps that steak from becoming maggot food.
Again, a hot G1 may weaken its own internal components and batteries over time, but putting it on ice won't give you an extra 6 hours to oogle Miley Cyrus' vBlog
Hope this helps.

For me, unless I'm expecting a text or a call always have my phone on airplane mode. I turn it off every hour or so to see if I got any unimportant texts, and then turn it back on

Smartass CPU Governor on Droid 2

So I was investigating loadable kernel modules on the Droid 2 this weekend. One of the modules I tried loading was the smartass governor module and to my surprise it worked. From what I can tell it appears to be working with no problems.
The module itself is from a Milestone Cyanogen ROM. Given how close the Milestone is to the Droid 1 and how close the Droid 1 is to the Droid 2 it seemed like a safe try to see if it would load.
Requirements:
You must be rooted. This really should go without saying but I'm trying to cover all the bases here.
You must have busybox installed.
You must be able to boot into clockwork recovery.
I've tried this on Fission ROM but since we can't change the kernel on the Droid 2 this will probably work on any other Droid 2 ROM. D2G users, YMMV.
NOTICE: By installing this you assume any and all risk for what might happen to your phone. I am not responsible if this mod causes your phone to stop working, catch fire, steal your significant other, and/or hijack a plane. Basically I haven't had any issues but that is not a guarantee that you won't have any issues.
Attached is the update.zip. Boot into clockwork recovery and choose this zip to install. Once you reboot you'll be using the smartass governor.

So what has this done for your battery life?

Anecdotally I believe my battery life has improved. With the ondemand governor and data and wifi off I've seen my battery drop 10% in a night. With the smartass governor under the same conditions my battery appears to be the same. Now given that Motorola phones report the battery in just 10% increments my totally non-scientific analysis might end up being nothing.
Really you'd have to try it yourself and determine if things are better. From what I've read online the smartass governor is better at conserving battery than ondemand but it really depends on how you use your phone.

Download circle battery widget from the market. Its free and somehow it reports 1% increments. I have been using it for a while now and it seems to be spot on.
Sent from my DROID2 using Tapatalk

It just guesses

Well, there is a way to get an accurate battery reading. Reading /sys/devices/platform/cpcap_battery/power_supply/battery/charge_counter will give you the battery level in 1% increments. However, the system reads from /sys/devices/platform/cpcap_battery/power_supply/battery/capacity which provides the bounded 10% increments. Some widgets, Minimalistic Text for example, will read from charge_counter on Moto devices.
Ideally a kernel module could be written that changes what is written out to capacity so the entire system could take advantage of 1% battery increments. If I had the time I would take a crack at it, but it's been awhile since I've done any C coding.

Looks interesting. I'll wait until a little more feedback is given before I try it. How is the performance after the install?

I'm guessing you have to sbf to go back?

tbaker077 said:
How is the performance after the install?
Click to expand...
Click to collapse
No different than using the ondemand governor. Smartass takes a clever approach to CPU scaling: instead of polling CPU usage like ondemand it detects when the phone comes out of sleep and sets a timer to go off in two ticks. Once that timer goes off it looks at CPU usage and scales if needed. What does all this mean? Well, if you turn on your phone to quickly check the time and then turn it back off the smartass governor will never ramp up the clockspeed. So far after a few days of light usage I've been quite pleased.
rtfield said:
I'm guessing you have to sbf to go back?
Click to expand...
Click to collapse
Nope. If you want to revert just chmod 644 /etc/startup/smartass.sh and reboot.

Sweet
Thanks

I wonder if they could modify this to work with the new gingerbread kernel.
I know when I had an HTC Eris, Conap used a smartass gov on his kernel and it was awesome.

So I took a shot and flashed the smartass governor a second ago on my GB d2, and seems to be working just fine. I'll report later with battery stats and anything else i notice.

Spitemare said:
Well, there is a way to get an accurate battery reading. Reading /sys/devices/platform/cpcap_battery/power_supply/battery/charge_counter will give you the battery level in 1% increments. However, the system reads from /sys/devices/platform/cpcap_battery/power_supply/battery/capacity which provides the bounded 10% increments. Some widgets, Minimalistic Text for example, will read from charge_counter on Moto devices.
Ideally a kernel module could be written that changes what is written out to capacity so the entire system could take advantage of 1% battery increments. If I had the time I would take a crack at it, but it's been awhile since I've done any C coding.
Click to expand...
Click to collapse
I took a look at this and found some stuff that might be encouraging.
Here is the source for the battery driver. Line 397 reads as such:
Code:
val->intval = sply->batt_state.capacity;
If line 397 is changed to this
Code:
val->intval = sply->batt_state.batt_capacity_one;
then battery level should be reported in 1% increments. I've posted the updated driver code here.
The problem is the gorram encrypted bootloader. It's not easily possible to swap a built-in hardware driver with a compiled module. If someone with more Linux kernel experience than I wants to take a crack at it then by all means...

Do we really need busybox to uses this?

tbaker077 said:
Do we really need busybox to uses this?
Click to expand...
Click to collapse
Busybox's insmod is a little more robust then the insmod that's on the Droid 2. You can try editing the file /etc/startup/smartass.sh to remove the references to busybox and see if it works; I just stuck with busybox since that was what worked for me when building this thing. I'd try it myself but I can't at the moment.
I'm running an experiment now to see how long this governor will take me. I charged my phone to 100% last night (really 100% and not just to when the charging light went off) and turned it off. I turned it on this morning and will let the phone run until 5% battery is left. At that time I'll take a screenshot showing how long the system has been up. A few guidelines:
ROM is Fission 2.6.1 which of course means Froyo. I've been thinking about switching to the leaked Gingerbread ROM but I've decided to wait a little longer
Data must remain on. I usually turn data off when I'm not using it but to get results closer to worst case I'll keep data on. The only time it will go off is when I turn on Wi-Fi at home.
No turning off the phone at any time nor plugging it in. I guess I'm going to be using Dropbox a lot during this to transfer files but I don't want to reset the time since plugged in at all.
No overclocking, underclocking, or undervolting. Clockspeed and voltage are stock.
Usage will be light to moderate. I tend to use my phones for calls, chats, and web browsing. I'll throw in some YouTube videos and maybe download Angry Birds.
No apps that try to maximize battery life. That means no SetCPU, Tasker, Superpower, etc. This is supposed to be about how well the smartass governor does for battery life.
Again, once I reach 5% I'll try to take a screenshot of how long the phone went without being recharged.

Spitemare said:
I took a look at this and found some stuff that might be encouraging.
The problem is the gorram encrypted bootloader. It's not easily possible to swap a built-in hardware driver with a compiled module. If someone with more Linux kernel experience than I wants to take a crack at it then by all means...
Click to expand...
Click to collapse
Is this difficult to swap in simply because of the nature of what we'd be switching out, or does the eFuse chip and whatever other protection play a role here? I would try compiling your modified code and putting it on my device, except I'm afraid there will be some protective measure or something like that would brick my phone if I try. That and the fact that I have no idea what libraries and stuff I would compile this against.

So unfortunately my phone rebooted halfway into the experiment so there is no screenshot for you all. I will say my phone made it just under 36 hours (6:30 Friday to 18:15 Saturday) on this governor. With some moderate internet browsing and way too many YouTube videos I'm quite happy with the outcome using this governor.
ZaneKaminski said:
Is this difficult to swap in simply because of the nature of what we'd be switching out, or does the eFuse chip and whatever other protection play a role here? I would try compiling your modified code and putting it on my device, except I'm afraid there will be some protective measure or something like that would brick my phone if I try. That and the fact that I have no idea what libraries and stuff I would compile this against.
Click to expand...
Click to collapse
I've already compiled the modified module and tried to load it. The phone just prevents it from loading since the hardware interrupts are already bound to the compiled in driver.
eFuse doesn't prevent new kernel modules from being loaded. Since a kernel module can alter almost anything not being able to change the kernel isn't too much of a problem. What a kernel module can't really do, however, is change device drivers. There's not a really clean way to unload a device driver module since it binds to hardware interrupts and you can't really unbind that once the phone is up and running. If you want to replace a device driver with an alternate module you have to load the module before the original module is loaded sometime during the boot process. With compiled in device drivers though that's not really possible.
Basically we're in a situation where we need to load an alternate version of the device driver in module form before the compiled in device driver binds to the hardware interrupts. That would take some sort of ramdisk containing the altered driver module and we can't do that with eFuse.
The other option would be to write a module that hijacks calls to the particular function in the device driver and replaces that call with an alternative. That's got loads of problems though and is potentially dangerous. It would take someone with a lot more kernel experience than I have to write such a thing.

I installed this and didn't see any improvement in battery life until I ran
Code:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
It said it was still ondemand. I checked scaling_available_governors and smartass was not in there, so I went ahead and installed the zip again... still doesn't work.
I went ahead and took a look at /etc/startup/smartass.sh. The permissions were right, so I ran /etc/startup/smartass.sh. I then checked /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and it was set to smartass.
Can anyone shed some light on why this script is not running on boot? I'm running the leaked Motorola Gingerbread ROM if that makes a difference.
Spitemare said:
The other option would be to write a module that hijacks calls to the particular function in the device driver and replaces that call with an alternative. That's got loads of problems though and is potentially dangerous. It would take someone with a lot more kernel experience than I have to write such a thing.
Click to expand...
Click to collapse
I see. I'm guessing the way to hijack said calls would be through directly modifying memory, right? That definitely is not something that sounds easy to do.

I tried running smartass.sh through an init.d script... still nothing. I actually had to make the /etc/init.d/ directory, so I figured that init.d scripts aren't supported on the Motorola Gingerbread rom... strange. I'll look for somewhere else where I can run stuff on startup.

Look for /etc/install_recovery.sh. That file is run by /init.rc if it exists. It's how the overclock stuff gets loaded on Fission. What the update.zip does is back up that file if it exists and then append /etc/startup/smartass.sh to the end. Just add the following to the end of /etc/install_recovery.sh if the update.zip doesn't add it:
Code:
/etc/startup/smartass.sh

[DEV] Power Management

Hi devs
I found something interesting about Android power management..maybe it will help us
http://developer.android.com/reference/android/os/PowerManager.html
http://www.netmite.com/android/mydr...s/power_management.html#androidPowerWakeLocks
and here is a app for users http://forum.xda-developers.com/showthread.php?t=1179809

I found some more things for power management
devs check pls
Enabling system for hitting OFF
#echo 1 > /debug/pm_debug/enable_off_mode
By default sleep_while_idle is set to false and enable_off_mode is set to true
CPU Dynamic Voltage Frequency Scaling settings
Enabling ondemand frequency governor
The ondemand governor enables DVFS(frequency/OPP) transitions based on CPU load.
#echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Enabling performance frequency governor
The performance governor keeps the CPU always at the highest frequency.
#echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Enabling powersave frequency governor
The powersave governor keeps the CPU always at the lowest frequency.
#echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Enabling userspace frequency governor
Once this governor is enabled, DVFS( frequency) transitions will be manually triggered by a userspace application by using the CPUfreq sysfs interface
#echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
See all the available operating points
#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
Application can select any of the available frequency from the above
#echo <Desired Frequancy> > /sys/devices/system/cpu/cpu0/cpufreq/ scaling_setspeed
Checking CPU IDLE states usage
There are seven power states introduced by CPU Idle
The usage and time count for these different states can be checked via
#cat /sys/devices/system/cpu/cpu0/cpuidle/state*/time
#cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage
Enabling system for hitting OFF
#echo 1 > /debug/pm_debug/enable_off_mode
By default sleep_while_idle is set to false and enable_off_mode is set to true
CPU Dynamic Voltage Frequency Scaling settings
Enabling ondemand frequency governor
The ondemand governor enables DVFS(frequency/OPP) transitions based on CPU load.
#echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Enabling performance frequency governor
The performance governor keeps the CPU always at the highest frequency.
#echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Enabling powersave frequency governor
The powersave governor keeps the CPU always at the lowest frequency.
#echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Enabling userspace frequency governor
Once this governor is enabled, DVFS( frequency) transitions will be manually triggered by a userspace application by using the CPUfreq sysfs interface
#echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
See all the available operating points
#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
Application can select any of the available frequency from the above
#echo <Desired Frequancy> > /sys/devices/system/cpu/cpu0/cpufreq/ scaling_setspeed
Checking CPU IDLE states usage
There are seven power states introduced by CPU Idle
The usage and time count for these different states can be checked via
#cat /sys/devices/system/cpu/cpu0/cpuidle/state*/time
#cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage
source: http://processors.wiki.ti.com/index.php/Android_Devkit_Power_Management_Porting_Guide
this is very interesting also:
Saving battery time for mobile devices has been a goal for the industry for many years. With the
advent of smartphones, reduction of energy consumption is even more important since they
consume a lot more energy than the generation of mobile phones before them. Consumers are
demanding longer battery life and greener electronics. One way to meet these demands is to
reduce energy consumption.
In order to make the mobile operating system utilize the Central Processing Unit (CPU) more
efficiently, applications should have different reservations based on how much they need to use
the CPU. A challenge the industry is facing is its lack of knowledge of the behavior of third
party applications. Especially since they are an increasing portion of the applications run on
smartphones. Without knowledge of how third party applications behave, it is hard to make
good reservations for them. If there was a way to dynamically make reservations for the
applications with adequate performance while they are running, the system could use this
information to reduce battery consumption by e.g. clocking down the CPU when a high clock
frequency is not needed. In this master thesis project, an open source resource manager called
ACTORS Resource Manager (ACTORS RM) [5][6] for desktop Linux [57] is ported to the
Android [37] operating system. The resource manager is also optimized for the applications
being run there. A power management patch to the Linux kernel was also used to get greater
control over the CPU’s frequency changes.
source: https://rapidshare.com/files/3398178110/Resource_reservation_and_power_management_in_Android.pdf

let's spy on HD2 kernel ?
feature:
AB: Audio Boost
AXI: AXI frequency tweak
BFQ: BFQ IO scheduler (default CFS)
BFS: BFS cpu scheduler (default CFS)
HAVS: Hybrid Adaptive Voltage Scaling (Static Voltage Scaling - SVS is default)
OC: OverClock
UV: UnderVolt
OC, UV and AXI features are the standard feature for EVO based kernel.
EBAT: Extended battery
http://forum.xda-developers.com/showthread.php?t=777921
Edit: after some more research i found out that we are in BIG $h|t,until the f**** HTC will unlock the bootloader and/or update Radio for us
What REALLY improves Android battery life on the HD2
So after all that rambling, the answer is: radio ROM version. When I installed Android, I installed the latest radio ROM available at the time (still the latest I think); i.e. 2.15.50.14, from http://forum.xda-developers.com/showthread.php?t=611787. After pulling my hair out trying all the above, I flashed the radio ROM with 2.12.50.02_2, and as if by magic, current draw under similar conditions to above is about 7mW; i.e. 10% of what it was, and an overnight period as above goes from 100% to 96%. Much better
source:http://forum.xda-developers.com/showpost.php?p=13397376&postcount=1
currently our phones use 150-200 mA (even in standby,and with setCPU on :O)...measured with Current Widget available on Market.
Edit2: Another thing that REALLY improves Android battery life on the HD2 is dumping your girlfriend.
Before, I needed to charge it almost twice a day. Lots of calls and messages.
Now, I can easily get two days of standby. LOL

The radio version on hd2 is a bit tricky. Its very different from people to people. Some people say that its related to your region too.
I dont know if its the same on HD Mini.
But some people here say the dont have battery drain. It would be nice to know what radio version they use and at what region they are.

tzacapaca said:
currently our phones use 150-200 mA (even in standby,and with setCPU on :O)...measured with Current Widget available on Market.
Click to expand...
Click to collapse
But if turn off wifi, gps and phone, consumption almost does not decrease.
Maybe this consumption of sdcard, because its slot is always hot.

ROM-Version (Vodafone)Switzerland German: 1.41.166.1, (10904) Radio:0.63.05.41
Strong battery drain is only after the first boot. after the third boot is the battery drain same as in wi-mo.. same experience with cm6(derefas) ,134++(schlund)

i don't really agree.
under android, the maximum we can expect is to get as much battery life as under winmo.
today, the phone consume too much battery when on sleep, because something prevents it to go sleep.
schlund has a fix for this battery drain, I tested it, it is really efficient.
it will be released in next release, be patient ;-)
regarding the android apps that tells you how much current you have:
it wont work if the phone is really sleeping, because all the apps would be put on sleep.
so you will never know how much your phone consumes when on sleep ;-)

I should say: after the third boot is the battery drain almost the same as in wi-mo , but the truth is that there is a big difference between the first and third boot in battery drain.
New battery Fix, I'm glad to hear.
I understand that it takes time to create something, I have patience but I think it is unfair to announce a new release for the end of the week and then change mind and do not give any explanation. I hope you'll accept this criticism. Thank you

codiak said:
The radio version on hd2 is a bit tricky. Its very different from people to people. Some people say that its related to your region too.
I dont know if its the same on HD Mini.
But some people here say the dont have battery drain. It would be nice to know what radio version they use and at what region they are.
Click to expand...
Click to collapse
well,telling region and radio version won't help with anything,I will not move from my city to get better signal and HTC won't make a new radio only for me too
btw,it's impossible to don't have battery drain when phone use 200mA
i guess people were talking about CM6 of derefas,but his version is based on r146 kernel,which still has battery issues...
p.s. since u own a HD2 also do u mind to test for me with Current Widget and tell me the values in standby and on?I read some guys had 6-7 mA in standby and i think around 60 while it was on

DmK75 said:
But if turn off wifi, gps and phone, consumption almost does not decrease.
Maybe this consumption of sdcard, because its slot is always hot.
Click to expand...
Click to collapse
i'm not an expert but i really think it's impossible sdcard will use 150-200mA,if it was so then we will have 5-6 hours battery life in WM
Edit: after little research i found this ->
Metric NAND SD
Idle (mW) 0.4 1.4
Read
throughput (MiB/s) 4:85 2:36
efficiency (MiB/J) 65.0 31.0
Write
throughput (KiB/s) 927:1 298:1
efficiency (MiB/J) 10.0 5.2
so SD cards use around 1,4 mW when idle and 2,36 mW when read from it(our case)
and to convert mW to mA-> http://www.ehow.com/how_8627497_convert-mw-ma.html
source: http://www.usenix.org/events/usenix10/tech/full_papers/Carroll.pdf

-r0bin- said:
i don't really agree.
under android, the maximum we can expect is to get as much battery life as under winmo.
today, the phone consume too much battery when on sleep, because something prevents it to go sleep.
schlund has a fix for this battery drain, I tested it, it is really efficient.
it will be released in next release, be patient ;-)
regarding the android apps that tells you how much current you have:
it wont work if the phone is really sleeping, because all the apps would be put on sleep.
so you will never know how much your phone consumes when on sleep ;-)
Click to expand...
Click to collapse
i'm not really agree with u too
Current Widget runs as a process,and processes are on even if Android is in suspended,no?for ex clock,alarm,etc

15MA1L said:
ROM-Version (Vodafone)Switzerland German: 1.41.166.1, (10904) Radio:0.63.05.41
Strong battery drain is only after the first boot. after the third boot is the battery drain same as in wi-mo.. same experience with cm6(derefas) ,134++(schlund)
Click to expand...
Click to collapse
lol I think that's placebo or else why would number of boots/reboots will improve the battery life?

tzacapaca said:
well,telling region and radio version won't help with anything,I will not move from my city to get better signal and HTC won't make a new radio only for me too
btw,it's impossible to don't have battery drain when phone use 200mA
i guess people were talking about CM6 of derefas,but his version is based on r146 kernel,which still has battery issues...
p.s. since u own a HD2 also do u mind to test for me with Current Widget and tell me the values in standby and on?I read some guys had 6-7 mA in standby and i think around 60 while it was on
Click to expand...
Click to collapse
I get about 3-7 mA with all on (GPS, BT, 3G etc). Sometimes there are peaks to around 60 mA that are related to mailcheck etc. Its roundabout 1-2% per Hour what is fine to me

codiak said:
I get about 3-7 mA with all on (GPS, BT, 3G etc). Sometimes there are peaks to around 60 mA that are related to mailcheck etc. Its roundabout 1-2% per Hour what is fine to me
Click to expand...
Click to collapse
u see?
this is what i'm talking about,u can't compare 3-7 mA to 150-200 mA..so i can't understand guys who said they have power usage same as on WM...
btw,that was in suspend or while display was on?

Thats with display off. When using it the value is very variable depending on what you are doing. From ~120 to ~350 mA.

tzacapaca said:
u see?
this is what i'm talking about,u can't compare 3-7 mA to 150-200 mA..so i can't understand guys who said they have power usage same as on WM...
btw,that was in suspend or while display was on?
Click to expand...
Click to collapse
lol ok
i read somewhere that the sdcard was using 10 to 50mA max, i dont think it uses so much. maybe someone using HD2 with Haret (on sdcard) could lighten us?
which application are they using to get those values, and how to read those values if screen is off?

codiak said:
Thats with display off. When using it the value is very variable depending on what you are doing. From ~120 to ~350 mA.
Click to expand...
Click to collapse
ok,thanks
what about when with display on and doing nothing?

I used an SD build on my HD2 before using the NAND Rom. The values where nearly the same. So I dont think sdcard has a big impact on battery.
I use this App from the Market. It logs to a file and you can view the history

tzacapaca said:
what about when with display on and doing nothing?
Click to expand...
Click to collapse
Then its around 120 mA.
But remember, HD2 has a BIG display

I don`t know, maybe it will be usefull for developers. I tested CM6 r146 releace from derefas.
All night in sleep mode it takes 10-15% of accum. Then I use it for maybe 4-5 hours, and android said that charge is needed (it was near 15%). Putting on charge, don`t bring any result, I wait for half an hour, no persets where moving.
Then I reboot the device i n WinMo and it shows me 70%, after it i use winmo for 2 days without charging...
It seems to me that the problem is with indicator... in my situation there was a good accum, but android don`t see it...
P.S. Sorry, if i am talking silly things

[GUIDE] Maximum Battery - Maximizing your battery life with CM7 ROM by NeoLojik

UPDATE [11th September 2011]
Modified the SetCPU profiles:
Removed AC-charging Overclock (subject to temperature warnings mentioned in replies)​Reduced some MAX values (has added 5 hours of real-world battery use and makes no noticable difference in performance)​Added an optional < 101% profile to default the maximum clock speed to 729MHz (does not reduce performance, adds 2 hours effective runtime)​Specified the Priority values (which I had forgotten to mention originally)​
Introduction - The Desire S Battery Problem
As a fellow Desire S owner, you no doubt agree that it is a lovely phone: sleek, thin, relatively light, feature-filled... almost everything anyone could ever want from a phone!
However...
As a fellow Desire S owner, you no doubt agree that the battery life (on the Stock Sense ROM, regardless of how strict your PWM settings) is rather pathetic.
I have two HTC Desire S phones (one for myself, one for my wife), and both of them have almost exactly the same runtime (give or take a few minutes) when run in identical test conditions... no more than 18 hours (almost all of which with the display turned off) between charges, and less than 8 hours average with light-to-moderate screen-time when in use.
Bottom line: it's rather pathetic, and unacceptable.
Thankfully, we have options now... and this guide provides you with the option I have chosen for my Desire S phones.
Introduction - The Sacrifice
HTC Sense is (to many) considered a very "pretty" GUI, with nice animated transitions, a rounded feel etc, however it comes at a price: it's a battery hog!
I have played with many Sense 2 and Sense 3 ROMs on the Desire S, all of which share the common result of dimished battery runtime...
Bottom line: The simplest way to get more battery life is to sacrifice Sense entirely!
Just to point out: HTC Sense is the only sacrifice this guide makes in the persuit of optimal battery life! Unlike other guides, this one doesn't compromise any other features, or ANY performance (in fact, I've found performance with the setup described here to be even better than the stock ROM... noticably so!)
DISCLAIMER
I cannot (and will not) be held responsible for any losses or damages resulting from your use of this guide or the materials it contains. If you brick your phone, you've done something wrong and the fault is your own.
You should follow this guide with a fully charged battery, and if possible perform all steps involving a PC from a Laptop, with your phone connected via USB to minimize the risks associated with sudden power loss on your mains supply.
Stage 1: S-OFF
Aside from a lucky few whose Desire S came with S-OFF as a factory default, most of us have S-ON handsets.
With S-ON, you cannot flash a custom ROM onto your Desire S... but fear not, as there is now a FREE (and insanely simple) way to unlock our handsets, giving us the precious S-OFF we require.
You will require the Android SDK to be installed on your system, as well as the USB drivers for the HTC Desire S (these are installed as part of HTC Sync, though you should close HTC Sync from the system tray before proceeding as the S-OFF process will refuse to run with HTC Sync running at the same time)
Head on over to http://revolutionary.io/ to download their tool. This guide presumes you are using Windows, though it should be easy enough - if you're a Linux user - to adapt this information for your Linux platform.
Once you press the link to download Revolutionary, you will notice that a form appears asking for certain information. You'll see a screenshot of this below, but before we get to that there's something you must do...
Open a Command Prompt window from the Platform-Tools directory of the Android SDK.
From that Command Prompt window, type adb devices. Presuming you have the HTC Desire S drivers installed correctly, and your handset connected to your PC via USB, you should something like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
LEAVE THIS COMMAND PROMPT WINDOW OPEN, WE'LL NEED IT AGAIN SHORTLY
The third line of text begins with your handset's serial number.... you will need to enter this into the form on the Revolutionary website in order to generate your Beta key:
Once the Revolutionary zip file has downloaded, extract its contents into a folder on your PC (doesn't matter where, so long as you have access to that location).
Run revolutionary.exe following the instructions provided (it's a very quick and simple process... the automated portion of which shouldn't take more than 2 or 3 minutes to complete)
When it prompts you to install the Recovery mod, do it! You will need it for the next stage of this guide!
Your HTC Desire S now has S-OFF, is equipped with a version of ClockWork Recovery, and is ready to recieve the custom ROM! (All is good with the world).
Stage 2: The Custom ROM
IMPORTANT - THIS WILL FACTORY RESET YOUR PHONE (UNAVOIDABLE) SO DON'T FORGET TO BACK UP WHATEVER YOU NEED BEFORE YOU PROCEED WITH THIS GUIDE! YOU HAVE BEEN WARNED!
NOTE You will either need a spare MicroSD card, or to back up your existing MicroSD card and make it accessible to have files written to it from your PC (I use a card reader, but you can always use the USB Mass Storage feature of the phone itself to access the SD card in your phone from your PC)
The custom ROM of choice is NeoLojik's CyanogenMod 7, lovingly and paintakingly prepared especially for our HTC Desire S handsets, with quite probably the most prompt and spectactular support from NeoLojik himself.
I have chosen NeoLojik's CM7 ROM because it has proven (after exhastively testing other ROMs for the Desire S) to provide me with the very best battery performance, as well as all of the settings you will tweak as part of this guide.
Download (from the ROM's thread linked above):
The latest version of his ROM
The recommended Tiamat Kernel
The recommended version of the Google Apps package
To save time later, download The Android Market 3.1.3 APK
(You can download the APK from your phone directly after you've completed this portion of the guide, if you prefer)
Place the three ZIP files, as well as the Android Market APK, on the root folder of your MicroSD card (by "root" I mean the initial path of the SD card, which is whatever drive letter it mounts as on your Windows PC - e.g. "H:\")
Now, with your phone still connected to your PC via USB (and the SD card put back into your phone, if required), return to the Command Prompt window we used earlier and type adb reboot recovery
Now direct your attention to your phone
Once the Recovery Menu has loaded (should take about 30 seconds) we will follow some simple instructions below... but first, a few points on how to use Recovery:
Use the Volume Up and Down buttons on your handset to highlight one of the displayed options
Use the Power button to trigger the highlighted option.
wipe data/factory reset
wipe cache partition
apply update from sdcard
choose zip from sdcard
update-cm7.1.0-RC1-DesireS-Nexx-signed.zip (or whatever the ROM's filename is at your time of downloading... it will change as the ROM evolves)
apply update from sdcard
choose zip from sdcard
Tiamat_Saga-v1.1.2.zip (or whatever the filename is for the recommended Tiamat kernel at your time of downloading)
apply update from sdcard
choose zip from sdcard
gapps-gb-20110613.zip (again, filename might be slightly different for you)
Remembering with each selection to navigate to the "YES" option in the confirmation menu (this exists to prevent you from accidentally flashing the wrong file onto your phone)
Now, from your PC (or from the Recovery menu... doesn't matter which), you want to reboot your phone! To do this from the PC, you will just type adb reboot into the Command Line window we used previously.
Your phone will now boot with the new ROM (CyanogenMod), and has been factory reset (so you'll have to run through the first-run configuration wizard).
NOTE: Don't be scared if (after the boot animation disappears) the screen remains black for a minute or so! The first boot of the new ROM (especially with the Tiamat Kernel) does take a bit longer than every subsequent boot there-after. Just give the phone a few minutes, and press the Power button. You SHOULD see the Lock screen once the device is ready!
Run through the first-run wizard following instructions provided (fairly strait forward), though keep in mind that (at the time of writing) the wizard does not prompt for a WiFi connection until AFTER it attempts to log in to your Google account! Fear not, though, as when it fails to connect to your Google account (presuming you don't have Mobile Data available to you), it'll then prompt for a WiFi network and repeat the Google account login afterwards.
Once you have completed the first run config, open the "File Manager" app included as part of the ROM.
Navigate to /sdcard and run the com.android.vending-3.1.3.apk file. You'll be prompted to allow unknown sources, you want to tick that box and click on the APK again.
Once you've installed this, you will be running the latest (and greatest) version of Android Market, which (amongst other things) enables you to use a different Google account for your Apps (very useful if you want to install your paid applications on your wife's phone, as I have)
Welcome to CyanogenMod!....
Stage 3: Battery-saving Mega Settings [Menu-by-Menu]
The Settings I'm providing you here are the results of countless hours of experimentation (as well as logic and common sense). They have proven to provide the best degree of battery runtime with absolutely no performance or feature sacrifice!
If a menu or entry within a menu isn't mentioned, it's because it has no bearing on power saving!
Wireless & networks
Wi-Fi settings
Network notification = OFF
Press the Menu button, then Advanced
Wi-Fi sleep policy = NEVER​
Call settings
Vibrate on answer = OFF
Vibrate every 45 seconds = OFF
Vibrate on hangup = OFF (NOTE: I leave this ON as my one concession as it's the only way you will know if a call drops out on you unexpectedly!)
Vibrate call waiting = OFF
Always use proximity = OFF
Enable sensor rotation = OFF
Voicemail notifications = ON (it doesn't save power, but seriously... you want it on!)​
CyanogenMod settings
Display
Automatic backlight
Light sensor filter > Enabled = OFF (If enabled, unnecessarily drains more battery life! The feature itself is pointless as there is no difference to the UX with it Enabled or Disabled!)​Light levels
Use custom = ON
Screen dim level = 14
Allow light decrease = ON
Edit other levels...
This is what I consider to be the most optimal set of levels:
Lower | Screen | Buttons
0 | 21 | 2
160 | 31 | 2
255 | 35 | 2
320 | 40 | 0
640 | 50 | 0
1280 | 75 | 0
2600 | 90 | 0
5800 | 130 | 0
8000 | 200 | 0
10000 | 255 | 0
Press Save & apply (scroll to the top to find the button)
NOTE: You may want to play around with some of the values in this table, as screen brightness is not a "one size fits all" affair, and what I can see clearly might not be so clear for you (or vice-versa). Basically, use those levels as a starting point, and tweak them from there until you find the best settings for you in various lighting conditions.
I will say this, you don't want to set the Buttons value above 0 if you can see the buttons even faintly at a given light level. The backlighting for the buttons is a surprising battery drain (it's calculated as part of the Screen's power consumption in the Battery Usage menu). Bottom line: if you don't need any lighting on the hardware buttons in order to use them even in pitch blackness, then set the value of Buttons for each set in the table to 0 and squeeze more life out of your battery!​
Performance (press OK when the warning is displayed)
CPU settings
Available governors = SMARTASS ("SMARTASS" has been designed specifically [and brilliantly] to scale the CPU frequency with such a perfect balance of performance-on-demand versus power saving... it's the perfect choice!)
Min CPU frequency = 192
Max CPU frequency = 1036 (We'll be using SetCPU [full version, bought from the Market] to set up some magical CPU profiles later in this guide, saving us LOTS more battery life!)
Set on boot = ON​
Sound
Haptic feedback = OFF (Remember: The phone's vibrator consumes more power than playing a beep or other short tone through the speaker at even the highest volume!)​
Accounts and sync
Auto-sync = OFF (Auto-sync being disabled saves both battery power, as well as bandwidth on your Mobile Data tarif [2G and/or 3G dependant on carrier]. Really, you should just "sync on demand" as and when you want/need to!)​
This concludes the Settings portion of the guide!
Stage 4: SetCPU (for ROOT users) configuration
SetCPU for ROOT Users is available for on the Android Market for just £1.25 (or $1.99 USD). Not only does this program enable you to overclock/underclock your phone's CPU, but more importantly it enables you to provide Profiles, to scale the CPU based on the operational status of your phone.
This is well worth the infintismal pricetag, as the potential power savings (at no performance cost) is more than significant!
Open SetCPU, go to the Profiles tab:
Enable = ON
Notifications = ON (Really this is up to you! I like to have notifications for when the profile is changing to ensure that the CPU is scaling properly, and to ensure that my profiles are the best they can be for performance/battery balance)
Add Profile
Profile = Charging AC
Max = 1036800 (Potentially, you could set it up to 2GHz, but I have stability (and heat) concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful! If you do elect to overclock (particularly whilst charging), you will need to add a profile (with 100% priority) to drop the Max value if the temperature exceeds 45 C)
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Charging USB
Max = 1036800 (Basically 1GHz [original] CPU clock. We don't want to bleed into the minimal input of power provided by USB, so this is the best setting to use)
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Battery <
Battery < = 75%
Max = 652800
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Battery <
Battery < = 50%
Max = 576000
Min = 192000
Scaling = smartass
Press Save​
B]Add Profile[/B]
Profile = Battery <
Battery < = 30%
Max = 422400
Min = 192000
Scaling = smartass
Priority = 80
Press Save​
Add Profile
Profile = Screen Off
Max = 345600
Min = 192000
Scaling = smartass
Priority = 60
Press Save​
Add Profile
Profile = Time
Time = 01:00 - 08:00 (NOTE: Substitute the given range with whatever your daily sleeping hours are!)
Max = 345600
Min = 192000
Scaling = smartass
Priority = 70
Press Save​
The following profile is optional... and (if used) would specify your default clock speed
Add Profile
Profile = Battery <
Battery < = 101%
Max = 729600
Min = 192000
Scaling = smartass
Press Save​
Feel free to experiment with other profiles as well! Perhaps you may want to procedurally reduce your CPU speed based on Battery % in a more gentle way... this is certainly possible, and would squeeze even more life out of your battery.
You should also feel free to use lower MAX values for each setting (I would strongly advise against higher values) if you feel that the lower clock speed makes little-to-no noticable difference in performance as you use your phone.
Personally, I notice no difference between 729600 and 1038600!​
Stage 4: Recalibrating your Battery
Install the Battery Calibration app (FREE on the Android Market).
If your phone isn't charged, charge it up so that it is showing 100% (with the Green LED lit).
Run Battery Calibration and press the Battery Calibration button. Immediately unplug the power/USB cable from your phone, and allow it to run (as normal) until fully discharged.
Once the phone has switched itself off, plug it into the AC cable (using the mains charger).... and LEAVE YOUR PHONE SWITCHED OFF until the LED indicator is lit green!
You may want to repeat the discharge/recharge cycle one or two more times (as many people claim that this provides a better calibration)... though really that just entails running your phone on the battery until it is fully discharged, then allowing it (whilst switched off) to fully recharge on the mains adapter (AC)... which is not what most people would normally do as a routine.
Potential Stage 5: Tasker
Tasker (£3.99 on the Android Market) enables you to create profiles which automatically change various settings based on one or more given criteria. This even includes the ability to switch on and off features of your phone such as WiFi, Bluetooth, GPS, GSM, Mobile Data and Airplane Mode.
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
General Battery Storage/Maintenance Advice (Applies to all Lithium-Ion Batteries, including those used in Laptops)
To prolong the operational lifespan of your battery, you should not really allow your battery to run for very long below 50% charge, as "topping up" a half-charged battery generates less wear and tear on the battery, prolonging its overall lifespan.
NEVER leave your phone fully discharged for more than an hour, or the LiIon cells will begin to degrade, meaning your battery will never be able to physically hold as much charge. Indeed, the longer you leave a discharged battery, the less overall capacity your battery will retain.
NEVER store your battery (even if the phone is running at the time) in cold conditions! As a general rule of thumb, if it's "a little chilly" for you, it's unhealthy for the battery!
Both of the above tips form respectively the Number 1 and 2 causes of battery death! Don't let your battery become another statistic!
If - like me - you have one or more "spare batteries", you will likely be tempted to store them when they are fully charged (100%). This sounds like a good thing to do, but actually it can have (to a slightly lesser degree) the same damaging effect on the battery as leaving it fully discharged for any prolonged period of time!
The absolute best level of charge at which you should store a battery is at 50%, or as close there-to as possible!
Dependant on how often you find yourself recharging your battery, you should recalibrate it between every 3 to 6 months (the more often you discharge/recharge, the less often you should recalibrate).
Also, you should ALWAYS recalibrate after having flashed a new (or updated) ROM and/or Kernel!
My results using the exact configuration [excluding Tasker] detailed in this guide...
As I stated above, with the way I use my Desire S, I was lucky to get 8 hours of what I would call "light-to-moderate" use whilst running on the battery!
With the configuration detailed in this guide, I have now had a successful "100% to discharged" usage of 46 hours (under the exact same usage conditions as when I was using the stock ROM factory-installed on the phone (and updated OTA ~ a week ago).
This is a VERY significant improvement, though I must stress that results will vary heavily based on how much (or what) software you're running on the phone, how often you're interacting with it, how long you spend in calls etc.
Basically, every phone is different, and every operator (me, you, everyone) is different.
Please also keep in mind that your phone won't "settle in" to the new settings in terms of battery runtime until you've done 2 or 3 discharge/recharge cycles (as explained in the Battery Calibration portion of this guide)
Conclusion
There are plenty of third-party ROMs out there, and (obviously) I can't physically test them all! I have tested what I believe anyone would consider to be a perfectly suitable number (more than a dozen now), and have found the exact combination detailed in this guide to provide the very best battery runtime for me.
I understand that some of you will likely have your own ROM preference (for various reasons), but I hope that at least some sections of this guide will be useful to you.
If you just want to get the very best battery performance out of your Desire S, and either don't particularly care what ROM you use, or (like me) happen to love Cyanogen anyway... this guide will fit you like a glove!
Need any more advice?
No problem... post your comments and questions as a reply to this guide, and I'll answer anything I can, as promptly as possible (please consider that I have a company to run, and a life beyond the Internet... so replies might not always be "instant")
I hope you like this guide, and more importantly... I hope you enjoy your new-found battery runtime!

Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS

ben_pyett said:
Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS
Click to expand...
Click to collapse
Yeah, I can understand why so many people strictly adhere to Sense ROMs... for me the "slight prettiness" of Sense doesn't justify the hammering of the battery... especially as I actually preffer the L&F of Cyanogen anyway

If I have gotten 18 hours with almost always screen off I returned the phone. With nomal usage my phone last more than one day. Keeping the screen almost always off last almost 2 days with wifi and sync turned on (to be honest, never reached that again). ROM is whether LBC or rooted stock whith stock HTC kernel. So I can find any problem there. Nevertheless, this is a smartphone, and I always have a charger with me
I will try CM and what the battery life is like.

Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.

zeekiz said:
Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.
Click to expand...
Click to collapse
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.

Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.

LaKraven said:
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.
Click to expand...
Click to collapse
You could add a setcpu profile for limitting the temperature. I dont overclock, but when im using my phone while charging, it gets hot, so I limit the temperature at 41.1 C , so 768mhz - 245mhz , on demand.
lbc ROM, stock kernel

zeekiz said:
Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.
Click to expand...
Click to collapse
I've updated the guide (see the update notes at the very top of the post). The on-AC overclock setting has been removed, and I have placed a warning about overclocking next to it.

Updated the post to address a typo in one of the SetCPU profiles (I missed a 0 from the end of 345600).

I will have done this process by tomorrow, I'm sure - even bought Tasker. - Hoping I wont damage something in the process since I've never dealt with an HTC phone before. :/ Since my mom bought it to me as a present, she just peeks in from time to time to check wth am I doing with it - gotta keep a satisfied grin on my face all the time while I'm figuring how to fix this problem lolz

Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!

LaKraven said:
Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!
Click to expand...
Click to collapse
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium

ben_pyett said:
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium
Click to expand...
Click to collapse
Good to know I'm not the only one! It's such an easy step to overlock... just a good job it's also the least fatal mistake to make!

and then this
.. Ther is no Path in User, but there is in System...Geez, so tired..What do....:/ I'm all set to flash, just this thing I think...

You need to reinstall Java JDK.
This has happened to me before!

LaKraven said:
You need to reinstall Java JDK.
This has happened to me before!
Click to expand...
Click to collapse
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools

Bombastc said:
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools
Click to expand...
Click to collapse
Open Windows Explorer, navigate to C:\Program Files (x86)\Android\android-sdk\platform-tools
Hold down SHIFT and RIGHT-CLICK in on that folder
Click "Open command line window here"
You're then ready to start using ADB commands

LaKraven said:
UPDATE [11th September 2011]
Potential Stage 5: Tasker
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
Click to expand...
Click to collapse
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.

shizuku said:
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.
Click to expand...
Click to collapse
As a tasker convert myself, I can also say that you'll read a great review of some of its functionality and a slightly biased review of the product by wnp_79 as part of his [GUIDE] Update 28/06/11: HTC Desire S Guide (V1.03) For Newcomers to Android which is in a sticky at the top of the forum.

conservative cpu governor up/down thresholds, and their defaults

I did an experiment with some interesting results. It started out as my beginner's attempt to compare two kernels.
It evolved into providing insight (I think) regarding up/down threshhold parameters for the "conservative" cpu governor
If you dont’ want to read the whole thing, jump to the conclusion section posted at the end.
Phone configuration – installed qkster’s UCLB3 with AT&T bloatware removed, added custom kernel, rooted.
To remove variable cpu loads, I turned wifi/data off and turned off the continuously-running programs that I have installed myself (Power Tutor and Tasker).
To create a steady cpu load, I started the program “relax and sleep” (calm background noise program, available for free). I checked one audio channel in the program, and pushed back button to place program in the background, still creating noise. (I think relax and sleep is a good choice of program for cpu testing in general because it allows to check variable number of channels which does put variable cpu load.. although in this case I only used only one channel.. and note that you cannot recreate this experiment if you use mp3 music app instead, because it uses much less cpu than one relax and sleep channel)
Then I started setcpu for monitoring and experimentation. Repeated with several different kernels.
Results with Entropy’s daily driver kernel.
I set the test setup in setcpu to conservative governor, Fmax = 1200, Fmin = 100, i/o scheduler = noop.
The cpu frequency in Mhz now has the following pattern:
800, 1000,800, 1000, repeat ... (frequency changing approx once per second)
Results with with Zen Infusion-Z A/1600 kernel.
I set the test setup in setcpu to conservative governor, Fmax = 1200, Fmin = 100, i/o scheduler = noop (same as before, intending to compare the performance of the kernels).
The cpu frequency in Mhz now has the following pattern:
1200 (constant).
ok. On the surface one might conclude Entropy’s kernel is somehow handling the load better without ratcheting up the frequency. But the story gets more interesting than that:..
Next I tried Zen’s same kernel Infusion Z/1600 with everything the same except change the cpu governor from “conservative” to “on-demand “
The cpu frequency in Mhz now has the following pattern:
200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 1200 repeat
(changing about once per second, mostly 200, 400, pops into 1200 only very infrequently).
But wait! The "conservative" governor is supposed to be better on the battery than the on-demand governor, and yet for the exact same conditions, we’re gettings higher cpu frequency (1200 constant) with conservative than with on-demand (mostly 200/400 with occasionaly 1200). It’s the exact opposite of how it's supposed to be. Surprising, don’t you think!!???!!
So now let’s look at some other governor settings that don't seem to get much attention.
Go to “governor” page of setcpu with “conservative” selected on the main page. The following values appear repeatably after kernel installation for each kernel, so I am ASSUMING these are default values provided in the kernels themselves (open to comment if I have somehow come to the wrong conclusion)
For Zen’s Infusion-Z (A or B, 1600 or 1400)
up threshold = 80
down threshold =20
(also freq step = 5, sampling rate = 78124 although I don’t think these are important for this post)
For Entropy’s DD
up threshold = 50
down threshold =35
(also freq step = 20, sampling rate = 40000 although I don’t think these are important for this post)
(both kernels have sampling down factor = 1, ignore nice load = 0).
I think we can explain my "experimental" results by examining the above up and down thresholds and making some assumptions about the nature of the load (my assumptions are admittedly contrived in attempt to explain these observations, but they seem reasonable to me).
I ASSUME the steady cpu load I have created in my steup varies in the range 350-400 Mhz quasi-steady state (not perfectly constant due to other processes jumping up in the background).
I ASSUME that before the steady cpu load is reached, there is a temporary increase in cpu loading to 700Mhz or more associated with me flipping screens around to get from the relax and sleep appliation to the setcpu application. Within several seconds, this temporary increase will be gone and only the quasi-steady portion 350-400 Mhz remains.
First look at performance of Zen's Infusion-Z A/1600 while in conservative with default settings in the above experiment. That initial spike of 700Mhz load was enough to get us above the up-threshhold of the 800M-hz level (80%*800Mhz = 640Mhz) and push us to 1200M-hz (1200 comes after 800 in progresion for Zen A, which has no 1000). Once we got to 1,200Mhz, we are NEVER going to get down from there until we reach a load corresponding to the down-threshhold of that level which is 240Mhz (20%*1200Mhz = 240Mhz). And with my relax and sleep application running at 350-400Mhz, it won't happen. That is quite a depressing thing to think – I could put my relax and sleep on for an hour as backgorund noise, and my cpu would be buzzing at 1,200Mhz even though the load is only 350-400Mhz.
This seems very undesriable for battery life.
Now lets look at performance of Entropy’s daily driver in conservative/default setings in the above experiment. The postulated 350-400Mhz cpu load occasionally exceeds the up threshhold of 800Mhz (50%*800Mhz = 400) and once in 1000Mhz occasionally drops below dropout setting of the 1000M-hz (35%*1000Mhz = 350). (And now you know why I postulated 350-400). I have two comments about these Entropy results. The first is minor/tangential, the second more important.
1 - First comment (minor/detour) has to do with cycling between different cpu frequencies which is created by the governor (not the load). I don't think it's any problem at all, but this type of cycling is more likely to occur when the diferences between adjacent frequencies are large. For example let’s say the cpu load was rock solid pure steady state (not varying) at 250Mhz. The up threshhold for 400Mhz setting is 200 (50%*200) while the down threshhold for 800Mhz is 280 (35%*800). So we have postulated a situation where the cpu demand is pure steady state (250Mhz), yet the governor will never find a steady state solution... if it’s in 400Mhz it wants to upshift and if it’s in 800Mhz it wants to downshift. Again I don’t think it’s a problem (it's probably ok to let the two frequencies time-share back and forth) but there is a strategy to avoid it if we want to avoid it, as follows. Considering the highest possible ratio between adjacent frequencies (for these kernels) is 2.0, then we should set things so the ratio of (UpThreshold / DownThreshold) > 2.0 in order to avoid this cycling (which is probably not a problem, more later)
2 – Second comment is more important because it relates to battery usage (as I percieve it). Original postulated load that explains this experiment results is 350Mhz-400Mhz. Yet the cpu is running at 800-1000Mhz. Twice as high. That’s wasting some battery I think.
To summarize results so far, it seems to me that Zen’s kernel default thresholds have potential to waste battery due to low down threshhold (20%), which can keep it at high CPU rate forever, even though the load has decreased substantially. In theory we could be setting the cpu almost 5 times as it needs to be in the situation where steady load decreases to just above 20% of the higher level.. The Entropy’s kernel default threshhold have potential to waste battery due to the low up threshold (50%). In theory we can be setting the cpu almost twice as fast as it needs to be in the situation where the steady load increases to just above 50% of the lower level. Entropy's kernel defaults also create the potential for continuos cycling between frequencies even in the presence a of perfectly steady cpu load, since ratio up/down is less than 2 (I don’t think that's a problem, the only reason I mention cycling is because it feeds into my strategy for selecting down threshold - see below).
So what settings should we use for up/down thresholds? Actually I haven't done my complete due diligence in searching before posting this thread, if someone has a good link with recommendations and/or discussion on this subject I'd be interested. I have seen the generic xda thread on governors and I don't think it was covered there in terms of specific recommended values. Here's my thought process fwiw:. Higher is better for battery on both numbers (at some possible expense of performance). I remember seeing on other sites a default up threshhold of 95% (listed, but not discussed). That makes sense to me for battery saving... shift up at the last minute. Perhaps this high value gives small slowing of response to demand increase, but I don’t think it’s much slower (especially for rapid cpu load increase which is the most critical for response...rapid increase means short time to get from 50% to 95%... short time means not a big response penalty difference) and certainly it seems worthwhile to try to strive for an efficient operating point in long-term steady state. Additionally, we're talking about the "conservative" governor which is supposed to favor battery (we can set up a setcpu profile to invoke on-demand or interactiveX in situations when we want more responsiveness and don't care as much about battery, at least these are availble in Zen's). I don’t recall seeing any number for down threshhold, but should be high as possible again to save battery. How high? I don't know. The only way to put a limit I can think of it is to impose an arbitrary (maybe unnecessary) requirement that we don't want any cycling in pure steady state as discussed above. This means we need down threshhold at least a factor of 2 below up. So I pick 95/2, rounded down to nearest round nubmer of 45%. There may be further improvements if we drop that requirement to avoid cycling and allow even higher down-threshhold, but at least we know the down threshhold of 45% would seem to have moved in the right direction for battery from the defaults. So up/down 95/45 is my pick for now.
Using conservative governor with 95% up threshold and 45% down threshhold (still noop i/o) in above conditions on Zen’s kernel, I’m seeing frequency pattern
400, 400, 400, 400, 400, 400, 400, 400, 800, repeat
in other words mostly 400, intermittent jump to 800.
Certainly the up/down 95/45 settings for conservative governor perform better batterywise than the default settings for conservative governor given in both kernels for this one experiment. To me, it seems very reasonable to expect it to also be better batterywise accross a wide range of expected operations, but it's open to comment.
Small detour - why did we do better batterywise on Zen's on-demand default settings than on Zen's conservative default settings for this particular cpu loading?. The settings for Zen's on-demand default include an up threshhold of 95% and no down threshhold. So on-demand governor apparenlty finds some other way to shift down. Since the 20% down threshold that was causing the problem in Zen's conservative governor default settings is not present in the on-demand governor... that probably explains why the on-demand didn't get hung up at the higher level and performed better afterwards. Another thing to note, if 95% up threshhold is responsive enough for the on-demand, it should surely be responsive enough for the for the conservative...supports the previous sugestion to increase conservative up threshhold to 95%.
CONCLUSIONS:
There is only thing in this entire thread that I am completely 100% positive about, and it is that Zen and Entropy know lightyears more about this stuff than me. In fact, that is the very reason that I was extremely careful to record the as-found default settings in order to preserve any intelligence that went into those defaults before I started tweaking.
So I can reach one of two conclusions:
#1 – I am completely misunderstanding how this conservative cpu governor works
or...?
#2 – The developers never intended for the “default” values to be used, instead they envisioned the users would adjust them as needed.
In the event that #2 were correct, then it would seem logical for battery-concious users to tweak these up/down threshhold settings of the conservative governor. My thoughts would be to set them to 95/45 by the logic above.... may or may not be considering all relevant factors. I'm open to thoughts and comments....

In the above analysis, I have assumed that power consumed by the cpu can be predicted from the cpu frequency (for a given voltage setting of course).
I now believe that assumption might be incorrect.
The reason I believe it is false is a result of another experiment I just did.
I set the cpu governor to performance to maintain constant 1200Mhz.
Then I looked at the cpu power usage trace in "Power Tutor" program.
I expected to see power attributed to cpu usage as constant, but it was varying up and down.
And by moving the homescreens around, I could create a dramatic and predictable increase in power usage of cpu (as indicated on Power Tutor).
All of this change in power consumption of the cpu occurred while the cpu governor was in performance mode with cpu frequency constant at1200Mhz.
I didn't expect that. I can't really explain it (can anyone else?). But clearly there is more to the story than I thought (assuming that the cpu power usage reported by the Power Tutor is correct, which I'm not sure of either).
To evaluate the battery friendliness of variouis governor settings, it might be more useful to watch the power tutor results when performing the above experiments, instead of just watching the cpu frequency as I did before.

Over my head...

How does the battery cycle pan out?
It would be nice if you or someone else had a spare phone to test this battery consumption theory.
I would wonder if the report of consumption is also correct.
The bottom line that I would be interested in seeing is how long can the phone, running a certain kernel and governor, last.
For example: Charge to 100%. Take off charger. Wifi off, Cell data off and in Airplane mode (removing signal variable).
Then run kernel with governor - record the battery duration.

e.pete - nice work! I appreciate your empirical approach to this topic.
I can add the following: you have described accurately how the conservative governor works. For OnDemand, the governor behavior results in the CPU at max under load and minimum when idle, with a smaller amount of time being spent at the steps in between based on thresholds. On my phone today with OnDemand, for example, I'm at 1600mhz 6% of the time, 100mhz 5% of the time, and 800mhz 2% of the time. Deep sleep is 83% and the other CPU frequencies are all below 0.5%.
In general use, conservative should be kinder to the battery and to the hardware. The recommendations I have seen for Linux platforms is to use conservative where battery life matters and ondemand when there is a constant external source of power (i.e. PC or server). Of course, actual use determines how the governor performs. Most smartphones have a lot going on even when the screen is off. A good indicator of average CPU use over the course of a day is CPUSpy. This app, combined with a decent battery monitor can help tell the story from a macro/whole system perspective over time. On the "be kind to hardware" topic, conservative should increment and decrement to adjacent frequencies based on load. This behavior might be happening too fast for SetCPU or other realtime monitor to capture..that's where CPUSpy can show what is happening over a larger period of time. These more gradual transitions may result in less wear and tear on the phone hardware, but I have not seen any significant evidence that this is a factor in the usual life span of a smartphone. (On the flip side, setting the governor to performance and OC to max setting...that is NOT recommended and could harm the phone).
That said, the two kernels you tested have the following default characteristics:
Entropy DD - Conservative/BFQ - Optimized for stability and battery life
Infusion (Bedwa/Zen) - OnDemand/CFQ - Optimized for performance
The Infusion kernels do not include optimization settings for conservative. As you surmised, the expectation is that if you are going to change these settings you have some idea of what you are aiming for and will adjust accordingly.
If battery life is your aim, I've found that the best savings are realized in optimizing transition to sleep when the phone is not being used, minimizing the number of apps that attempt to keep the phone awake, and being selective in your use of wifi and data radios (although too much mucking around with this last option can lead to triggering some of the known bugs in these kernels which manifest as a higher than normal Android OS or Dialer/RILD drains - as seen on the standard battery usage screen in Settings).
On this last topic, there's another thread (which I see you have visited) which covers discussion and work on these known battery drain anomalies: http://forum.xda-developers.com/showthread.php?t=1408433
Here is some additional information on governors courtesy of Big Blue... http://publib.boulder.ibm.com/infoc...?topic=/liaai/cpufreq/TheOndemandGovernor.htm
And a bit more info ... https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling

Truckerglenn said:
Over my head...
Click to expand...
Click to collapse
:what: I'm so glad there are people much smarter then myself here. Great work electricpete :thumbup: even if I followed about half of it
Sent from a de-FUNKt Infuse

Pete - Here's a link to a thread that has a lot of information about governors, i/o schedulers, tweaks, scripts, and kernel objects:
http://forum.xda-developers.com/showthread.php?t=1369817

Thanks everyone, a lot of good info.
Especially Zen, very useful info and links.
It was a very interesting comment about certain governor strategies being hardware unfriendly if they jump increase the cpu from min to max.
I never realized that was a factor (only thought the max speed was important).
But it definitely sounds plausible. Maybe (?) the rapid temperature increase causes uneven temperature (cpu gets hot before attached plate gets hot) and therefore uneven thermal expansion, which causes mechanical stresses. I can imagine there are other subtle aspect of the cycling up/down that can be important. If you have any more info or links on the effects of cpu governor strategy upon hardware life readily available, I'd be very interested to hear it. (If not readily available, that's fine too, I will do some googling).
I did find this link which suggested it's better for the hardware life to run at 100% (I guess for us that's 1200Mhz) than it is to cycle up/down. It's not written about phones but about PCs. There might be some differences in the technical aspects. There are of course big differences in the priorities for PCs... they don't care about power usage as much as phones do, and pc users probably expect a longer life than phone users do.
http://www.overclockers.com/overclockings-impact-on-cpu-life/
Thanks again.
I will report back if I get some free time to continue experimenting... maybe this weekend.

Primary consideration (as you've noted) with smartphones is battery conservation. ARM processors are engineered to operate at multiple frequency steps, and to turn off where possible. Without this capability phones would need a much higher capacity battery. As for PCs, current processors include frequency stepping technology to reduce power consumption and heat, and perhaps extend life by keeping temps lower.
The main conclusion of the article you referenced (which is 13 years old, btw, but does contain a wealth of good foundational information) is that heat is the primary enemy. This is a major factor with smartphones as they have limited ability to dissipate heat. An Infuse running at 1200mhz (or 1600mhz OCed) confined to a purse or pocket, or (as reported in these forums a while back) under a pillow gets hot very quickly. This will lead to conditions that will harm the phone. At one time, my phone had an error condition causing the Dialer to go crazy (rild process) and peg the CPU at 100% for an extended period of time, while the phone was also plugged into a charger (thus heat from the charging process too). The end result of this was a temperature that tripped a heat sensor threshold, causing the phone to shut itself off. So there are, at least, limited protections against extreme events.
As I noted above, I've not seen any evidence that the normal (or even OCed) frequency stepping that occurs with smartphones leads to failures within the normal in service period for these devices - 2 to 4 years in most cases. Running at 100% all the time may put your phone's health at risk and will definitely impair your battery life.

Zen - Good points. One thing I do take away from the article (along with your comments) is the cuumulative effect of cycling, So when I settle on up/down threshholds, I may try to avoid putting them too close together in order to avoid extra cycling (keep Max/Min threshhold ratio >2). Although I do realize these particular cycles between two adjacent frequencies are not as bad as bad as the cycle between min and max frequency.

more test results
I have completed some testing using PowerTutor and results reported in attached spreadsheet.
I would say the results only muddy things further. Don’t read any further if you don’t have a tolerance for ambiguity.
SETUP (common to all tests)
In all tests, I had similar setup as in the original post: 1 channel of “relax and sleep” running to create a constant cpu load, and all other continuous-run programs turned off except power tutor.
Some other details common to all tests: Tasker off, Wifi off, data off, Power Tutor on
No uv
Noop I/o governor used throughout.
WHAT CHANGES BETWEEN TESTS:
See the spreadsheet, tab labeled “summary”.
The things that changed between tests are in rows 3 thru 8, labeled “Tested Configuration”
As you can see, between tests, I varied the Up threshhold and Down threshhold. I varied the kernel. I varied the governor (mostly conservative, but performance used).
WHAT WAS RECORDED DURING EACH TEST:
1 – Recorded power usage of CPU, LCD, Audio as reported in Power Tutor over the course of one minute. I converted them to battery %/hr (conversions shown in tab “Notes”) and listed them in rows 12-14
2 – Recorded the actual cpu frequencies seen in setcpu “home” screen, similar to original post and listed these in row 15. I attempted to guess the average frequency over time and put this in row 16.
3 Rows 18-23 are the Quadrant results for the six categories that Quadrant reports (yes, I know people don’t like Quadrant, just recorded as a datapoint)
WHAT PATTERNs EMERGE:
1 – Entropy’s DD and Zen’s Infusion-A use comparable power (as reported by Power Tutor) in this particular experiment.
2 – Zen’s Infusion does better on quadrant score in this particular experiment, when both are set at the same governor configuration (100-1200, conservative), . Not surprising since Zen said he has optimized for performance.
3 – How does the governor frequency affect power usage? This is the muddy part. There is no doubt that if we blindly take the data at face value, then there IS a correlation between cpu frequency and power attributed to the cpu by Power Tutor. However the correlation that emerges from the data is in the opposite direction from what anyone in the world would think: this data suggests that increasing CPU frequency causes decrease in power consumption reported by power tutor. See tab labeled “chart 1” for graphical depiction of this result.
As you can see in the graph, there is not a random spread of results (as would be the case if random unacconted-for errors were at work). There is a definite correlation. What it suggests perhaps is that there can be a systematic error in the way PowerTutor measures power that depends on cpu frequency.... in other words the error itself (between measured and actual) somehow depends on cpu frequency.
So, I am just reporting some results. I am definitely not suggesting anyone overclock to save power (that would be truly bizarre and I’d probably be kicked out of xda for suggesting something so silly).
On the other hand, as stated in the 2nd post of this thread, I’m still very leery of using cpu frequency as an indicator of power that cpu is drawing... because there is just too much going on inside that black box that I don’t know about. For one thing, the cpu itself may draw different amounts of power at a given frequency depending on it’s loading because the registers may not be doing anything at low loads. For another thing, there are a lot of other things in the phone (like RAM, bus) that may draw some power but probably get lumped in with the reported cpu power in Power Tutor and others. Perhaps the cpu is somehow more efficient at interfacing with these others parts of the system when cpu is at high speed, enabling it to reduce the power they draw. The point is, it’s a lot more complicated then I assumed in my first post.

I have heard Entropy mention that before changing kernels we should always reset UV settings (and reboot) and reset other cpu related settings (Fmin and Fmax I assume).
I would like to add another item: always uninstall setcpu before changing kernels and reinstall it after you change.
The reason: I have seen some very weird results of setcpu when I left it installed in between swapping kernels. Like for example cpu running at 1600Mhz even though Fmax is 1200Mhz and there are no profiles allowing 1600. Those weird results are not included in the above data (I observed the frequencies during each trial as reported in the spreadsheet).

Power Tutor has a great interface and very detailed stats available. Seems to have great credentials based on their website.
But I can only conclude we can’t trust it for our particular phone because of results above (power draw goes down as cpu speed goes up) and some other results I have seen (it seems to suggest that power used by my display does not change depending on dark/light backround, and also seems to suggest that power used by the phone does not change when I change the volume of music playing).
So, I’m looking for another way to be able to track power usage closely.
I kind of like qkster’s idea to just watch the battery go down.
I’d like to try to automate that using Tasker. I can write a program which will help me build a log of power usage.
The interface will be:
push a start icon and it prompts me to enter description of conditions that will be tested
wait some period of time (this is the constant-load test period that we're evaluating...may be listening to mp3)
push a stop icon and it prompts me for comments about anything that happened during the test.
At time of pressing the start icon, it will also record from the system:
1 - clock time (in seconds)
2 - voltage in millivolts to 4 digits of resolution (like 3784 millivolts)
3 - battery life remaining in percent to 2 digits of resolution (like 43%)
The same info will be recorded from the system upon pressing the stop icon.
All this info will be appended to a logfile and we can compute drain based on change in battery divided by change in time.
I can get these voltage and % life stats using the method suggested by Brandall’s tutorial here:
http://tasker.wikidot.com/using-linux-shell-with-tasker-for-a-technical-battery-widget
I couldn’t get the grep command to work, but I can still extract the required voltage and percent-life-remaining from the Battery sysdump using the tasker variable splitter command (I’ve already got that part programmed).
No-load voltage has a roughly known relation to battery life, but there’s also the matter of voltage drop accros the internal battery impedance that varies with load at the time of the measurement, so we don’t see no-load voltage, we see something lower which makes the whole thing somewhat variable.
Percent Remaining is the exact thing I want. But it is only given rounded to two digits, (43%). If I wanted to do a trial run listening to a 5-minute MP3 draining something like 12% per hour, the battery drop during that that 5 minutes will be only around 1%... the difference between two kernels or cpu frequency settings will be only a very small fraction of that 1%, so comparing the start and stop values which are both rounded to 1% would introduce an enormous error compared to the thing we're interested in. I can surely reduce that error by working with longer times, but that starts to become a PITA. That may end up being the only solution, but if there's any way to avoid it I'd like to be able to gather data in shorter chunks.
Which leads me to a QUESTION:
Does anyone know whether there is any way to retrieve or estimate “battery % remaining” with greater resolution that two digits (ie 43.26% instead of just 43%)?

unintended consequences from changing up threshhold
I used the following setup for almost a month:
Zen’s Infusion A Kernel (with my stock GB), conservative governor
UpThreshold = 95
DownThreshhold = 45
Only twice during the month, I saw the following:
Received a phone call. I could see the name of the caller. I couldn’t hear the caller. When I finally got hold of them later, they told me they could hear me even though I couldn't hear them.
That was very tough to figure out because it only occurred on two out of probably 30 or 40 phone calls received in a month.
The two phone calls did originate from cell phones in the same geographic area (near my work, an hour away from my home).
Then I had a breakthrough when I set up my work voicemail to automatically call my Android phone. Almost every time it called, the problem appeared (I couldn’t hear the robot voice telling me I had a message).
I kept leaving myself messages to reproduce the problem and narrow it down.
I found out it only occurs when my phone is asleep at time of the call (doesn’t occur if phone is awake at time of the call).
I removed my UV and problem continued.
I adjusted my governor and could make problem go away.
I narrowed it down to the up threshhold.
Repeatable with 95/45 up/down, the problem occurs.
Repeatably with 80/45 up/down, the problem does not occur.
I have gone back and forth between those two settings at least four times and each time it confirms the symptom is directly related to the governor setting.
Exactly why that is I’m not sure. Maybe the cpu is to slow to wake up to handle the call? Sounds kind of hokey, but I guess it doens’t really matter.
The bottom line for me: 80/45 is a great place for me to stay. Eliminates the “can’t hear caller” problem and still does pretty good at preventing cpu from going to high frequency when listening to my relax and sleep program for long periods of time.
If anyone has gone to 95/45 based on my recommendation, you might rethink it, especially if you see unusual behavior.