CPU Overclocking while screen off - Droid Eris General

Is there a negative effect of setting the clock speed lower while screen off? Aside from running really labor intensive tasks?
It just seems like a great way to save battery to me. Right?

The only negative is getting the phone to wake up fast enough when you get an inbound call.
The CFS kernel (which is widely used now) seems to be less able to come out of a deep sleep rapidly than the older "zanfur" OC kernel did.
IIRC, on the older "zanfur" OC kernel, you could set the minimum scaling frequency to 19 Mhz - but with with the CFS kernel, you may need to use a minimum value of 122 Mhz or 245 Mhz.
Set the max scaling speed to 480 or 528 when sleeping. (The max frequency is only rarely used when the phone is sleeping - but you want the phone to pop out of it's low speed state quickly when you power up the screen, or experience an inbound call).

Thanks, Yeah I usually set the max to 480 while sleeping and 480 as min while awake. Battery seems good there.
Originally I was using SetCPU but I have switched to CPUBoost. Most all the kernels in the past few roms I have used are made by conap and he is also the creator of CPUBoost, so I figured they would integrate really well.
Also if I enter anything above the 800 range the phone will have random reboots throughout a few different roms I've tried.

As a note, if I remember correctly, if you have a kernel/ROM that supports the smartass governor, you should be able to use it and not need to have a profile set to underclock while the screen is off, or really need to underclock at all, as I believe it determines for you how much CPU is needed and sets the clock speed accordingly, simply abiding by your max and min speeds you set. Since less CPU is needed when the screen is off, it will automatically adjust accordingly. However, this is just something I've read around the forums, so don't take my word for it

Pokelover980 said:
As a note, if I remember correctly, if you have a kernel/ROM that supports the smartass governor, you should be able to use it and not need to have a profile set to underclock while the screen is off, or really need to underclock at all, as I believe it determines for you how much CPU is needed and sets the clock speed accordingly, simply abiding by your max and min speeds you set. Since less CPU is needed when the screen is off, it will automatically adjust accordingly. However, this is just something I've read around the forums, so don't take my word for it
Click to expand...
Click to collapse
Thanks for the info, I didn't know that. I will assume that's more or less accurate unless Conap or bftb0 chime in.

Pokelover980 said:
As a note, if I remember correctly, if you have a kernel/ROM that supports the smartass governor, you should be able to use it and not need to have a profile set to underclock while the screen is off, or really need to underclock at all, as I believe it determines for you how much CPU is needed and sets the clock speed accordingly, simply abiding by your max and min speeds you set. Since less CPU is needed when the screen is off, it will automatically adjust accordingly. However, this is just something I've read around the forums, so don't take my word for it
Click to expand...
Click to collapse
roirraW "edor" ehT said:
Thanks for the info, I didn't know that. I will assume that's more or less accurate unless Conap or bftb0 chime in.
Click to expand...
Click to collapse
Well, I suppose it could be said that the whole point of any rate governor is to reduce overall power consumption without markedly affecting the user's perception of "responsiveness" or "speed" - however they go about defining those metrics.
OTOH, because there are - what - five different scaling governors available, it is apparent that people have found their own reasons to create new scaling governors; presumably that arose from a dissatisfaction with the behavior of the available scaling governor - or, that different users have differing application workloads, and so they prefer one governor over another.
As Pokelover980 suggests, you could just hand a given rate governor a fixed set of limits (min/max), and be done with it.** For folks that have the time and desire to experiment, I would suggest that: pick a governor and a min/max clock rate and run that way for 2-3 days - no profiles at all. Then pick a different governor with the same min/max clock rate and run that way for another 2-3 days, and see how it goes - maybe not in battery life, because that's hard to measure in a repeatable way, but at least to see if any problems occur coming out of sleep.
Is the "smartass" governor better than all the rest of them? I don't really know. I used it for a little while, but found something I didn't like about it. (But don't take that as conclusive about anything; I doubt that I was doing disciplined testing when that happened). I tend to use either "interactive" or "ondemand", and don't have a strong preference for one over the other.
There probably is some value in keeping things simple. I think that I mentioned before that at one point (back when the CFS kernels were still in a state of flux) I was convinced that using setCPU was exacerbating problems with lock-ups I observed (once every couple of days). Again, though - that was really only my suspicion; I can't really prove it.
bftb0
** I suppose that folks that insist on extreme levels of overclocking ought to use either an overtemp profile or some other means to monitor temperature so that they don't cook their phone.

I Installed SetCPU on the wifes Eris. The smartass governor on CM7 will max out the cpu (to your preset max) if needed. I dont think the smartest thing to do is max out the cpu at 15% batt life. I have 5 different profiles set. One for screen off, charging, < 50%, < 30%, <10%. I use interactive governor vs smartass. Her phone is pretty responsive and I dont hear about issues with it not waking up. Battery life has also increased quite a bit.

Related

Overclocked-UV-Kernel-Battery Life Without Set-CPU

If you are using one of the Over-Clocked Undervolted Kernels please uninstall set-cpu and observe your battery life for 3 days and compare it to what you got when you used set-cpu. Then report as to if it is better, worse, or the same.
Just compare to what how long your battery lasts with your normal usage. Please do not give replies like "I only used 30% in two days with normal use."
Just reply with either better, worse, or same. Because usage is relative and that is not the purpose of this.
I think that set-cpu is interfering with the built in govenor and its ability to scale the freq of the phone. I think that it is staying on what-ever freq you set in set-cpu and scaling properly and thus reducing the battery life, and making the undervolting useless.
IF YOU BELIEVE YOU HAVE BETTER BATTERY LIFE WITHOUT SETCPU, THEN GET LOGS WHILE IT IS RUNNING AND SEND THEM TO THE DEV.
I have also noticed lag on the home screen with setcpu, I started using Overclock Widget to detect the values and to diff freq screen off 245-576 and put the phone on sleep while charging so will stay cool. Battery life has been great so far! I'm using 2.6.33.4 [email protected] #1 about to upgrade to his newest 2.6.34...I think SetCpu has flaws!
Will let you know my results.
this thread may be of some help. im currently trying pershoots 5.12vfp release without setcpu at all.
i do, however, remember getting 37 hours with moderate use with setcpu and profiles set, but i cant remember which kernal it was exactly. i think it may have been IRs 4.29 release..
Just uninstalled SetCPU and I'm running Pershoot's newest 2.6.33.4 925 Kernel. I will report back my findings in a couple of days...
Been curious about this for a while, but does the Nexus automatically throttle CPU speed by itself when SetCPU is not installed?
paulk_ said:
Been curious about this for a while, but does the Nexus automatically throttle CPU speed by itself when SetCPU is not installed?
Click to expand...
Click to collapse
Nope, incredible and onwards only.
Did this Quite a bit ago... ran with and without for over a week and i have better battery life without setcpu
When you don't have setcpu, you're not running at 1113ghz..
persiansown said:
When you don't have setcpu, you're not running at 1113ghz..
Click to expand...
Click to collapse
Perhaps...However, Linpack is proportional (I think) to the device's performance. My little experiment was testing different frequency kernels and measuring that against Linpacl
998: 7.4
1.13: 8.2
1.19: 8.9
So it would appear that performance increases with each kernel which wouldn't be the case if SetCPU was required.
I have some reasons to believe that SetCPU would interfere with the actual design of the Nexus One. I mean after all, i'm sure it was programmed to manage itself. So why have another app that does the same thing, twice? Just a thought, but for one thing, my phone is definitely cooler when charging compared to having SetCPU with profiles.
dogiedogie said:
Nope, incredible and onwards only.
Click to expand...
Click to collapse
You mean that the Incredible features CPU throttling?
jlevy73 said:
Perhaps...However, Linpack is proportional (I think) to the device's performance. My little experiment was testing different frequency kernels and measuring that against Linpacl
998: 7.4
1.13: 8.2
1.19: 8.9
So it would appear that performance increases with each kernel which wouldn't be the case if SetCPU was required.
Click to expand...
Click to collapse
There are dozens of potential optimizations that can be done to improve performance without touching the cpu speed. Different kernels, especially if they're from different people, will have different flags set in the build and so will perform differently even at the same clock speed.
Casao said:
There are dozens of potential optimizations that can be done to improve performance without touching the cpu speed. Different kernels, especially if they're from different people, will have different flags set in the build and so will perform differently even at the same clock speed.
Click to expand...
Click to collapse
I completely agree however all the kernels I use are from the same person and the optimizations at the different clocks speeds are identical. Therefore the spread in my linpack scores indicate that setcpu is not required. At least, that's my theory
this and other threads have made me question why we need setcpu anyways. I have it running and its great but can't we just integrate what setcpu is doing from the get go instead of having an external app running a separate process?'seems a little inefficient to me. The reason I say this is that I noticed most people are using the same settings for set cpu.
anyways, I dunno how relevant all this is since froyo's just around the corner and that may alleviate some problems but bring more problems
Yeah, start bashing my app, knowing I was the one who came up with the ideas behind the 1113MHz/uv hack in the first place (in fact, I came up with the 21MB hack as well, so prominently displayed in the OP's kernel thread title). Thanks, nexus one community.
I can explain that setcpu does not run any code in the background if your profiles are disabled, I can explain how cpufreq works, I can explain what lengths I went to to optimize the profiles, and I can explain that the profiles are very passive (except sometimes on the Droid, but there's an option for tweaking that) but I probably won't bother. Grab 1.5.3a and use it, or don't use it. I don't care either way.
I think that set-cpu is interfering with the built in govenor and its ability to scale the freq of the phone. I think that it is staying on what-ever freq you set in set-cpu and scaling properly and thus reducing the battery life, and making the undervolting useless.
Click to expand...
Click to collapse
You obviously do not know how cpufreq works. Setcpu does not touch the values after it sets a profile. Profiles actually run code only when it receives broadcast intents. It sets the max and min bounds and the governor if necessary within a fraction of a second. The service is completely idle otherwise. It can't "interfere with the built in governor." Okay, then. What is your big theory? What exactly is setcpu doing wrong?
SetCPU is advantageous because it allows you to tweak speeds on the fly and based on certain conditions. You can have solely kernel based overclocking and undervolting, sure, and that is perfectly fine. SetCPU is a convenient tool for controlling that without having to compile and flash a new kernel. If you do not like profiles, do not use them. They were only introduced in 1.3.0 But don't uninstall SetCPU because it does nothing with profiles disabled.
dogiedogie said:
Nope, incredible and onwards only.
Click to expand...
Click to collapse
HTC implements a rather awkward driver in nearly all of their Sense UI devices (and I think the Magic 32A) that throttles based on certain conditions. I am not entirely sure how it works, as I have not looked into the specifics, but it seems to max out the CPU under some conditions.
chowlala said:
I have some reasons to believe that SetCPU would interfere with the actual design of the Nexus One. I mean after all, i'm sure it was programmed to manage itself. So why have another app that does the same thing, twice? Just a thought, but for one thing, my phone is definitely cooler when charging compared to having SetCPU with profiles.
Click to expand...
Click to collapse
I am 100% sure this is placebo effect. Setcpu can't make your phone run hotter just because it's there. If you had a charging profile set for 1113/1113, sure, but that is not setcpu itself. Linux does not control the CPU scaling any further than what ondemand does - there is nothing preventing the CPU from going up to your max during sleep (or rather, when the screen is off), for example, or when your battery is low.
Oh, and using the active widget is a bad idea if you care about battery life. I tried to optimize it as much as possible, but realize that it's updating a lot more things than other apps are (the frequency, the bounds, and two temperature readings) at a relatively fast interval. The home screen does pause a bit while it is updating. That is a fact of life. Longer intervals are essentially useless because the update interval for cpufreq itself is on the order of thousands of microseconds. The current appwidget refreshes if the screen is on, regardless of whether it's visible or not (there is currently no way to tell if it is visible). A live wallpaper would be a much better idea than a constantly updating appwidget, and I'll look into that.
Let me explain this bit better. Cpufreq will scale your CPU between the max and min values automatically. Once the CPU load hits the "up threshold," it takes your CPU frequency from the min to the max, then gradually eases it down. SetCPU lets you easily change the max and min values on the fly. If you want, it can also prevent the system from scaling the CPU up that high during times you don't want it to (with profiles, of course). It does not and cannot interfere with the actual governor.
Well there you have it, straight from the source
TL;DR - setCPU doesn't run code in background unless you use profiles, it doesn't make your phone hotter unless you use a 1113/1113 profile, & if you value battery life don't use setCPU Active widget.
SetCPU
coolbho3000 said:
...
Click to expand...
Click to collapse
Props dude. Keep up the good work.
To be honest I'm a user, donator and supporter of SetCPU. I've never had cause to complain.
Not bashing your app dude, in fact I have the paid version. I am only wondering why people are noticing better battery life without it than with it. Want to see if it really is setcpu or something else. To do that something has to be isolated.
And I believe that if the freq are set in the kernel then the phone will scale up an down on its own.
coolbho3000 said:
Yeah, start bashing my app, knowing I was the one who came up with the ideas behind the 1113MHz/uv hack in the first place (in fact, I came up with the 21MB hack as well, so prominently displayed in the OP's kernel thread title). Thanks, nexus one community.
I can explain that setcpu does not run any code in the background if your profiles are disabled, I can explain how cpufreq works, I can explain what lengths I went to to optimize the profiles, and I can explain that the profiles are very passive (except sometimes on the Droid, but there's an option for tweaking that) but I probably won't bother. Grab 1.5.3a and use it, or don't use it. I don't care either way.
You obviously do not know how cpufreq works. Setcpu does not touch the values after it sets a profile. Profiles actually run code only when it receives broadcast intents. It sets the max and min bounds and the governor if necessary within a fraction of a second. The service is completely idle otherwise. It can't "interfere with the built in governor." Okay, then. What is your big theory? What exactly is setcpu doing wrong?
SetCPU is advantageous because it allows you to tweak speeds on the fly and based on certain conditions. You can have solely kernel based overclocking and undervolting, sure, and that is perfectly fine. SetCPU is a convenient tool for controlling that without having to compile and flash a new kernel. If you do not like profiles, do not use them. They were only introduced in 1.3.0 But don't uninstall SetCPU because it does nothing with profiles disabled.
HTC implements a rather awkward driver in nearly all of their Sense UI devices (and I think the Magic 32A) that throttles based on certain conditions. I am not entirely sure how it works, as I have not looked into the specifics, but it seems to max out the CPU under some conditions.
I am 100% sure this is placebo effect. Setcpu can't make your phone run hotter just because it's there. If you had a charging profile set for 1113/1113, sure, but that is not setcpu itself. Linux does not control the CPU scaling any further than what ondemand does - there is nothing preventing the CPU from going up to your max during sleep (or rather, when the screen is off), for example, or when your battery is low.
Oh, and using the active widget is a bad idea if you care about battery life. I tried to optimize it as much as possible, but realize that it's updating a lot more things than other apps are (the frequency, the bounds, and two temperature readings) at a relatively fast interval. The home screen does pause a bit while it is updating. That is a fact of life. Longer intervals are essentially useless because the update interval for cpufreq itself is on the order of thousands of microseconds. The current appwidget refreshes if the screen is on, regardless of whether it's visible or not (there is currently no way to tell if it is visible). A live wallpaper would be a much better idea than a constantly updating appwidget, and I'll look into that.
Let me explain this bit better. Cpufreq will scale your CPU between the max and min values automatically. Once the CPU load hits the "up threshold," it takes your CPU frequency from the min to the max, then gradually eases it down. SetCPU lets you easily change the max and min values on the fly. If you want, it can also prevent the system from scaling the CPU up that high during times you don't want it to (with profiles, of course). It does not and cannot interfere with the actual governor.
Click to expand...
Click to collapse
I too am a fan of setcpu, and over the last week I did get curious due to this this thread. I found my battery ran down quite significantly faster without setcpu, maybe because I didn't have my sleep profile of lowest freq min/max, or my battery profile of max 756, or my low battery profiles scaling down my cpu max. Either way, stop bashing the app, it's awesome, and if you had concerns, take them to the dev rather than start a witch hunt in the forums trying to make a posse.
People that report better battery, may not have had setcpu set up correctly in the first place. A friend of mine at work installed it, ran for a day and uninstalled it, citing it didn't do anything and infact drained his battery. He had the widget running, and had upped the minimum cpu freq to 500 and something, max to the 1.13ghx. He didn't run profiles. But as such, he wasn't letting his phone scale down to the lowest freq when it wanted to, and had the widget drain. I got him to set t up as I have mine, and he was blown away with the change.
"My car wont go over 20km/h"
"Are you putting your foot on the accelerator?"
"Whats an accelerator?"
Things have to be used correctly to get the best out of them, and unless someone saying it's far worse than without actually comes in and puts up their values they have it set to, we have no idea why they are having the fault. My experience (I have worked tech call centres for years) is that 99/100 issues people experience are due to not using things as they are set out to be, or just have no idea how to do what they are trying to do. My work mates thing was that he thought all apps would go faster if he increased the minimum freq, so therefore use less battery because the processes are completed faster. In a way it's logical, but the result is that even when nothings running the cpu wont fall below that value, so the battery drained much faster than he expected.

[Q] Underclocking

I'm currently debating buying WidgetLocker, but I'm a bit skeptical since I'm not sure how bad it will lag with my current sleep profile. Can any WidgetLocker users possibly shed some light if they think it will lag on my phone? I'll put my profiles below.
Code:
Temp > 38.6C, Priority: 100, 480 max 160 min, ondemand
Charging/Full, Priority: 75, 710 max 245 min, ondemand
Battery < 25%, Priority: 50 ,480 max 245 min, ondemand
Screen Off, Priority: 25, 245 max 160 min, ondemand
If my sleep profile would make it lag, would bumping it up to 245 max 245 min help any?
Profile recommendations are welcome as well if theres anything that could be done to improve performance without sapping an excessive amount of battery. I have noticed my phone lags waking up sometimes and occasionally just when it's being used.
I would put your sleep profile at either the 2nd or 3rd highest priority - either right after the overtemp profile, or after the "on charger/full" profile.
my profiles usually look something like this (ordered from highest to lowest priority) :
- temperature (can have more than one; highest (over-)temp has highest priority)
- charging/full
- screen off
- battery (can have more than one; lowest battery % has highest priority)
- battery < 101% (this is the sort of like the "off charger, not overtemp, screen on state)
If the "screen off" profile has a higher priority than all the battery conditions, then all the "battery" conditions certainly can only be effective when the screen is on. (Note that the way you have it now, your < 25% battery condition always "wins" over the screen-off profile)
Also, note that your profiles don't contain anything matching the "off charger, 25% < battery < 101%" condition as they stand - what is controlling that, the default profile?
I'm not sure that there are big gains to be had by ratcheting down the min/max cpu frequency for low battery conditions: when you have the display on, it could well be drawing more power than the CPU - so, if your goal is to save battery, it would make sense to have whatever it is you want "computed" to show up on the screen as quickly as possible - so that you can shut the screen off that much quicker.
For the same reason, if most of the time the phone is on you are just "staring at the screen", and nothing is going on in the background, allowing the rate governor to drop to a low frequency saves you only a little bit (if the screen is really the dominant juice-user in that scenario.)
My GSB v1.6 Eris reports using only 2-3 % overnight - it's screen off profile is set to 160/245 - and I seem to be using the "interactive" governor on all profiles ... but I also use Toggle2G with a 10-minute sleep onset delay.
( Probably that means that I don't get email notifications as soon as I could, but that doesn't bother me much - I get them as soon as I unsleep the phone. If you are the type of person that needs to look at their phone every time your facebook updates, then Toggle2G perhaps isn't for you.)
I can't prove it, but so long as you don't peg your CPU minimum frequency too high, and rely on the rate governor to do it's job, most power savings are likely to come from managing the radio state and the screen brightness.
bftb0
What percentages do u recommend bftb0
Sent from my Ginger Tazz using Tapatalk
bftb0 said:
I would put your sleep profile at either the 2nd or 3rd highest priority - either right after the overtemp profile, or after the "on charger/full" profile.
my profiles usually look something like this (ordered from highest to lowest priority) :
- temperature (can have more than one; highest (over-)temp has highest priority)
- charging/full
- screen off
- battery (can have more than one; lowest battery % has highest priority)
- battery < 101% (this is the sort of like the "off charger, not overtemp, screen on state)
If the "screen off" profile has a higher priority than all the battery conditions, then all the "battery" conditions certainly can only be effective when the screen is on. (Note that the way you have it now, your < 25% battery condition always "wins" over the screen-off profile)
Also, note that your profiles don't contain anything matching the "off charger, 25% < battery < 101%" condition as they stand - what is controlling that, the default profile?
I'm not sure that there are big gains to be had by ratcheting down the min/max cpu frequency for low battery conditions: when you have the display on, it could well be drawing more power than the CPU - so, if your goal is to save battery, it would make sense to have whatever it is you want "computed" to show up on the screen as quickly as possible - so that you can shut the screen off that much quicker.
For the same reason, if most of the time the phone is on you are just "staring at the screen", and nothing is going on in the background, allowing the rate governor to drop to a low frequency saves you only a little bit (if the screen is really the dominant juice-user in that scenario.)
My GSB v1.6 Eris reports using only 2-3 % overnight - it's screen off profile is set to 160/245 - and I seem to be using the "interactive" governor on all profiles ... but I also use Toggle2G with a 10-minute sleep onset delay.
( Probably that means that I don't get email notifications as soon as I could, but that doesn't bother me much - I get them as soon as I unsleep the phone. If you are the type of person that needs to look at their phone every time your facebook updates, then Toggle2G perhaps isn't for you.)
I can't prove it, but so long as you don't peg your CPU minimum frequency too high, and rely on the rate governor to do it's job, most power savings are likely to come from managing the radio state and the screen brightness.
bftb0
Click to expand...
Click to collapse
Never a post that isn't enlightening from you.
Yes my default clock profile (710 max 160 min, might bump it up to 245 min) is the one managing the clock rate when the phone is off the charger. As for Toggle2G that might not be a bad idea, I keep my phone on Airplane Mode most of the time I'm at school (horrible signal = battery draining out the wazoo) but it might not be a bad idea to have for when I'm not at school. Of course I'm not sure I would need it though since I have an extended battery, maybe something to experiment with.
As for profiles, something like this?
Code:
Temp > 38.6C, Priority: 100, 480 max 160 min, ondemand
Screen Off, Priority: 75, 245 max 160 min, ondemand
Charging/Full, Priority: 50 ,710 max 245 min, ondemand
Battery < 25%, Priority: 25, 480 max 245 min, ondemand
If you are already using Airplane Mode because of poor signal conditions, Toggle2G won't help much - the battery will drain just looking for voice/1xRTT service (not to mention 3G). I have a pretty good signal where my phone spends most of it's time, including overnight ( -70 dBm to -80 dBm )
ToastPwnz said:
As for profiles, something like this?
Code:
Temp > 38.6C, Priority: 100, 480 max 160 min, ondemand
Screen Off, Priority: 75, 245 max 160 min, ondemand
Charging/Full, Priority: 50 ,710 max 245 min, ondemand
Battery < 25%, Priority: 25, 480 max 245 min, ondemand
Click to expand...
Click to collapse
Seems OK. I have a couple of battery profiles where I slowly drop the max frequency, and make the default condition explicit by using a "battery < 101%" profile, as in:
Pr Min/Max Governor Condition
90 245/480 interactive Temp > 50.0 C *audible alarm
80 245/604 interactive Temp > 45.2 C
70 528/710 interactive Charging
60 160/245 interactive Screen Off
50 160/480 interactive Battery < 15%
40 160/528 interactive Battery < 25%
30 245/604 interactive Battery < 40%
20 480/710 interactive Battery < 67%
10 480/729 interactive Battery < 101%
I'm not sure this really produces much effect in terms of battery savings, though - for instance, it runs counter to my suggestion (above) that it might actually hurt to slow things down with reduced battery reserve because you just end up with the screen on longer.
I'll also mention that for a period of time I was actually convinced that using setCPU was causing random freeze-ups when used with certain combinations of the CFS kernel, governor choice, and min frequency - and so I didn't even have it installed on my phone. I only recently put setCPU back on my phone because I was noticing that CPUboost settings did not seem to be sticking even within the same session (perhaps I was misinterpreting something, I'm not sure). No random freeze-ups lately.
Because some of the things which actually drain the battery - cell radio, screen time on & brightness, 3G activity level, etc., are so highly variable, I'm not sure that any of the reports on this forum (including mine) can be regarded as particularly meaningful. It takes real dedication to the task (creating reproducible signal conditions and compute/activity workloads) to be able to produce quality data about battery usage. Most folks need to use their phones throughout the day (moving continuously from place to place with widely varying signal levels), so they can't set their phones aside to do such things; their usage is not repeatable, so it is hard to believe them, whether they are saying "great battery life", or "battery life sucks!".
Heck, even at night, when my phone isn't "doing anything", (which you would think would be sort of "reproducible") if I move it 8 inches one way or another on the nightstand, my signal level can change by 10 dBm. That means that if I don't use Airplane Mode overnight, it is really not too meaningful to compare "configuration X" to "configuration Y" on successive nights - because the battery usage by the radio is not reproducible.
I guess the bottom line is - if you can get a full day out of the phone, be happy with that; it's just about what the phone was designed to do.
bftb0
bftb0 said:
If you are already using Airplane Mode because of poor signal conditions, Toggle2G won't help much - the battery will drain just looking for voice/1xRTT service (not to mention 3G). I have a pretty good signal where my phone spends most of it's time, including overnight ( -70 dBm to -80 dBm )
Seems OK. I have a couple of battery profiles where I slowly drop the max frequency, and make the default condition explicit by using a "battery < 101%" profile, as in:
Pr Min/Max Governor Condition
90 245/480 interactive Temp > 50.0 C *audible alarm
80 245/604 interactive Temp > 45.2 C
70 528/710 interactive Charging
60 160/245 interactive Screen Off
50 160/480 interactive Battery < 15%
40 160/528 interactive Battery < 25%
30 245/604 interactive Battery < 40%
20 480/710 interactive Battery < 67%
10 480/729 interactive Battery < 101%
I'm not sure this really produces much effect in terms of battery savings, though - for instance, it runs counter to my suggestion (above) that it might actually hurt to slow things down with reduced battery reserve because you just end up with the screen on longer.
I'll also mention that for a period of time I was actually convinced that using setCPU was causing random freeze-ups when used with certain combinations of the CFS kernel, governor choice, and min frequency - and so I didn't even have it installed on my phone. I only recently put setCPU back on my phone because I was noticing that CPUboost settings did not seem to be sticking even within the same session (perhaps I was misinterpreting something, I'm not sure). No random freeze-ups lately.
Because some of the things which actually drain the battery - cell radio, screen time on & brightness, 3G activity level, etc., are so highly variable, I'm not sure that any of the reports on this forum (including mine) can be regarded as particularly meaningful. It takes real dedication to the task (creating reproducible signal conditions and compute/activity workloads) to be able to produce quality data about battery usage. Most folks need to use their phones throughout the day (moving continuously from place to place with widely varying signal levels), so they can't set their phones aside to do such things; their usage is not repeatable, so it is hard to believe them, whether they are saying "great battery life", or "battery life sucks!".
Heck, even at night, when my phone isn't "doing anything", (which you would think would be sort of "reproducible") if I move it 8 inches one way or another on the nightstand, my signal level can change by 10 dBm. That means that if I don't use Airplane Mode overnight, it is really not too meaningful to compare "configuration X" to "configuration Y" on successive nights - because the battery usage by the radio is not reproducible.
I guess the bottom line is - if you can get a full day out of the phone, be happy with that; it's just about what the phone was designed to do.
bftb0
Click to expand...
Click to collapse
Hm, I might try those profiles with a few tweaks, or I might just end up bumping up my screen off profile in terms of priority, not sure yet.
Another question, what do you suggest as far as governors go? I seem to have the most success with ondemand, but I've never tried interactive. I learned the hard way that smartass lags my phone horribly, not sure why.
With my extended battery, I've gone roughly 65 hours total uptime with about 45% battery left with moderate use. I guess I should be proud of that.
ToastPwnz said:
I'm currently debating buying WidgetLocker, but I'm a bit skeptical since I'm not sure how bad it will lag with my current sleep profile. Can any WidgetLocker users possibly shed some light if they think it will lag on my phone? I'll put my profiles below.
Code:
Temp > 38.6C, Priority: 100, 480 max 160 min, ondemand
Charging/Full, Priority: 75, 710 max 245 min, ondemand
Battery < 25%, Priority: 50 ,480 max 245 min, ondemand
Screen Off, Priority: 25, 245 max 160 min, ondemand
If my sleep profile would make it lag, would bumping it up to 245 max 245 min help any?
Profile recommendations are welcome as well if theres anything that could be done to improve performance without sapping an excessive amount of battery. I have noticed my phone lags waking up sometimes and occasionally just when it's being used.
Click to expand...
Click to collapse
Wow you actually set a max of 480 for merely being over 38.6C??? I think that's a bit extreme. Other than that your profiles aren't that different than what I use (using Conap's CPUBoost tool, what are you using?).
I love WidgetLocker, and yes it's one of the only two apps I've actually purchased. Lag or not I wouldn't trade it.
The only "issue" (not necessarily WL's fault) is that using the Theme Chooser under GB ROMs, at least with the Speedometer Battery theme, definitely causes WL to lose what widgets are on it between reboots, although not always every reboot, but most of them.
It's confirmed that the solution is to not use Theme Chooser, at least with the Speedometer Battery theme. I don't know for sure if other themes cause it as well, but it's easily reversed (go back to the stock theme) if it does.
roirraW "edor" ehT said:
Wow you actually set a max of 480 for merely being over 38.6C??? I think that's a bit extreme. Other than that your profiles aren't that different than what I use (using Conap's CPUBoost tool, what are you using?).
I love WidgetLocker, and yes it's one of the only two apps I've actually purchased. Lag or not I wouldn't trade it.
The only "issue" (not necessarily WL's fault) is that using the Theme Chooser under GB ROMs, at least with the Speedometer Battery theme, definitely causes WL to lose what widgets are on it between reboots, although not always every reboot, but most of them.
It's confirmed that the solution is to not use Theme Chooser, at least with the Speedometer Battery theme. I don't know for sure if other themes cause it as well, but it's easily reversed (go back to the stock theme) if it does.
Click to expand...
Click to collapse
I'm still using SetCPU.
Yes I do knock it down that far, my phone heats up like crazy while I'm at school (terrible signal) and once it reaches 100F I could use the phone as a hand warmer and if I take off the back I can smell burning plastic. Maybe thats normal for the Eris, but I use it just as a precautionary measure.
ToastPwnz said:
Another question, what do you suggest as far as governors go? I seem to have the most success with ondemand, but I've never tried interactive. I learned the hard way that smartass lags my phone horribly, not sure why.
Click to expand...
Click to collapse
I haven't spent much time trying to figure out the "best" governor - I tend to use either "ondemand" or "interactive" without giving it too much thought. I tried smartass for a while, and remember being not happy with it for some reason or another; but I don't remember what those reasons were. ( It might have been nothing more than "choppiness" of scrolling behaviors. )
bftb0 said:
I haven't spent much time trying to figure out the "best" governor - I tend to use either "ondemand" or "interactive" without giving it too much thought. I tried smartass for a while, and remember being not happy with it for some reason or another; but I don't remember what those reasons were. ( It might have been nothing more than "choppiness" of scrolling behaviors. )
Click to expand...
Click to collapse
Now my curiosity is getting the best of me. Whats the difference between ondemand and interactive? (Sorry for all my questions <.<)
ToastPwnz said:
Now my curiosity is getting the best of me. Whats the difference between ondemand and interactive? (Sorry for all my questions <.<)
Click to expand...
Click to collapse
I don't know for sure...
... but I can tell you that the exact answer to your question is right here.
bftb0 said:
I don't know for sure...
... but I can tell you that the exact answer to your question is right here.
Click to expand...
Click to collapse
Hidden within that garbled mess.
I kid, I think I found the explanation you had in mind, and from what I can find the only major difference is that interactive is more aggressive then ondemand. I'm not sure if I should take that governor for a test run or not, I do notice that my phone lags when waking up occasionally. It kind of sounds like switching to interactive might help that.
ToastPwnz said:
I'm still using SetCPU.
Yes I do knock it down that far, my phone heats up like crazy while I'm at school (terrible signal) and once it reaches 100F I could use the phone as a hand warmer and if I take off the back I can smell burning plastic. Maybe thats normal for the Eris, but I use it just as a precautionary measure.
Click to expand...
Click to collapse
You probably have your reasons, but when you're at school, why don't you put it in Airplane mode and just take it off it between classes to check emails and such? Save your battery and the heat of your Eris a bunch.
Or do you and you just use the temperature profile as a fallback in case you forget to put it back in Airplane mode?
roirraW "edor" ehT said:
You probably have your reasons, but when you're at school, why don't you put it in Airplane mode and just take it off it between classes to check emails and such? Save your battery and the heat of your Eris a bunch.
Or do you and you just use the temperature profile as a fallback in case you forget to put it back in Airplane mode?
Click to expand...
Click to collapse
You are quite correct sir. That and my I bump my phone occasionally, and I think two days ago it turned on and I didn't notice, and when I checked it I noticed over the course of about 2-3 hours it lost 14% and was at around 95ish F.
I do keep it in Airplane Mode when I'm not using it (and it's off as well), but the profile is pretty much just a precautionary measure.

[REQ] Standalone fix for high CPU freq with screen on

As I understand solution for "998 MHz with screen on" bug is found: http://forum.xda-developers.com/showthread.php?t=1225411&page=17#post16944722
We need to replace only one governor.
I don't want to play with different ROMs and kernels and I'm looking for simplest solution.
Is it possible to compile it as a module ("ondemand_mod" for ex.) and add it to stock ROM?
Or any other (simple) way?
Wrong section ...
Sent from my X10i using Tapatalk
Why wrong Section, this is Development to get the CPU Governor working correctly
Wolfbreak said:
Why wrong Section, this is Development to get the CPU Governor working correctly
Click to expand...
Click to collapse
Exactly, this is the right section for such request.
However, I can't help but wonder: is this really a "problem"?
No offence to anyone, but I find that the phone is very snappy
when on max frequency... The big problem for me, would be if it
didn't go into Deep Sleep immediately after turning the screen off
and stayed at min frequency for an extended period.
When the screen is on (aka using the phone) I'd like it to be as FAST
as possible. That's the reason I use the minmax governor.
Anyway, again, I don't mean to argue with anyone, I am just
presenting my point of view.
My_Immortal said:
However, I can't help but wonder: is this really a "problem"?
No offence to anyone, but I find that the phone is very snappy
when on max frequency... The big problem for me, would be if it
didn't go into Deep Sleep immediately after turning the screen off
and stayed at min frequency for an extended period.
When the screen is on (aka using the phone) I'd like it to be as FAST
as possible. That's the reason I use the minmax governor.
Anyway, again, I don't mean to argue with anyone, I am just
presenting my point of view.
Click to expand...
Click to collapse
Yes, it's really problem.
Higher frequency - higher power consumption. Moreover - with higher frequency CPU used with higher voltage so consumption is even more higher. So at 998 MHz CPU eats about 5 times more battery than on 246MHz.
With properly tuned governor I don't feel any real lags or slowdowns.
And, when screen is on CPU load is usually is lower than 20% at full frequency. So I don't want to waste my battery.
As I see it's possible to compile and use governor as module.
Could someone compile it? And assemble as xRecovery package?
Or point me where to read about compiling for arm, where to get tools and so on...
Karlson2k said:
Yes, it's really problem.
Higher frequency - higher power consumption. Moreover - with higher frequency CPU used with higher voltage so consumption is even more higher. So at 998 MHz CPU eats about 5 times more battery than on 246MHz.
With properly tuned governor I don't feel any real lags or slowdowns.
And, when screen is on CPU load is usually is lower than 20% at full frequency. So I don't want to waste my battery.
Click to expand...
Click to collapse
The thing is, on 245 MHz, you can't get any kind of decent performance.
Try this: set the minimum and maximum CPU frequency with SetCPU to 245 and attempt to use the phone normally.
Also, you might be right about voltage, but if the CPU is forced to work on lower freqs when it actually needs higher, there's definitely stress and increased battery consumption.
My phone lasts for more than 24 hours and it's always at max frequency when the screen is on. No lag, no freezes, no drain.
I do agree that the ondemand governor might not function as expected but I fail to experience the actual problem. That might be just me though.
Xperia X10i via Tapatalk
My_Immortal said:
The thing is, on 245 MHz with high load, you can't get any kind of decent performance.
Try this: set the minimum and maximum CPU frequency with SetCPU to 245 and attempt to use the phone normally.
Also, you might be right about voltage, but if the CPU is forced to work on lower freqs when it actually needs higher, there's definitely stress and increased battery consumption.
My phone lasts for more than 24 hours and it's always at max frequency when the screen is on. No lag, no freezes, no drain.
I do agree that the ondemand governor might not function as expected but I fail to experience the actual problem. That might be just me though.
Click to expand...
Click to collapse
There is no need to work on 245MHz as proper governor rise frequency automatically when it's necessary.
And really no stress for CPU to work an low frequency at full load. Moreover - CPU will consume more power at 500Mhz with 45% load than at 250Mhz with 95% load.
Sometime I use phone for navigation - long time with screen on and very low load. In this scenario battery drains very fast.
And last one - I like to have everything working properly. In case that I'll really need high frequency all the time I'll use other governor. I just want to have a choice.
I need a simple solotion for this too..I use z kernel and I found that Thego2s kernel fixed this problem..I was going to flash that kernel but think that has a bug and stoucks on logo ..can some one sayas a simple way?
Yes, I think a lot of people would prefer to use just small and simple fixes rather than replacing the whole kernel with a lot of nice but (personally) unnecessary features.
I am waiting for developers to release a fix for this problam

Min/Max frequencies of the CPU and you

I remember there was this long debate about ASUS/NVIDIA and how they took away the 107MHz frequency and how it affected battery life..
For the record, on my CPU Spy I have it at 120 hours with 35% at 370MHz and 0% (56 minutes) at 102MHz with the rest in deep sleep and 405 and up to 1300MHz with great battery life.
In any case, there's a discussion in EVO 3D about CPU that might have some bearing on the frequencies and how it affects battery life and why sometimes the lowest one isn't the best for battery life.
Now, of course we know the variances between all the devices posted on here so while a lot of folks might have been fine, some might not, but that seems to be the case for the Prime. Hence we saw posts from folks saying they were fine with battery when it was at a min of 370MHz while some had worse.
Also, the Prime does use a different CPU than the EVO 3D so that could be taken into account as well
Anyways, good read for those interested
-----
From http://forum.xda-developers.com/showpost.php?p=23384703&postcount=2110
Thanks for the feedback. I do appreciate it, but by the looks of your post, you didn't see my detailed description of why the frequencies are set to what they are now. I was more interested in what people are actually experiencing as far as performance and battery in real world tests and conditions. From your post, the information that I believe is relevant is that you think your phone runs fine at 192Mhz. I'll accept that for what it is (a data point) but I already know from experience that you are in the minority here. As soon as I released v1.1 with the 192Mhz min frequency, I immediately started getting inundated with people complaining that battery life was much worse, and the phone lagged more on occasion. Then when I brought the frequency back up to 384Mhz, the vast majority reported "thank you, battery life is back to phenomenal and lag is gone". Well, that's what got me on my quest to actually find and measure the needed frequencies.
No, neither HTC nor Qualcomm set these devices up to work as well as they actually can. They simply do not have the resources and the time. These things are rushed to market and updates are no better: they are designed to "make the device work". That's about it! So when I actually started testing these things, I found that 192Mhz was far too slow to make this phone work without lag. 384 fixed the problem but when I looked into it further, 486 worked even better, and without extra battery drain. I didn't pull these numbers out of a hat nor did I increase them for bragging rights. They are measured values of what the phone actually needs in order to keep up! I spent many hours testing different states, what frequencies are needed when the CPU wakes up when the screen is off, etc. Simply put, 192 doesn't cut it (not even close) and 384 doesn't quite cut it either. When you crunch the numbers, you find that the phone actually needed 432Mhz while running one core with the screen off and 540Mhz while running dual core with the screen on. Lowering those numbers caused the CPU to jump relentlessly between the min/max numbers and when you look at the time and crunch the numbers, it was always shooting for those figures: 432 with screen off and 540 with screen on!
In other words, if you crank it down to even 384Mhz while the screen is on and IDLING (not even running any games or other apps: what you called "waiting for input"), it'll hop up to 1188 much more frequently and in fact, crunch the numbers for the amount of time it spent at 384 and 1188 and get an average and you'll find that on average, the CPU was using about 540Mhz of power with the screen on and about 432Mhz with the screen off. I will add a disclaimer here that yours may be slightly different (up or down one notch in the time table) from the 432-off/540-on numbers, but I did test a variety of configurations as I said in my description when I released 2.0 and 432/540 minimum frequencies were the good middle ground that worked well under all setups from clean install to heavily loaded down. Part of the need for higher minimum frequencies is because with the screen off, there's an initial "crunch" when the CPU is awakened and that often requires more CPU power than when a longer task is being performed. And with the screen on, it is always doing more than just waiting for input from you! There's a lot more going on in there than you think. Even bumping the min screen-on frequency from 384 to 486Mhz caused a dozen posts saying "Wow, lag is completely gone" and "apps seem to open before I even touch the screen". This is not placebo. This is noticeable and even measurable in benchmarks! No, the phone CANNOT and will not instantly crank up to 1188 Mhz from 192 (or 384). I've proven this many times. It doesn't work that way.
You have to remember that the decision to ramp up to 1188 is made at 192Mhz! It only measures CPU load 20 times per second. And it will never be able to ramp up to 1188 in 1/20 second! The reason is that by the time the service reports a high CPU load (high enough to trip the up-frequency), you've already experienced 1/20 second lag minimum. At that point, it takes at least one more cycle to actually increase CPU frequency at which point you've experienced at least 1/10 second of lag. That is almost always noticeable. To complicate matters, if you look at the code for the daemon, you'll notice that it is a "nice" process which means other high priority system processes can actually "steal" time from the daemon and that can actually greatly increase the amount of time it takes for the daemon to actually raise CPU frequency once it notices the phone is lagging. By that time, you've already noticed additional wait to open an app, a "hiccup" while scrolling, etc. The reality is, your phone can lag at 192Mhz (or 384) for several 1/20 second cycles before the CPU is actually ramped up to the full 1188 and THAT is what causes the lag.
So long story short (I know, too late now) I have to discount all your questioning about whether or not I got the numbers right because your assumptions about the numbers are quite frankly all dead wrong! Your scale of the numbers in your car analogy doesn't fit either. I actually do performance tuning on (among other setups) Hemis. The analogy is more like: set your idle to 192 RPM and see if you can keep it running. If it does, it'll be loping like hell and then when you hit the gas, what happens? It bogs. It's because the system wasn't ready for the load. Set it to 540RPM and see how much better it responds. That's a better analogy here.
So I'm really interested in actual results more than people pulling their own numbers out of a hat and saying "these make more sense to me". A lot of testing went into the CPU tweaks in this ROM and I'm aware of "theories" about how people think 192 might be better or 384 is better. Been there done that. That was the boardroom stage... kinda where HTC and Qualcomm left it. We're already out on the track racing and making adjustments.
Oh, and the frequencies are no more "locked" now than they've ever been. I intentionally set up the init.post_boot.sh so that they can easily be changed. So if you want to run yours at the laggier, less efficient 192Mhz, the choice is yours. Just follow Lrod's instructions above. I was going to post those but he did a fine job.
Edit: I also notice you said at one point "So I don't understand why the decision was made in v2.0 to raise the minimum frequencies to 432mhz for core0 and 540mhz for core1.". CPU0 is never run at a different minimum frequency than CPU1. The numbers for min/max are:
- Screen off: CPU0 = 432/648, CPU1 = offline
- Screen on: CPU0 = 540/1188, CPU1 = 540/1188
And again, these numbers came from actual measurements and number crunching. Didn't matter what you used for minimum frequency: you could set it to 192 and run the phone for a day, and then set it to 384 and run the phone for a day. What you'd find is that regardless of what you picked, the CPU was always "hunting" for about 432Mhz with the screen off and about 540Mhz with the screen on. And with screen on, I mean the screen forced on but the phone doing nothing but idling on the home screen. The CPU was doing nothing but typical background tasks with an occasional email or SMS message coming in and maybe a stray screen scrolling thrown in infrequently.
Mike

[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!

(Scroll down to The Money Shot if you just wanna know the settings to use and skip all my preamble, but be aware that you may sacrifice results if you don't understand everything fully! You've been warned!!)
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor. :good:
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! I'm talking about 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*At least on the EvoLTE, you shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
The Background
I got my first Android phone (Galaxy S4) about 8 months ago, and after dropping it in the toilet a couple months ago, I had to get something cheap. Enter the EvoLTE.
Performance on the EvoLTE was not what I was used to, and that disappointed me. (I should rephrase. Performance while getting similar battery life was disappointing. What good is a fast phone if you can't use it cuz it's dead?) While I had immediately caved and ROOTed and installed a new ROM (CM 10.2), I soon pined for a new kernel with promises of overclocking, under-volting, new fangled governors, etc.
So, I S-OFFed and installed Haunted Kernel. Played with overclocking, used the suggested governor (smartmax), under-volted, all that jazz. One problem: constant reboots. My focus shifted from performance and battery to just getting it to run reliably.
To my dismay, I learned that my phone has no tolerance for overclocking, so I lost that speed boost. Further, it has no tolerance for under-volting, so I lost that power savings. And then I discovered the recommended governor (which gave pretty good battery life and so-so performance) was too buggy to be reliable, so I lost that balance.
I was never fully satisfied with the performance of that governor. It promised a lot. People raved about it. It was certainly very power-friendly and lag free, but it stuttered. Notice how everyone promises lag free, but rarely do they talk about smoothness as things slow down. You know what I mean... quick scroll through a webpage or list, and as it slows down it hops and jerks. I hate, hate, HATE that! But hey, you can't have all three--smoothness, snappiness, and stutter-free... right?
Wrong! (But I'm getting to that!)
Shifting back to stock CPU settings (clock speed and voltages) I turned my focus to the governors. Surely, I thought, one of these other fancy governors will satisfy my needs. But after weeks of tweaking and testing, I had to make a compromise in one way or another. None of them delivered the results I wanted, no matter how I tweaked them. They were better than the standard governors in many ways, but still didn't meet my expectations. I sat there, so disappointed. All these cool features to boost performance, save battery, all that... out of my reach. I was back to square one. Stock speeds, stock voltages, basic governors...
Basic governors...
...basic governors...
...basic governors..?!
Well that's something I hadn't looked into much, I thought.
I mean, why bother? Either they keep your CPU at a low clock speed, or a high one, or slowly scale between the two, or jump quickly between the two. Pretty basic stuff. The new fangled governors were designed to more efficiently finesse these brute choices to improve performance and battery life, so what would basic governors have to offer?
Nothing, I thought. Until I looked at the kernel source and realized that the Interactive Governor had some advanced features I'd never seen anyone use in their recommended settings. On any forum. Ever.
That's not to say it's some well-kept secret or that I'm the first person in the world to post about such things. But it's certainly not widely known or promoted well. Most people just jump onto some new fangled governor with default settings to provide some features that, in all honesty, we can find in a governor featured in practically all kernels, and actually may out-perform the new fangled governor in both performance and battery life!
After a bit of tweaking and experimenting, I developed some settings that provide absolutely incredible battery life, buttery smooth performance, and a lag free experience. And you don't need a fancy governor, or a custom kernel, custom clock rates, or even an EvoLTE. This will work on any ROOTed phone with the Interactive governor!
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for decompressing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on both cores using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups, and multiply that clock speed by your number of cores.
For example, on my EvoLTE, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the both CPUs clock rates are no less than 432Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Because the EvoLTE has 2 cores, we multiply 432Mhz * 2 = 864Mhz. Thus, the nominal clock rate for scrolling a webpage on my EvoLTE is 864Mhz.
Now, here's the rub. If you turn off one of the cores and turn the other core to 864Mhz, you will not find that it is smooth anymore. I will not write a dissertation regarding why this is the case. Suffice it to say, despite what is often incorrectly conveyed, multi-core usage is more efficient in multi-dimensional processing loads--such as rendering graphics, playing sound, or decoding video--than a single core's performance because the time spent at a given clock rate is non-linearly less than if it were processed on a single core at a higher frequency. We want a balance of battery life and performance, and that requires using both cores. The other core will kick on when necessary to "fill in the gaps" under such a load, so our measurement stands. For our purposes, the nominal frequency for a given task is the sum of the frequencies of all cores always on at a given clock rate.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Using stock voltages, the EvoLTE's efficient clock rates are:
384Mhz
702Mhz
1026Mhz
1512Mhz
These are the clock rates that are at the top tier of each of their voltage ranges, before each anomalous ratio jump. These are the most voltage efficient clock rates using stock EvoLTE voltages. If you are using a custom kernel or have changed your voltages (or a totally different phone altogether), your efficient clock rates may be different. Calculate them as applicable to your setup! List the clock rate differences between each frequency step and the differences for each frequency's voltages. You will see an anomalous voltage jump every several frequency steps. The frequency before this jump is the next efficient clock rate. Write it down and keep going through the frequency steps until you have exhausted them.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I am using stock voltages, I use the efficient clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 189Mhz
Page Scrolling - 864Mhz
Video - 1134Mhz
App Loading - 1350Mhz
High Load Processing - 1512Mhz
(Note that my nominal idle speed is less than stock. This is why you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
Once you've listed all of your nominal clock rates, try to consolidate them if you have more than 3. (This is not entirely necessary as you'll see later, but it simplifies things significantly until you're more comfortable dictating more than a few clock rates for your needed task loads.) If you have any tasks that rest in the far upper portion of the frequency spectrum, discard them! We are by no means underclocking anything, but we are trying to keep the CPU clock rate as low as possible for as long as possible. However, the fastest frequencies will be available for sustained load processing, as you will see later. In my case, in addition to discarding the "high load processing", I'll sacrifice a (very) little app loading speed and consolidate video and app loading:
Idle - 189Mhz
Page Scrolling - 864Mhz
Video/App Loading - 1134Mhz
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
Idle - 189Mhz efficient / 189Mhz nominal
Page Scrolling - 710Mhz efficient / 864Mhz nominal
Video/App Loading - 1026Mhz efficient / 1134Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000​
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 702000:60000​
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 702Mhz. (If you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using an EvoLTE, use the following Interactive governor settings and then tweak with the instructions below:
(If you are using a phone other than an EvoLTE, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000 702000:60000 1026000:150000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 384000
io_is_busy - 0
min_sample_time - 40000
target_loads - 98 384000:40 702000:80 1026000:95
timer_rate - 30000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 710Mhz/864Mhz rates, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "710000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
I will be happy to answer any questions, or provide any guidance I can. However:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
I will not answer questions about "what is a governor?" There are plenty of resources available already, so search for them.
I will not answer questions about "how can I tweak [some other] governor?" This is about the Interactive governor only.
I will not respond to "nuh uh! show proof!" posts. The fact that I spent 12 hours writing this up should be proof enough that I am satisfied with the results. You can take it or leave it; makes no difference to me. The default settings should work with any fully optimized EvoLTE, so just try them on your own. If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
Really nice write up! Easy to read and understand. One question, how exactly are you changing the above high-speed delay. I input exactly but when I save and go back it's bank only to 20000
Sent from my EVO LTE using XDA Premium 4 mobile app
Great article!
jmkarnai01 said:
Really nice write up! Easy to read and understand. One question, how exactly are you changing the above high-speed delay. I input exactly but when I save and go back it's bank only to 20000
Sent from my EVO LTE using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I was wondering the same thing.
jmkarnai01 said:
Really nice write up! Easy to read and understand. One question, how exactly are you changing the above high-speed delay. I input exactly but when I save and go back it's bank only to 20000
Sent from my EVO LTE using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I use the the fku updater app the paid version and all my settings stick on my g3 and my m8
Nice write up. Just the sort of info I've been looking for
Well done sir
Great information here!
Finally someone makes complete guide on this governor
hello..i am not an advanced user like you guys..great work !..i try my best to understand,i read threw every word,even though i dont have your device.i am useing a htc m8 on sprint..i flashed the kernal after reading all about it..i do want amazeing battery life,i work all the time,constantly networking and listening to music,useing data all the time really,i understand these things will kill battery no matter what..i also know you said if we have abother device other than the evo the device you laid out exact settings for,we would have to tweak on our own..and without you haveing the device i have im sure be hard to give some advice..couple questions?- 1.)if i just use default settings,and change nothing will it benifit me at all,or did i just flash the kernal for nothing,since im not advanced enough to really tweak kernal on my own..2)is there anyway possible to get exact instrutions for my device like you gave for the evo...just wanted to add how lucky users of that device are for you to of givein these details,you seem to of really mastered that device..thanks for hard work either way..if i cant get nothing out of this,its ok i can allways just wipe device and restore back up without the kernal installed...
Very nice, well-written guide. Thanks a lot!
@soniCron: How do I turn on and of cores one by one? I have quad core.
Hi soniCron, I just wanted to let you know that I followed your guide and tweaked my OnePlus One. Great results so far, and stellar battery life. I'm very happy with it, thanks
Phazonclash said:
Hi soniCron, I just wanted to let you know that I followed your guide and tweaked my OnePlus One. Great results so far, and stellar battery life. I'm very happy with it, thanks
Click to expand...
Click to collapse
Can you share your changes/parameter settings?
Maybe via pm if not using the thread?
solar666 said:
Can you share your changes/parameter settings?
Maybe via pm if not using the thread?
Click to expand...
Click to collapse
above_hispeed_delay 20000 652800:20000 1190400:40000 1497600:60000 2265600:80000
boost 0
bootpulse duration 80000
go_hispeed_load 99
hispeed_freq 652800
io_is_busy 0
mac_freq_hysteresis 10000
min_sample_time 60000
target_loads 98 652800:40 1190400:70 1497600:80 2265600:90
timer_rate 30000
timer_slack 40000
How the lemon does this guide only have 2 pages?
Great guide, thanks a lot, going to try it with my oneplus one now
thewind730 said:
I use the the fku updater app the paid version and all my settings stick on my g3 and my m8
Click to expand...
Click to collapse
Can you share please your M8 settings and tell if it really had an impact on performance and battery life. Thanks.
Also I cannot save the edited parameters files under /sys/devices/system/cpu/cpufreq/interactive although I have full root. Any suggestions? I have an HTC One M8 with ViperOneM8 4.3, rooted and S-Off.
Sent from my HTC One_M8 using Tapatalk
tghandour said:
Can you share please your M8 settings and tell if it really had an impact on performance and battery life. Thanks.
Also I cannot save the edited parameters files under /sys/devices/system/cpu/cpufreq/interactive although I have full root. Any suggestions? I have an HTC One M8 with ViperOneM8 4.3, rooted and S-Off.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Sent from my HTC One_M8 using Tapatalk
I'm testing this guide on my LG G2 and it seems to work pretty well.
Good job :good:
Awesome! I just tweaked mine now to the lowest frequencies that is lag free and will check tomorrow if battery life of my htc one m9 has improved somehow.
Also you might want to add this link to kernel cpu governor documentation. Which pretty much explains the other variables.
tghandour said:
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Can u share ur m8 settings to try out please...... Thanks
HTC m8 on arhd 43 using dark blue Tapatalk from jokerpoker1

Categories

Resources