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.
If I can undervolt my CPU to run 600MHz at a lower voltage than stock runs 300, any reason I wouldn't set my min to 600?
In trying to avoid some of the "wake-up" issues people have experienced, I've been running 400/800/1200 today, and it seems stable...
No reason why you couldn't, but because you could set it to lower than stock voltage, by that reasoning you could set it even lower by undervolting at 300mhz, therefore you're still losing out on a potential power saving
Hello!
I recently noticed how frequencies 122MHz through 460MHz all employ the same voltage (900mV). I've come to understand that the higher the CPU frequency the faster your battery will drain. What I don't understand is why a higher frequency will drain your battery faster.
Is the only cause for higher battery drain when running a higher frequency, the higher voltage which comes with a higher frequency, or are there other factors?
If, then, a higher voltage is the only cause, then my battery would not drain faster if I clocked my minimum frequency at 460MHz instead of 122Mhz?
Thanks in advance to anyone who can shed some light on this!
Hi
cpu power consumption at a specific frequency is bound to its voltage.
you should test a voltage for a frequency while your device has 100% workload, because you could find a voltage so that your device is stable while being idle, but freezes when it needs to work. (for more information search for linux phc)
my conclusion:
the voltage for a specific frequency has minimum!
you can set your minimum frequency to 460 if you want to, since the screen consumes most power, it should not matter that much. i have set my minimum freq that high, too. I believe that way, my phone needn't raise the frequency when dooing simple stuff, like playing music.... but i am just guessing.
i theory it must get hotter than at lower frequencys, but i did not notice that.
i have had a palm pre and a custom kernel introduced a voltage on demand governor, which kept the device at 1ghz all the time, but changes the voltage with the workload. i think the developer of the awesome idea is "unixpsycho" ... i would like to see something similar on android.
greetings
matto
EDIT:
http://en.wikipedia.org/wiki/Dynamic_frequency_scaling
it looks like it is bound to the frequency, too!
~const*f*V^2
the Voltage is quadratic, that means it tkes a higher priorety.
e.g. lowering the voltage from 900mv to 800mv => (0.8^2)/(0.9^2) ~ 0.79
460mhz*0.79~363mhz
=> [email protected] consumes as much power as [email protected] (Stock)
I'm wondering if anyone's undervolted and to what values.
I'm also wondering waht the deafult values are and if they change per kernel.
Is there a way to disable SetCPUs undervolting settings?
Has anyone improved battery life with profiles? On the Eris this was the only way to get usable battery life.
Or not. I gave up undervolting after I actually compared battery life at stock values vs undervolted (on my old phone, sgs4g) and discovered it does nothing for battery life.
Edit: undervolting "might" marginally increase standby battery life, but considering how good this phone already does... it certainly won't increase actual screen on usage.
Sent from my Galaxy Nexus using xda premium
Depends how low you under volt. Got more battery life, maybe about an hour, after finding optimal battery life on my gfs Gnex.
If you don't under volt correctly, of course it won't improve battery life.
From my sexy white, Nocturnaled HTC One X
If you're not overly comfortable with undervolting, then using one of the many kernels with Smart Reflex will do a mild undervolt for you. If you are comfortable, then the only way to find numbers good for your phone is to try and test. I tweaked mine down to the point that I was occasionally getting hot boots when the screen was off and media was playing. Tweaking the numbers back up added the needed stability. Even little things like kernel or ROM revisions can change what voltage is or isn't stable. Another example is that when I updated my Jellybro CM10 version the other night, along with updating leankernel from 4.1.0exp3 to 4.2.0, I had to increase a few of my voltages to avoid hot boots.
Just for example numbers, here are mine:
Code:
1350MHz -- 1200mV
1200MHz -- 1150mV
920MHz -- 1050mV
700MHz -- 950mV
350MHz -- 825mV
These numbers will vary from device to device and even between ROM/kernel combinations, so don't use them as hard fact.
Thanks. On a phone like this it might not make a huge difference but on the Eris (Where stock battery life could sometimes be 6 hours if you actually used your phone) an undervolted kernel with setcpu could turn those 6 ours into 48.
Thanks Cilraaz, I'll try those voltages out and benchmark a bit to see if they're stable for my system.
Two things I can say for sure:
1. you will have very limit battery gain by undervolting with Gnex, no matter how low you try.
2. undervolting will bring some stable issue if you get too low, like lose signal and reboot.
I am using Kernel Franco GPU 384 Stock rom on my 4.1.1 and did undervolting
Current configuration:
384Mhz
950mv
------------
729Mhz
1050mv
-----------
1036mhz
1125mv
----------
1228mhz
1275mv
-------------
I did not change the frequencies of overclocking, because I'm not using them.
I felt an improvement in battery consumption unless the unit is heating up.
Just curious - what kind of profiles are you using? I have a "Screen off" that's 350min and 700max. I figure that's fast enough f someone calls me.
I've read many times undervolting isn't worth it.
Hungry Man said:
Just curious - what kind of profiles are you using? I have a "Screen off" that's 350min and 700max. I figure that's fast enough f someone calls me.
Click to expand...
Click to collapse
I'm using the following with SetCPU: default (1350MHz-350MHz), charging, CPU temp > 64, and battery < 35%.
If you're using a kernel and governor that support hotplug, then you likely don't want to use a screen off profile. The combination of the two can tend to cause sleep-of-death or hot boots.
I Am Marino said:
I've read many times undervolting isn't worth it.
Click to expand...
Click to collapse
Most people don't want to spend the time to do it right.
I'm actually not used to the new kernels. I haven't messed with my eris in about a year and back them there was "smartass, on demand, performance," and some other one that clocked down instead of up
Can you explain th escreen off profile causing issues? I don't even know what hotplug is lol I've been out of Android for a long time.
Hungry Man said:
Can you explain th escreen off profile causing issues? I don't even know what hotplug is lol I've been out of Android for a long time.
Click to expand...
Click to collapse
Hotplug disables one of the CPU cores when the screen is off. Some governors, like hotplugx, will also attempt to disable a CPU core during periods of low CPU usage. For some reason, this combined with a screen off profile can cause some problems. I assume it's because of the "screen-off-max-freq" that Imoseyon mentions in the quote below.
Personally, I prefer the interactivex governor with leankernel by Imoseyon. From his kernel thread:
With interactiveX V2 (for gnexus), things are a bit different, since gnexus has built-in support for screen-off-max-freq for all its governors. I took the new interactive code in gnexus, added early_suspend support (screen off/on trigger), and then added logic to the code so the governor uses the phone's built-in hotplugging capability to turn off cpu1 when screen is off (and then turn it back on when screen comes back on). Cpu1 goes offline entirely - no idle, no sleep.
Click to expand...
Click to collapse
I think undervolting helps - my phone is running 728 - 1228 using the interactive governor, with voltages of 600 mV, 700 mV, and 800 mV (728 MHz, 1036 MHz, 1228 MHz respectively) and I haven't had any issues so far. I know there are some reports that say undervolting doesn't help much, but those are when people undervolt by like 50 mV, whereas here I'm going like 400 mV under lol. (Yes, smart reflex is off).
Thanks Cilraaz. Good to know.
So turning the screen-off profile could improve things? Honestly, my system does fine at 350mhz with screen off. Turning a core entirely off would probably help though.
If I use hotplugx governor that would disable one core when the screens off, right?
Hungry Man said:
If I use hotplugx governor that would disable one core when the screens off, right?
Click to expand...
Click to collapse
Hotplugx will disable a core when the screen is off or when there is low system load. Depending on your kernel/governor choice, other governors may do it also. On leankernel, for instance, interactivex will disable a core when the screen is off, but not on low system load.
Ok, thank you.
I haven't done any comparisons of before/ after since I undervolted/ underclocked first thing. But I was browsing for hours while listening to music while talking to a friend with GTalk. talked for about 1.5 hours with someone, Left it on overnight (10 hours), woke up, used it to talk (voice to text) to someone via GTalk, and it's 3:25PM right now and I still have a fair amount of battery life left.
I'd heard mixed things about the battery on this so I'm happy.
My voltages:
1650: 1300
1520: 1250
1350: 1175:
1200: 1125
920: 1000
700: 925
350: 900
I stress tested each one without a crash.