[AOSP/CM7 Kernel] 11/01/2012 ManU 2.1 - 2.6.35 based battery efficient kernels

Which version do you use?

  • Total voters
    133
  • Poll closed .
Search This thread
By:
Advanced…
L

Latty

Senior Member
Jun 28, 2007
741
102
Dr Byte said:
Maybe it's time to try that IceCream Sandwich ROM now?
Click to expand...
Click to collapse

I'm definitely eyeing the new CM9 builds of ICS too :p

Anyways, felt like I should post my brightness settings too. Mine are a little dimmer for slightly better battery savings, but I find it's 100% readable:

Moving average filter: enabled
Window length: 30s
Reset threshold: disabled
Sample interval: 1s
Custom light levels:
0-39 35
40-199 45
200-299 50
300-399 55
400-999 60
1000-2274 75
2275-2999 100
3000-infinity 255
[Buttons on only for the 0-39 level]
Allow light decrease, hysteresis: 70%
 
  • Like
Reactions: tlexul
danarama

danarama

Senior Member
Aug 22, 2010
31,277
18,811
Oxenhope, West Yorkshire, UK
So far so good. One issue for me (not kernel related) is that I have changed work place and mobile signal is not great, draining more power. Going to work on a tasker profile for that. It just means its harder to compare.

I have seen some 4mA's though which is good. Definitely haven't found a reason to crawl back to 1.4 yet, like I usually do ;)

Thanks for keeping this kernel alive EV!
 
  • Like
Reactions: EViollet
D

Dr Byte

Senior Member
Oct 22, 2010
205
104
erklat said:
I think you could make sixteen if you enable airplane mode.
Click to expand...
Click to collapse


<SMIRK>
As of this morning, I can confidently predict at least two weeks, if not four
</SMIRK>

I did a calibration run on my "new" battery last night, as it was reporting 0mAh at about 9%. The App left the phone in airplane mode afterwards, and it was still there after the reboot... so it stayed that way overnight. For a moment, I thought I'd made another breakthrough, in my bleary-eyed condition. Never trust such thoughts :)

1mA almost every sample, with a very few exceptions. Which (in addition to the previous logic) nails the kernel and "just being booted and in Deep Sleep" as 1mA. 2-4mA for the same plus 3G voice - 95% of the time, it's 3mA. So 3G voice is consuming 1-3mA on top of the "1mA minimum life support" level.

However, using airplane mode is just the same as turning the phone off, except it uses battery. The phone does nothing useful for me (noone can make that emergency call to wake me up) so the point is moot.

I don't browse or read emails while I sleep, nor do I want to be woken up because someone spammed me. The only thing I could possibly use it for in "airplane mode" is as an alarm clock, and I *have* one of those. So I'd turn it off entirely before using that. The phone was programmed not to give me alerts during 'sleep time' anyway, so why bother polling for mail in the first place? Just wastes power.
 
Last edited:
erklat

erklat

Senior Member
Nov 14, 2010
2,444
455
Dr Byte said:
/snip
Click to expand...
Click to collapse

I meant that would further complement screen off time nicely. Those pics you posted could serve as a viable results in 'who's using phone the least' contest. On the other hand on any rational level we could possibly elaborate about battery life, they are useful as chocolate teapot.

SwiftKeyed from my HTC Desire using XDA App.
 
yreham

yreham

Senior Member
Sep 16, 2010
631
84
yerres
I can't get past the second level of brightness 300/399/55 does not register for me

Sent from my HTC Desire using XDA App
 
m0nn3

m0nn3

Senior Member
Jan 23, 2009
229
21
Hello, with which program can i change the light Sensor Level?
Tanks for help. The Kernel is verry good!!

Sent from my HTC Desire using XDA App
 
L

Latty

Senior Member
Jun 28, 2007
741
102
I updated my custom voltages in case anybody's interested. These values are lower than Dr Byte's, but are stable for me personally. I had very sporadic reboots with my old voltages, so feel free to try these (as attached). Script enables EViollet's low WiFi power option as well, although I don't see a discernible difference.

Code: 
#!/system/bin/sh
# Latty's custom voltages, 2nd edition

# Set our voltage table
if [ -e /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs ]; then
	echo 128000 900 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 245000 900 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 384000 925 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 422400 925 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 460800 950 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 499200 975 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 537600 975 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 576000 1000 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 614400 1025 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 652800 1050 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 691200 1075 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 729600 1100 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 768000 1125 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 806400 1175 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 844800 1200 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 883200 1200 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 921600 1225 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 960000 1225 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 998400 1225 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 1036800 1225 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 1075200 1225 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 1113600 1250 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 1152000 1275 1350 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
	echo 1190400 1275 1350 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
fi

# Enable low power Wifi mode
if [ -e /sys/module/bcm4329/parameters/wlLowPower ]; then
	echo 1 > /sys/module/bcm4329/parameters/wlLowPower
fi
 

Attachments

  • havs_init-script_latty2-signed.zip
    156.5 KB · Views: 31
  • Like
Reactions: jdstrydom, kostelo and n0j0e
danarama

danarama

Senior Member
Aug 22, 2010
31,277
18,811
Oxenhope, West Yorkshire, UK
interesting. I went for:

Code: 
sleep 30

echo 19200 875 950 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 128000 875 950 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 245000 875 975 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 384000 900 1000 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 422400 925 1025 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 499200 950 1050 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 614400 1000 1150 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 729600 1050 1175 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 844800 1125 1225 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 921600 1150 1275 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 998400 1150 1275 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 1036800 1175 1275 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 1075200 1200 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
 
echo 1113600 1225 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs 

echo 1152000 1250 1300 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

echo 1 > /sys/module/bcm4329/parameters/wlLowPower
 
D

Dr Byte

Senior Member
Oct 22, 2010
205
104
Second calibration run on new battery

Just completed a second calibration run on the new battery. The result is pretty annoying... it peaked at 1310mAh. That's 91% of "new" capacity, after a handful of cycles (no more than 50, probably 30 or less).

So use this to "calibrate" the power usage in my earlier experiments; 9% is really 0%. 100% is really 1310mAh.

In all my 30+ calibration runs, I've never seen the age set properly.
Whenever I set the age to the right % value, I get a charge that is x% of x% of the full40 value, NOT x% of full40. ie, 91% of 91%. So I will just live with knowing that 0% for me is 9% or 11% on the original battery.

The ACR adjustment in the Calibrator app does nothing for me (it worked 2-3 times at most) nor does pushing a value under 10 in to register 10. This is probably why ACR doesn't work (it pushes 1). However, I found that a value of 10 does work. So don't give up until you try that.

Despite what one poster commented, the experiment was not about "who can use their phone the least" but about quantifying the power drain of various elements by removing as many variables as possible. We now know how much this kernel uses in airplane, 3G voice, and full-smartphone modes.

Yes, it was annoying to have to leave the phone "dark" for a week, but someone has to make sacrifices in order to build up a baseline.

I'll probably continue on this exact configuration until CM9 or until the Galaxy Nexus hits a reasonable price - probably in about a month when the 32G version hits the market.

Somehow, I don't think my next phone will be a HTC. They cut too many corners on the Desire. The GN isn't much better, but at least they cut different ones :)
 
  • Like
Reactions: EViollet
E

EViollet

Senior Member
Aug 9, 2010
1,851
715
Google Pixel 5
Hi.
This is rather off-topic but nevertheless interesting. How do you calibrate your battery? I use this method ( http://forum.oxygen.im/viewtopic.php?id=723 ) and it works quite well.

Regards


Dr Byte said:
Just completed a second calibration run on the new battery. The result is pretty annoying... it peaked at 1310mAh. That's 91% of "new" capacity, after a handful of cycles (no more than 50, probably 30 or less).

So use this to "calibrate" the power usage in my earlier experiments; 9% is really 0%. 100% is really 1310mAh.

In all my 30+ calibration runs, I've never seen the age set properly.
Whenever I set the age to the right % value, I get a charge that is x% of x% of the full40 value, NOT x% of full40. ie, 91% of 91%. So I will just live with knowing that 0% for me is 9% or 11% on the original battery.

The ACR adjustment in the Calibrator app does nothing for me (it worked 2-3 times at most) nor does pushing a value under 10 in to register 10. This is probably why ACR doesn't work (it pushes 1). However, I found that a value of 10 does work. So don't give up until you try that.

Despite what one poster commented, the experiment was not about "who can use their phone the least" but about quantifying the power drain of various elements by removing as many variables as possible. We now know how much this kernel uses in airplane, 3G voice, and full-smartphone modes.

Yes, it was annoying to have to leave the phone "dark" for a week, but someone has to make sacrifices in order to build up a baseline.

I'll probably continue on this exact configuration until CM9 or until the Galaxy Nexus hits a reasonable price - probably in about a month when the 32G version hits the market.

Somehow, I don't think my next phone will be a HTC. They cut too many corners on the Desire. The GN isn't much better, but at least they cut different ones :)
Click to expand...
Click to collapse



Envoyé depuis mon GT-i9100 avec Tapatalk
 
D

Dr Byte

Senior Member
Oct 22, 2010
205
104
EViollet said:
How do you calibrate your battery? I use this method ( http://forum.oxygen.im/viewtopic.php?id=723 ) and it works quite well.
Click to expand...
Click to collapse

Same program, but from the original source, http://xdaforums.com/showthread.php?t=765609 here on XDA :)

I know I'm doing it right, it's just my hardware won't play ball. I've run it for the last time now, as a precursor to trying ICS for a few days next week. Your kernel supports calibration, but I can't count on the hodge-podge of ICS kernels to do the same.

(And no, it isn't your kernel: I got the same results on stock CM7.0.3 and 7.1.0 kernels.)

It all seems to work fine until the battery is full; it suddenly jumps from 13xx to 14xx mAh and 9x% to 100% and doesn't set the age. I'm done trying!

Just unlucky, I guess. Two strong, bud dud batteries or one dud phone! The battery logic, like the touch panel and memory are the Desire's worst enemy.

I can also report that I've had no further startup glitches since shoving that script in init.d -- the voltages are deliberately very conservative, and are only used until IntelliControl comes along later in the process. However, it always gets there now, in a very deterministic fashion. The default voltages make it a bit of a lottery, based on temperature. My Mileage definitely varies, as they say!

If anyone is having trouble booting the 2.0.5 kernel (or .03 or .04), it's worth having that .ZIP on the SDCARD in readiness for "recovery." If the phone starts, but is erratic, laggy, or crashes, apply the .ZIP and try again. It's a magic bullet for me.
 
kostelo

kostelo

Senior Member
Apr 28, 2011
540
276
Sorry for being a bit off-topic, but I 'm in the process of calibrating my battery with the tool that Dr.Byte mentioned a couple posts above. My question is:
Do I have to do this type of calibration every time I flash an update in CM or another kernel let's say, like wiping battery stats in recovery or is it enough for it to be done just once and calibration still remains?
Thanks in advance.
 
danarama

danarama

Senior Member
Aug 22, 2010
31,277
18,811
Oxenhope, West Yorkshire, UK
I cant pinpoint exactly when it needs to be done, but the effect of my battery calibration has been lost since doing certain things that you mentioned in your post. Im glad though. For some reason i just didnt adjust to my desire actually shutting down at 1%
 
D

Dr Byte

Senior Member
Oct 22, 2010
205
104
kostelo said:
Do I have to do this type of calibration every time I flash an update in CM or another kernel [...]
Click to expand...
Click to collapse

In an effort to stop the off-topic questions, No.

You need to calibrate when your battery life is exceptionally short, or when the phone shuts down well before 0%. If it is exceptionally short, it may simply be worn out, but one way to check is to rejuvenate it with a calibration run. If it still runs short, you should know from the log. Look at the stored mAh just before it jumps to 100%. That should tell you what the capacity is now.

The basic rule of thumb is that it should be showing about 3.5v when it's about to go into a death-dive and die in the next half-hour or so. At 3.7v (3700mV) it should be at about 30-40% remaining (about 400-450mAh).

The goal of calibration is to have the battery read "0mAh" at 3201mV at the same time. Preferably 3416, since the run time between 3201 and 3416 is measurable in minutes, but the lower you run the battery, the more you wear it.

You need a kernel with the right driver (such as CM6.1 and above, or ManU of course) in order to run the app, along with good reflexes.

Generally speaking, the battery loses 0.78% capacity every month or so of use. If you haven't run a calibration in the last six months, it's probably overdue.

If you let the battery run dead flat, it will reset the "age" to 94% when you next charge it - charging the phone while off does this. It's annoying. You then have to wait until it's ready to boot, and use the app to reset the age to 100, 96 or whatever your KNOWN age actually is. In my case, that's 88% and 91%. But since my phone is a *&^*(&^, doing so actually reduces the maximum charge because calibration doesn't work properly; it only seems to save half the data. So I have to simply remember that the age should be 100% but that "Flat - 0% charge" is actually around 10% on the battery scale.

The ManU kernel can't be at fault here, because it uses the same mechanisms to read and write the various other values from the battery driver. That, and CM7.x doesn't work, in exactly the same way. Since many others' phones calibrate fine, it must be my hardware that is at fault.

You do NOT need to run a calibration except when the capacity is wildly wrong or the phone shuts down before reaching 15% or if the "3700mV" level is wildly different from 400mAh remaining.

This is NOT "battery stats" from recovery (which correlates the battery voltage and remaining mAh) but a function of the chip in the battery - the two are unrelated mechanisms. This procedure calibrates the "zero point" and the "100%" point of the battery based on current flow and voltage as it charges.

It is probably wise to reset the battery stats as well when you've done a successful calibration - but it doesn't MATTER. It'll be the same thing as swapping to a different battery - the OS battery scale may read slightly off what the calibration app reads for a while, but it will adjust after a few charge/discharge cycles. Clearing "battery stats" in recovery will simply speed up this process. Calibration configures the FIRST ORDER estimation of battery charge. "Battery stats" (OS concept, what's in the notification bar) is a SECOND ORDER estimation based on the first.

For any further information, see the thread above. Also any further questions should go there.

We now return you to our regularly scheduled programming :)
 
Last edited:
  • Like
Reactions: fossean and kostelo
You must log in or register to reply here.

Similar threads

A
  • Locked
[ROM-FROYO AOSP] OpenDesire v3.6.1 (720P | 2.6.34.5 SVS KERNEL | 1305mhz) (26/08)
Replies
12K
Views
2M
joshkoss
joshkoss
R
  • Locked
[ROM-FroYo AOSP+CyanogenMod] DeFroST 6.1a 12/12: HAVS/FM/MODS/OTA
Replies
18K
Views
4M
J
jean marc
baadnewz
[ROM][15/09][STABLE][Sense2.1+3.0GB]InsertCoin CM7 HBOOT/STOCK 1.1.4-Kernel Update #2
Replies
11K
Views
3M
A
atlantisu21
robocik
[ROM][Sense 2.1+3.0mix][02 June]RCMix S v2.0 Evolutionary Sense
Replies
13K
Views
3M
ze7zez
ze7zez
xavierjohn22
  • Poll
[ROM][MIUI-XJ] Mar 31 - 2.3.30 GB 2.3.7 EN-MULT+OTA+CM+Updater|D2EXT X-PART|A2SD+|D2W
Replies
19K
Views
3M
rmg2
rmg2

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 70
    E
    EViollet
    I'm listing here 2 different 2.6.35 based kernels :
    The 1.x series exist for Froyo and Gingerbread. They are based on a 2.6.35.8 linux kernel. They are CFS only (no BFS version), and forked from Richard Trip's kernels (https://github.com/richardtrip/cm-kernel)
    The 2.x series are for GingerBread only. They have CFS and BFS versions. They are based on a 2.6.35.13 kernel and forked from _thalamus' kernels (https://github.com/thalamus/kernel)

    All of my kernels have the following characteristics :
    • Go from 128Mhz to 1190Mhz. If your phone crashes at those speeds, then don't use them. Not all phones are equal and they won't all accept these frequencies.
    • The noop IO scheduler is defined as default. I think that all the other schedulers are unnecessary with flash disks. They are too complex and consume more CPU for the same result.
    • Two-way call recording thanks to avs333 (http://xdaforums.com/showthread.php?t=993793)

    The following characteristics are available in some kernels :
    • BFS. Brain F*ck Scheduler. Only available on the 2.x kernels.
    • CFS. Completely Fair Scheduler. Choose which scheduler suits your needs the best. Check here for a description of both : http://www.stackednotion.com/2010/06/04/what-are-bfs-and-cfs
    • AXI. AXI optimisation is available in some kernels : http://xdaforums.com/showthread.php?t=665110. When it is enabled, the AXI bus speed is lowered to 64Mhz instead of 128Mhz when the screen is off. In the other kernels, the AXI bus speed is throttled according to the current CPU speed.
    • HAVS. Hybrid Adaptive Voltage Scaling. Dynamically changes the phones voltage. Should use up less battery than SVS. In comparison with Richard's original kernel, I upped the maximum voltage in the overclocking frequencies to 1350mV instead of 1300mV because it didn't seem enough (at least on my phone). I also set the minimum voltage to 900mV. I feel it's a good compromise between 875 and 925... ;)
    • SVS. Static Voltage Scaling.
    • On the ManU kernel series, it is possible to change the voltages table on the fly using the following method. On the SVS kernel, the following method was used : http://xdaforums.com/showthread.php?t=821372. See the post below for a simpler description of this

    The following kernels are based on an OLD version of the Android kernel. The main advantage is the battery usage : it's very low compared to the latest kernels. The source code is available at http://github.com/eviollet/cm-kernel.

    As of versions 2.1, SVS versions are no longer supported. Only HAVS versions are available.

    2.6.35.13 ManU-Version 2.1 - Gingerbread ONLY
    Gingerbread-HAVS-CFS ----------------
    Gingerbread-HAVS-AXI-CFS ----------------
    Gingerbread-HAVS-BFS ----------------
    Gingerbread-HAVS-AXI-BFS ----------------

    2.6.35.8 ManU-Version 1.4
    Froyo-HAVS-CFS ---------------- Gingerbread-HAVS-CFS ----------------
    Froyo-SVS-CFS ---------------- Gingerbread-SVS-CFS ----------------
    Froyo-HAVS-AXI-CFS ---------------- Gingerbread-HAVS-AXI-CFS ----------------
    Froyo-SVS-AXI-CFS ---------------- Gingerbread-SVS-AXI-CFS ----------------

    Many thanks to Richard Trip for helping me out with the 1.4 kernel, and to thalamus for help on the 2.0 kernel.
    View
    15
    E
    EViollet
    Version history :

    11/01/12 ManU-V2.1:
    • HAVS only. The voltages run from 1000mV to 1350mV which means that they should be stable on all phones. Feel free to play around with the voltages using a script, or IncrediControl
    • LED notification should now work on GingerVillain 2.8 and upwards thanks to Richard Trip.
    • Added smartassV2, thanks to erasmux.
    • Fixed VPN on MIUI (and perhaps other ROMs) thanks to mondilv@xda
    • Fixed "adb devices" id name bug
    • Fixed battery calibration
    • Added lazy governor thanks to Ezekeel : http://xdaforums.com/showthread.php?t=1276092
    • Added system files to display the current state of the vdd levels
    • Optimized onDemand governor: ondemand: Remove the iowait-is-busy tunable code. Thanks to someone (I don't know who, sorry...)
    • Changed the Lazy governor default values to the ones recommended by Dr Byte (80/30000)
    • Added debug information in the AVS module when voltage changes occur. Especially if they fail.
    • Added working VPN back again (credits go to mondilv)
    • Started changing the AVS vdd changing logic. Now only changes the frequencies that are directly impacted.
    • Add WiFi screen off power level switch
    • Fix sound issue when using voice commands when bluetooth is connected (??)

    28/05/11 ManU-V2.0:
    • kernel rebased on V2.6.35.13

    07/04/11 ManU-V1.4:
    ManU-V1.3:
    • added CPU Vdd levels sysfs interface for HAVS kernels as well
    • changed the audio settings
    • changed the modules location
    ManU-V1.2:
    • added CPU Vdd levels ("undervolt") sysfs interface for SVS kernels (http://xdaforums.com/showthread.php?t=821372)
    • fixed video recording crashes
    • updated most of the drivers to most recent versions
    • changed the kernel name in the Android about box (now reports version number as well)
    • changed the zip flash to (hopefully) fix problems when flashing on phones with bad sectors
    • fixed some kernel versions having CPU governor performance by default
    ManU-V1.1:
    • fix battery charging issue between 90% and 100%
    • disable 128Mhz when the screen is on, in the AXI kernels
    ManU-V1.0: Kernel based on an old version (approx. October 2010)
    V1 : Fix for IPV6 on MIUI. 6.1 and 6.1se kernels
    V0 : First version : 6.1 and 6.1se kernels

    FAQ:

    • How do I know which version I'm running? : Look at the "About the phone" screen at the kernel version. It should display which options you're currently using.
    • Which kernel do you recommend? : I'd say ManU-HAVS-AXI-CFS. On my phone on idle, I'm using up approx. 2-3ma/h instead of 6-7 with the default kernels with this kernel. So I'm very happy with it, and am currently using it as my main kernel. If you do any testing, feel free to tell us about your own experience! :)
    • Do you recommend any settings with SetCPU? : I currently use 128-440 conservative governor when the screen is off, and 128-1130 interactive when the screen is on and it gives good results.
    • After some time my phone feels sluggish. Why? : Apparently there seems to be an issue when switching governors, especially with "interactive". I recommend not to use it, or stick with it and don't change. This may be fixed in the future.
    • *Something* doesn't work with this kernel. Can you fix it? : First of all, my knowledge of the current state of the kernel is very limited. I just changed a few things in the DeFrost kernel to suit my taste and thought that this kernel may be of interest to some other people. If you have a problem, try explaining it, and give the following details : Name and version of your current ROM, previous kernel that worked, which version of the kernel you are now trying and any other details that may be of interest. I can't guarantee that I'll be able to fix it, because I don't develop the kernel, but I can try to help.
      If you have a problem, try disabling the 128Mhz and overclocking options. They may be the culprits.
    • If 128Mhz saves battery, why isn't it enabled by default in other kernels? : Good question, and I don't know exactly. why. Apparently it causes issues on some phones. So, if you have a problem, try disabling 128Mhz. Also, 1190Mhz is a very high value and can also cause issues. So try lowering the maximum frequencies if you have issues.
    • On which ROMs do these kernels work? : 1.x series work on DeFrost 6.1, probably earlier versions as well, MIUI and GingerVillain, Redux, and probably others. The 2.x series only work on GingerBread.
    • On which ROMs do these kernels NOT work? : Oxygen 2. I recommend directly using _thalamus' kernels for Oxygen 2 : http://thalamus.ineige.org/kernels/2.6.35/

    Here is a description of how to use the sysfs interface to configure voltage levels :
    For SVS kernels, the file name is "/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels" and on HAVS kernels, the file name is "/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs".
    This file is used to read the current voltage state of write new voltage settings.
    How to read the settings with the HAVS interface:
    connect to the phone using a terminal, or adb shell, and type "cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs". The phone will display the frequencies and the associated high and low voltages.
    If you want to change the voltages, just send "echo 128000 875 1000 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs". This will configure the minimum voltage to 875mV and max to 1000mV for the 128000 frequency.
    Another useful command is "echo -25 +25 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs". This will lower the minimum voltage by 25mV and raise the maximum voltage by 25mV on ALL frequencies.

    As for the SVS interface, the commands are similar.
    "cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels" will display the frequencies and the voltages, and "echo 128000 900 > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels" will set the voltage to 900mV when the CPU is at 128Mhz.

    Please note that voltages are multiples of 25mV. So, accepted values are 800, 825, 850, etc. Other values will be rounded.


    There is also the possibility to visualize how the kernel is managing the HAVS voltages by using the following system files: /sys/devices/system/cpu/cpu0/cpufreq/vdd_table_havs and /sys/devices/system/cpu/cpu0/cpufreq/vdd_tables_havs

    The first file lists the voltages being used for each frequency at the current temperature range.
    The second file first displays the current temperature range index (starting at 0) and then the voltages being used for each frequency and for each temperature range.

    The WiFi screen off power level can be configured by modifying the following file: /sys/module/bcm4329/parameters/wlLowPower
    By sending 'echo 1 > /sys/module/bcm4329/parameters/wlLowPower' the WiFi will switch to low power level when the screen is switched off. By default maximum power is used at all times.

    Test versions:
    The following section contains test materiel. This means that I need feedback on this version, as it may (or may not) become the next official version.
    For the moment, no beta/test version available.
    View
    14
    D
    Dr Byte
    1% per hour on standby (or even less)

    I'd love to show you another graph, but CurrentWidget had another of its famous infarcts, and lost several hours' worth of data. Suffice it to say that I'm at over seven hours, with 91% left, having spent a good half hour diagnosing K9 wakelock problems.

    So: if you're not getting around 1%/hour or better, and want to...

    • Check out what is using your battery and try to put it in a lower-energy mode.
    • If it persists, try stopping services
    • If there are no programs running, check out your WakeLocks (Spare Parts, BetterBatteryStats) and see if anything is using more than (say) 1% of the time.
    I found that Fancy Widgets (an HTC Clock/Weather widget clone) kept using a large amount of "WakeLock" time even though it was set to update only every two hours.

    K9 also uses a huge amount of WakeLock time, even though the logs say it isn't... if you don't need PUSH email, turn it off to save a huge amount of WakeLock.

    My "Deep Sleep" has gone from about 85-87% to nearly 97% in a day. After 7 hours and change on OnDemand, I'm now seeing what Lazy will do for the rest of the day... before trying SmartassV2 again.

    Observations:
    • Wifi/3G/Sync on need not mean a fast battery drain
    • Battery "burn" is directly proportional to the amount of time NOT spent in "Deep Sleep" - the CPU is actually the most efficient component in the phone - everything else is profligate in its use of energy by comparison! To maximise your charge lifetime, maximise "Deep Sleep"
    • PUSH email (K9) can cause a significant increase in "awake" time (4-6% overall). Try polling instead, and see what a difference it makes. Set the mail program to only search the required folders (say, inbox) and you'll be surprised how much difference it makes to keep your inbox uncluttered!
    • Widgets may also keep the phone awake when they're supposedly not allowed to.
    • You can get up to 100 hours on standby on a Desire with CM7
    • The Kernel is the critical factor in battery drain in standby; .35 kernels use less than current ones
    • Tuning voltages too low can significantly INCREASE your battery drain as well as making the phone appear laggy and become unstable.
    • Tuning voltages to reasonable, safe levels (undervolting) can marginally improve your battery life
    • Tuning frequencies down (underclocking) can marginally improve your battery life
    • Running at 729MHz/1050mV uses just as little power as 128-729... with the side-effect of slower response times. The difference between 128, 245 and 729 is so small that it's not measurable in any meaningful way (too many uncontrolled variables) and produces much the same results.
    • Governors make FAR less difference than anything above. Some will use a bit more, some less. OnDemand gives the most consistent results (same statistics over and over) whereas Lazy can provide better AND worse results at the same time.
    • A properly tuned, sleeping phone doesn't care what governor is running, since it spends so little time actually running when in standby. Therefore, choose the Governor based on your actual needs while the screen is ON and CPU is active. If you use background file transfers, sync, or streaming - choose a Governor to suit. Otherwise, it's pointless arguing about what governor to use for 1-4% of the time.
    • Use one governor for everything - using different ones for screen-on and screen off can cause issues on the transition, especially on wakeup. Again, there is little point spending time optimising 4% of the problem - go for the 96%!
    • Tools are your friend. Use them to identify where your drain is, and systematically address it. If necessary, temporarily uninstall packages. Repeat this step until all the high drain problems are eliminated, then look for alternative settings or applications.
    • Change one thing at a time, or prepare to be confused!
    • When in doubt, increase the minimum voltages. It will have trivial or no impact on your current draw, but may make the phone a lot more stable.
    • Unless you know better, use 1350mV for all your maximum voltages. That way, the phone has the option of using it if necessary to cope; too little Vmax, and it may crash.
    • If your phone works on other or previous kernels with the same voltages, that isn't because it was using them - it's because of BUGS and RESTRICTIONS in those kernels that meant it wasn't actually using the low voltages you set! 2.0.3 and 2.0.4 will try to do what you ask. Don't complain if you get what you asked for - a voltage too low to operate reliably!
    • If you are using a script or application such as "IncrediControl" to manage your voltages, use the "Set at boot" checkbox with great care! It is very easy to set the boot-time voltages so low that you will have to restore your phone from backup (or use adb) to regain control of it again. When you DO use the checkbox, make sure you use very safe minimum voltage values, such as 1100mV or higher.
    • Tweak your operating voltages down once the phone is already booted and under your control, but don't expect miracles: the major drains are:
      • Display
      • GPS
      • Camera
      • WiFi
      • Mobile connection
      • ...and well-behaved applications/widgets running on the phone or in standby are trivial by comparison.
    • Some kernels use (or allow you to enable) PS_MAX (max powersave) mode for WiFi. 2.x uses PS_FAST (Fast, but power-light) mode by default, whereas 1.4 uses PS_MAX. MAX may sound like a good idea, but it limits the available bandwidth while in that mode, which may interfere with operations like file copies or streaming music while the screen is off. Use with care. Also, it seems not to save much (if any) power in practice.
    • WiFi conditions may also affect your "battery life." If you are in a saturated WiFi area, the phone will have to SPEAK LOUDER to be heard, using more power. Similarly, it will have to "listen" to more traffic in the background hubbub compared to a quiet area with only its own, virtually silent network.
    • Similarly, 3G conditions will affect your "Mobile connection" services' battery drain. If you are in a marginal coverage area, it will take more "oomph" to talk to the nearby tower(s).
    • It may be counterintuitive, but you will probably find that the phone uses less battery if you run at a higher minimum frequency with the screen off. What? Easy: you want the phone to be in "Deep Sleep" as much as possible. This means finishing the work as soon as possible. If it's entirely CPU bound, the faster the clock speed, the faster it can go back to sleep, using virtually no power. 20 seconds of power-on at 128MHz uses more power than 10 seconds at 384, and it probably won't even use that much.

    UPDATE: See http://xdaforums.com/showpost.php?p=19895459&postcount=1870 for an update on GpsLocationProvider wakelocks among others, related to WiFi Network location.
    View
    10
    E
    EViollet
    That's all folks!

    Hi everyone.

    Just passing by to say that 2.1 will probably be the last version of the 2.x series. I switched to ICS last weekend and I'm loving it!! :)

    Maybe there'll be a 3.x version for ICS some time from now. Who knows? But until then, I guess development on this kernel is kind of stopped.
    View
    8
    E
    EViollet
    Hi all.

    Just a quick update on the (very slow) progress.
    Smartassv2 has been added.
    Led notification now works with GV>2.7
    Lots of cleanup of the code
    Battery calibration should now work

    Still have a few things to fix, but I suppose a release seems possible next week.

    Regards

    Sent from my HTC Desire using Tapatalk
    View

New posts