Can someone tell me what ideal settings they have found for setcpu, particularly in the advanced tab? I would like to play around with the Sampling Rate, the Up threshold and Power Save Bias.
I know it is some what ROM and Kernel specific but a push in the right direction would be helpful.
I am running S3VO ROM by Deck and I am using NetArchy 3.7.8b.
Thank you very much!
I'm also interested in this!
Moto Droid running ChevyNo1's SS 4.6 Froyo ROM and his newest ULV 1.25ghz kernel. My battery life isn't bad but wondering if it could be better.
Also wondering if this would help fluidity on my homescreen scrolling. If i keep the min @ 250 the scrolling is choppy (presumably because the ondemand scaling doesn't increase from 250 fast enough to handle it) but if I keep the min @ 400 then it runs much smoother. Does anybody know if the Sampling Rate or Up Threshold would affect this?
I don't know a whole whole lot about it, but I'm pretty sure the Sampling Rate determines how often the cpu load is checked and the Up Threshold is the load required before it will clock up or down. I don't know too much about the other two and haven't played with them too much. Higher sampling rate and higher up threshold should conserve battery theoretically, but the 20 second upper limit is way too long without checking cpu load, so be careful there. I use 50000 (half a second) with a 90 up threshold personally to conserve a little battery but mainly so I don't lock up my phone when turning the screen on (245 frequency limit while screen is off). I'm no expert, but that's what I've seen from my experience. I'd like to know what others have to say as well.
axlebot said:
I don't know a whole whole lot about it, but I'm pretty sure the Sampling Rate determines how often the cpu load is checked and the Up Threshold is the load required before it will clock up or down. I don't know too much about the other two and haven't played with them too much. Higher sampling rate and higher up threshold should conserve battery theoretically, but the 20 second upper limit is way too long without checking cpu load, so be careful there. I use 50000 (half a second) with a 90 up threshold personally to conserve a little battery but mainly so I don't lock up my phone when turning the screen on (245 frequency limit while screen is off). I'm no expert, but that's what I've seen from my experience. I'd like to know what others have to say as well.
Click to expand...
Click to collapse
Very good advice ... I have seen slightly improvement on putting this into my settigns...
axlebot said:
I don't know a whole whole lot about it, but I'm pretty sure the Sampling Rate determines how often the cpu load is checked and the Up Threshold is the load required before it will clock up or down. I don't know too much about the other two and haven't played with them too much. Higher sampling rate and higher up threshold should conserve battery theoretically, but the 20 second upper limit is way too long without checking cpu load, so be careful there. I use 50000 (half a second) with a 90 up threshold personally to conserve a little battery but mainly so I don't lock up my phone when turning the screen on (245 frequency limit while screen is off). I'm no expert, but that's what I've seen from my experience. I'd like to know what others have to say as well.
Click to expand...
Click to collapse
Sampling Rate – An interval (in microseconds) at which the governor will poll for updates. When this happens, the governor will decide whether to scale the CPU up or down.
A microseconds is a milionth of a second .. => half a second is 500000 microseconds not 50000
Related
I was just wondering if it's possible to underclock HTC Desire bellow 245MHz to save even more battery life or to just lower the minimum value bellow 245MHz when set on ondemand?!
Just a guess, but I am imagining the underclocking is established by changing the multiplier on the processor. The multiplier can only take integer values, hence the discrete values the CPU will clock to. If this is the lowest multiplier value, then it wont be possible to underclock further (apart from turning the CPU off totally...)
Been posted before...
128MHz was tested for a while, but 245MHz is the minimum safe amount before the Desire becomes unstable/unresponsive in normal use.
PaulW21781 said:
Been posted before...
128MHz was tested for a while, but 245MHz is the minimum safe amount before the Desire becomes unstable/unresponsive in normal use.
Click to expand...
Click to collapse
Oh, tnx! i'll search for it! And btw i was thinking to use this underclock only when screen off.
I think it can still cause issues then too, for instance if you get a call or background processes which need it.
Either way, 245MHz is still quite a respectable drop (and power saving frequency) if you set it in SetCPU.
I have mine 245/384 for screen off. And varying speeds per 5% battery drop from 90%... Overkill maybe, but hey, I want battery life! lol
I am running Chad's 12-23 kernel on a mostly stock ROM, and have been testing between the on demand governor and the smartass governor, trying to determine which would give better battery life. I ran a log over a 1 minute period with the phone on/awake, but idle. I did NOT kill any background processes, and ran both tests back to back so running processes shouldn't have changed.
Over a one minute period, the governors averaged the following:
On demand
264 mhz
20% load
Smartass
371 mhz
14% load.
As a side note, the smartass governor scores slightly, yet consistently higher on quadrant, seems to run a much more stable framerate on the planet-and-moon graphics test.
so which should be better for batter, and why? lower speed, or lower load?
In general, smartass should provide better battery life than ondemand since it doesn't scale upwards as violently.
Sitting idle with the screen on isn't the best condition for comparing different governors. Since the governors affect the speed and level of scaling, you would want to test under conditions that have more dynamic processing needs.
While it doesn't answer all the questions you have, you might find this helpful:
Effects of CPU Frequency and Screen Brightness on Power Consumption
The funny thing is that even the On Demand governor on this kernel seems modified. On the stock kernel, on demand usually idles much higher, 600-700 mhz. So whatever changes Chad has made overall are causing on demand to be more conservative as well.
I don't really know a method to test under more dynamic circumstances. I'm simply observing in System Panel. But the logging feature it has doesn't get super detailed with CPU speed. Only the realtime monitor. About the only "test" I could do was to scroll the app list up and down on the system panel screen. This causes the mhz and load to jump up pretty much immediately to 800+ mhz. I did not see ANY difference in this between the two governors, they both seem to ramp up equally aggressively, and both would jump to about the same mhz.
bast525 said:
I don't really know a method to test under more dynamic circumstances.
Click to expand...
Click to collapse
You could set up scripts that run various commands/processes, with sleep times in-between.
Do you have Tasker? You could set up Tasks that not only would automate various processes, thereby exposing your CPU to dynamic (yet controlled) conditions, but Tasker now has %CPUFREQ which could record the current CPU frequency throughout the test.
There are also the Frequency Stats to the be found in SetCPU, Android System Info, or I'm sure a host of other apps. They show you how long your CPU has spent at any given frequency. The only catch is that I don't know how to reset those stats (as it's not really a function I use).
Since you are concerned with power use, you would also want part of your logging to include mA current being drawn from the battery.
Just brainstorming. There are a lot of ways you could set up more controlled tests.
OK, so digging a little bit, this should be even easier than I thought. The Frequency Stats are contained in /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
It looks like rebooting can reset them, but I haven't yet figured out a way to reset them without resetting the device. But it doesn't really matter Once you come up with a testing script, you can have it store a copy of time_in_state at the very beginning of the test, and then again at the end of the test. That way, you can simply compare the time_in_state at the end of the test to the one at the beginning to see just the influence of that test.
Question: if the kernel will go into deep sleep whenever it has nothing to do, what is the benefit in regards to power consumption of pinning the clock speed real low when the screen is off?
I ask because common knowledge, at least from what I've seen around, is that the low-clock "screen off" profile is common sense. But today I tried not having that profile, and I see that the CPU goes into deep sleep a lot more time now, and my battery life is the same if not actually better than before.
True, ROMs and kernels are still changing so much that it's difficult to dedicate enough time to one configuration to actually determine it's efficiency over time, which is why I wanted to throw this out here, see if anyone with more knowledge can answer.
If the CPU is under a certain amount of load, I would imagine that, for instance, in an Ondemand governor with a very low Up Threshold, the CPU will spike to a high speed until it's done, then sleep the rest of the time until the next load. If constrained to a low clock speed, it'll work on it, slow but steady, until it's done.
Is the high voltage required for that spike offset by the voltage savings of going to sleep, and is the total voltage consumption at the end of the load lower than the alternative, that is, stick to a low clock cycle, consuming what I assume is lower voltage, but for a longer amount of time? Is voltage consumption as clock cycle speed increases linear, or exponential?
If the power consumption increases exponentially as clock speed increases linearly, then it might be better for power consumption to restrict the processor to lower speeds. But if power increase is linear, then it would be better, I believe, to let the CPU finish with it's load as fast as it can, so it can go to sleep faster.
Any thoughts, ideas?
To Quote from Wikipedia's Overclocking page:
Increasing the operation frequency of a component will usually increase its thermal output in a linear fashion, while an increase in voltage usually causes heat to
increase quadratically
Click to expand...
Click to collapse
I know nothing about the Galaxy S II specifically, but most Android phones scale both voltage and clock-speed together, leading to exponential power increases when clocking up. Thus, in theory, you should see better battery life with a lower CPU limit with screen-off.
If in your case you have constant voltages across the board, that would explain why you see no benefit from a screen-off profile.
Finally, if you do have constant voltages across clock-speeds, then you probably could lower your voltages at lower speeds and thus realize a benefit.
YMMV, of course
Yes but if you have processes running in the background like large file downloading then the phone won't be able to process any of them
Sent from my SGH-T989 using xda premium
hi,
I am running stock jellybean with franco kernel. just wondering what is the optimal CPU setup that doesnt sacrifice too much performance while increasing battery life. Im not too concerned about games as I rarely play them. I ussualy use the phone for music, calls, text, email, and webbrowsing.
I am using the Franco updater app. I have 1228 max, 230 min
and screen off max is 384.
I also noticed in cpu spy that my highest two frequencies 1036, 1228 are combined less than 10%.
with all that information, what do you suggest?
hshaikh said:
hi,
I am running stock jellybean with franco kernel. just wondering what is the optimal CPU setup that doesnt sacrifice too much performance while increasing battery life. Im not too concerned about games as I rarely play them. I ussualy use the phone for music, calls, text, email, and webbrowsing.
I am using the Franco updater app. I have 1228 max, 230 min
and screen off max is 384.
I also noticed in cpu spy that my highest two frequencies 1036, 1228 are combined less than 10%.
with all that information, what do you suggest?
Click to expand...
Click to collapse
I suggest to decrease your max CPU until you feel it affects performance too much. You can also try switching to a governor less aggressive than interactive (try ondemand).
Don't expect magic though. I've played with decreasing max CPU clock, max CPU screen off, governor settings etc with three different kernels. Gathered stats for at least one week each time. Never noticed a difference large enough to actually matter to me. For maximizing battery life, you can gain more by hunting apps that cause a lot of (partial) wakelocks and alarms, and use low screen brightness.
hshaikh said:
and screen off max is 384.
with all that information, what do you suggest?
Click to expand...
Click to collapse
don't limit screen off cpu speed to 384. it will take longer to perform operations under wakelock, thus killing of more battery than it actually saves.
it would be nice if listening to music, since it's not an intensive task and it requires constant cpu usage. still, you'll most likely have stuff syncing in the background so i don't think you're doing any good by limiting it to 384 on screen off.
power isnt going to be conserved with lower clock speed. lower clock speed means it takes longer to finish the task. to conserve power, your phone has to do less. for example, lower brightness, no sound, less/no syncing.
Darunion said:
power isnt going to be conserved with lower clock speed. lower clock speed means it takes longer to finish the task. to conserve power, your phone has to do less. for example, lower brightness, no sound, less/no syncing.
Click to expand...
Click to collapse
Well, there is an optimum somewhere. Higher CPU speed means tasks are executed more quickly, but higher clock speeds also draw more current from the battery. I agree that tweaking this has little effect on battery life though.
Petrovski80 said:
Well, there is an optimum somewhere. Higher CPU speed means tasks are executed more quickly, but higher clock speeds also draw more current from the battery. I agree that tweaking this has little effect on battery life though.
Click to expand...
Click to collapse
you are correct. there is a magic middle ground because power consumption doesnt scale in a linear way. but finding that spot would take massive testing and even getting to the center, would still probably only gain about 10-15mins average use on a battery charge :/
bk201doesntexist said:
don't limit screen off cpu speed to 384. it will take longer to perform operations under wakelock, thus killing of more battery than it actually saves.
it would be nice if listening to music, since it's not an intensive task and it requires constant cpu usage. still, you'll most likely have stuff syncing in the background so i don't think you're doing any good by limiting it to 384 on screen off.
Click to expand...
Click to collapse
what speed show i set to max when screen is off.
did you read anything that Darunion and Petrovski80 wrote? I keep mine at it's max, i don't care, i don't live in the woods with no electricity.
thanks for your inputs. i have experimented and I found out that changing the cpu speeds has minimal effect of battery life. the clock speed is not killing the battery the screen is. no matter what cpu settings i use i get 3-4 hours screen on time.
if i dont use the phone alot that day (like 1 hour screen on time) the battery will still be 40% after a day.
hshaikh said:
thanks for your inputs. i have experimented and I found out that changing the cpu speeds has minimal effect of battery life. the clock speed is not killing the battery the screen is. no matter what cpu settings i use i get 3-4 hours screen on time.
if i dont use the phone alot that day (like 1 hour screen on time) the battery will still be 40% after a day.
Click to expand...
Click to collapse
Exactly. I get similar performance.
Sent from my Galaxy Nexus using Tapatalk 2
I've been thinking a lot about governors lately.
I'm thinking now that you want the cpu to ramp up as fast as possible to complete the task as fast as possible and then go back to sleep, i.e. ondemand.
A given task takes a specific number of clock cycles to complete so your clock frequency simply dictates how long until the task completes.
A cpu has static losses, leakage currents and whatnot, that are there regardless of frequency.
So unless your energy per clock cycle goes up with frequency, it seems you'd want to run as fast as possible to minimize static losses.
I also would guess you want the second core to stay off as much as possible.
Any thoughts or opinions?
MrTallboy said:
I've been thinking a lot about governors lately.
I'm thinking now that you want the cpu to ramp up as fast as possible to complete the task as fast as possible and then go back to sleep, i.e. ondemand.
A given task takes a specific number of clock cycles to complete so your clock frequency simply dictates how long until the task completes.
A cpu has static losses, leakage currents and whatnot, that are there regardless of frequency.
So unless your energy per clock cycle goes up with frequency, it seems you'd want to run as fast as possible to minimize static losses.
I also would guess you want the second core to stay off as much as possible.
Any thoughts or opinions?
Click to expand...
Click to collapse
Sounds a lot like ktoonservative.
Aerowinder said:
Sounds a lot like ktoonservative.
Click to expand...
Click to collapse
Yeah, ktoonservative lets you configure pretty much everything. The thing I was struggling with was setting up_threshold and sampling rate. It seems like depending how fast it's evaluating load, processes could build up and force the second core on when it isn't really needed. It seemed like the 2nd core turned on less with a faster sampling rate.
I don't know the down side of sampling too fast.
Pegasusq seems pretty cool in that the 2nd core turns on based on frequency and queue rather than just load. You can pretty much control exactly when the 2nd core comes on.
I'm trying out msm-dcvs right now even though I don't really know what it does and it's apparently not configurable. I'm not on ktoonsez at the moment so I don't have many choices.