Related
I've seen a few different posts in some of the kernel threads debating whether SetCPU is helping or hurting battery life. SO, I'm just kind of curious to see what results are on a larger scale? Based on your own experiences, do you have SetCPU installed and if so, does it help or hurt battery life generally? Also, if you do have it installed, do you use profiles? What are the most beneficial settings to use?
1. Not in right section
2. SetCPU not intended for battery life
3. It only adjusts CPU clockspeed
4. This thread is mostly meaningless
5. It's been discussed ad nauseam.
charnsingh_online said:
1. Not in right section
2. SetCPU not intended for battery life
3. It only adjusts CPU clockspeed
4. This thread is mostly meaningless
Click to expand...
Click to collapse
SetCPU is not intended for battery life? Go to the Market and look at the description. If I posted this in the wrong section I apoligize. But, I think you are mistaken with your comment about SetCPU not being intended to increase battery life or increase performance...
THATTON said:
SetCPU is not intended for battery life? Go to the Market and look at the description. If I posted this in the wrong section I apoligize. But, I think you are mistaken with your comment about SetCPU not being intended to increase battery life or increase performance...
Click to expand...
Click to collapse
SetCPU only sets clock speeds and governors already in the kernel. If you just install SetCPU and adjust no settings your battery life will not change. Thus, "does SetCPU help battery life?" is utterly and completely meaningless.
Discussion of different governors and clock speeds has occurred (and is still occurring) ad nauseum and is really more suited for the General forum.
Thread moved as it does not pertain to N1 development.
I see very little gains from setcpu but I use it because I purchased it from the market and why not use it if you bought it right?
This method does not apply to drug addiction LOL
-Charlie
bri3d said:
SetCPU only sets clock speeds and governors already in the kernel. If you just install SetCPU and adjust no settings your battery life will not change. Thus, "does SetCPU help battery life?" is utterly and completely meaningless.
Discussion of different governors and clock speeds has occurred (and is still occurring) ad nauseum and is really more suited for the General forum.
Click to expand...
Click to collapse
lol Why would you download an application, not use it, and expect results?
If you throttle your CPU down you WILL get better battery life. My phone is set to never go over 600mhz and I get bettter life with it than if I turn off setcpu altogether.
charnsingh_online said:
1. Not in right section
2. SetCPU not intended for battery life
3. It only adjusts CPU clockspeed
4. This thread is mostly meaningless
Click to expand...
Click to collapse
You have a lot of knowledge, this is obvious but you're unnecessarily harsh (mean).
It's boring but's it's a legitimate question because people still make inaccurate conclusions about CPU and battery life. Those of us with some knowledge can really help those that are trying to understand.
#2 above is correct. But the question remains, does a forced lower clock speed ceiling have an effect on battery life? It could do, of course it could, but without a baseline and a control environment it's impossible to prove either way. I suspect the OP is simply looking for subjective opinions.
And on this basis I offer:
The CPU only has a material effect on battery drain when it's being utilised.
When the Nexus CPU is not required to work it idles using the lowest power possible
The radio (network) interface is the second most demanding element of on your battery over time (next to the display). Although the CPU peak demand is higher than the radio.
SetCPU does not impact radio battery use.
SetCPU can not have a positive effect on battery usage if it's using more power to run it's clock cycles.
SetCPU can force the processor to use less power (wind down speed).
Slowing the processor means some tasks will take longer to perform.
If those tasks require a high-drain elements (display, radio, WiFi or BT for example) then it's counter-productive (battery wise) to slow them down.
However, because CPU power consumption does not have a liner relationship to clock speed, then some tasks that don't use high-drain elements will consume less power to complete.
So, whilst it's unlikely that your battery life will benefit from the use of SetCPU alone there is a chance that it will.
SetCPU is a fantastic app designed for overclocking, the profiles are niche facilities that may offer battery benefit to a narrow range of users.
Hey djmcnz thanks for the indept look at this app but more importantly thanks for showing respect to those of us who are just learning. We all have to learn information at some point and there are people that forget that at one point some one had to tell them.
Thank you for the clarification on that! Djmcnz-that was exactly what I was looking for in terms of an answer. I really appreciate you taking the time out to explain everything for me and anyone else that may have been curious.
charnsingh_online said:
1. Not in right section
2. SetCPU not intended for battery life
3. It only adjusts CPU clockspeed
4. This thread is mostly meaningless
Click to expand...
Click to collapse
Don't know why you're so pissed off by a thread...
1. Not a very big issue. We have mods here to take care of this.
2. I don't know if SetCPU affects battery life or not but similar thing on a PSP device does increase the battery life. I have tried it on my PSP and setting the clock speed to the lowest acceptable level (depending upon what you're doing) does help maximizing the battery life.
3. You're absolutely right here.
4. Don't know what to say man.. but being a little humble doesn't hurt....
I never meant to be rude. I always get pissed off when people post in wrong sections Seriously. If people post in right section it just frees up moderator time. And about CPU nexus CPU has same voltage for many frequencies like 998,960 have same voltage. Going so down doesn't mostly benefit. So setcpu is only good for overclocking IMO. Display uses most of the power along with radio n CPU is one of those in middle of usage maybe 3rd or 4th. So underclocking will give a big battery boost is just a placebo. Atmost 10 minutes more is what underclocking can provide. N its not worth sacrificing the performance. Go for something underpowered if u want to underclock IMO. So setcpu serves more purpose of power than battery
I use it for the cool widget and standby/idle profile. B-)
you know what?youre allright.i follow your threads and you explain things well for someone like me learning all this ****.i got no time for keyboard commandos.thanks for the explanation.
djmcnz said:
You have a lot of knowledge, this is obvious but you're unnecessarily harsh (mean).
It's boring but's it's a legitimate question because people still make inaccurate conclusions about CPU and battery life. Those of us with some knowledge can really help those that are trying to understand.
#2 above is correct. But the question remains, does a forced lower clock speed ceiling have an effect on battery life? It could do, of course it could, but without a baseline and a control environment it's impossible to prove either way. I suspect the OP is simply looking for subjective opinions.
And on this basis I offer:
The CPU only has a material effect on battery drain when it's being utilised.
When the Nexus CPU is not required to work it idles using the lowest power possible
The radio (network) interface is the second most demanding element of on your battery over time (next to the display). Although the CPU peak demand is higher than the radio.
SetCPU does not impact radio battery use.
SetCPU can not have a positive effect on battery usage if it's using more power to run it's clock cycles.
SetCPU can force the processor to use less power (wind down speed).
Slowing the processor means some tasks will take longer to perform.
If those tasks require a high-drain elements (display, radio, WiFi or BT for example) then it's counter-productive (battery wise) to slow them down.
However, because CPU power consumption does not have a liner relationship to clock speed, then some tasks that don't use high-drain elements will consume less power to complete.
So, whilst it's unlikely that your battery life will benefit from the use of SetCPU alone there is a chance that it will.
SetCPU is a fantastic app designed for overclocking, the profiles are niche facilities that may offer battery benefit to a narrow range of users.
Click to expand...
Click to collapse
djmcnz said:
You have a lot of knowledge, this is obvious but you're unnecessarily harsh (mean).
It's boring but's it's a legitimate question because people still make inaccurate conclusions about CPU and battery life. Those of us with some knowledge can really help those that are trying to understand.
#2 above is correct. But the question remains, does a forced lower clock speed ceiling have an effect on battery life? It could do, of course it could, but without a baseline and a control environment it's impossible to prove either way. I suspect the OP is simply looking for subjective opinions.
And on this basis I offer:
The CPU only has a material effect on battery drain when it's being utilised.
When the Nexus CPU is not required to work it idles using the lowest power possible
The radio (network) interface is the second most demanding element of on your battery over time (next to the display). Although the CPU peak demand is higher than the radio.
SetCPU does not impact radio battery use.
SetCPU can not have a positive effect on battery usage if it's using more power to run it's clock cycles.
SetCPU can force the processor to use less power (wind down speed).
Slowing the processor means some tasks will take longer to perform.
If those tasks require a high-drain elements (display, radio, WiFi or BT for example) then it's counter-productive (battery wise) to slow them down.
However, because CPU power consumption does not have a liner relationship to clock speed, then some tasks that don't use high-drain elements will consume less power to complete.
So, whilst it's unlikely that your battery life will benefit from the use of SetCPU alone there is a chance that it will.
SetCPU is a fantastic app designed for overclocking, the profiles are niche facilities that may offer battery benefit to a narrow range of users.
Click to expand...
Click to collapse
HUH English Please
Kidding
mikey1022 said:
huh english please :d
kidding
Click to expand...
Click to collapse
34567890
Personaly done many tests and the result was:
Test config: WiFi tethering all the way, screen 100% Playing video all the time 2G only
4:10 @ 245Mhz hard
3:30 @ 998Mhz hard
No use actually - using N1 on 245Mhz is impossible - too sluggish.
SetCpu is ussefull:
1) If u have OC kernel to set OC mode for games like Asphalt
2)For letting android vary frequence ondemand instead of 998 all the time
3)For downclocking while in sleep mode (why use full power when u dont use it?)
4)For using Failsafe profile, to prevent battery and hardware damage.
That's all.
No use trying saving battery setting profiles like 100% - 998, 50% - 576, 20% - 499. This is useless.
On UV kernels the same thing +\-30 minutes battery life. And UV kernels themselfs dont give segnificant battery life increase, only lags and unstability ti system.
Dont believe me try yourself - Create yourself some actions fo testing and repeat them 2 time (Min cpu and Max cpu) on any kernel. Results will be very close.
SeriousX said:
3)For downclocking while in sleep mode (why use full power when u dont use it?)
Click to expand...
Click to collapse
The CPU steps down to it's minimum speed by itself. It never uses more juice than it needs to.
As far as i know, it is always at maximum, but maybe im wrong and you are right - then theres even less sence in this app.
Hi, I spend last few days optimizing voltage table on my Desire and it left me wondering.
I bumped into several situations where 2 or 3 frequencies would be stable on the same voltage level. My question is, theoretically, if 300MHz would use the same voltage as 800MHz, would the power consumption increase proportionally or would it remain fairly similar?
Seeing that 300MHz would need more burn time at the same voltage to complete a task that 800 MHz would do in fraction of that time and then idle, this leaves me puzzled. Is it better to always use highest frequency of the group with same voltage for better efficiency? Or does the slower frequency actually consume less power even though it has to work longer and uses the same voltage?
Please enlighten me or discuss
I would also like to be enlightened on this.
AFAIK your assumption is on the right track, get the job done as quick as possible & get back to idling...
Slightly off topic, but somewhat relevant
byrong did a great write up on the effects of cpu speed vs screen brightness power consumption here that may be be of interest...
Interesting but still doesn't answer one question:
If my 245, 368 and 768MHz would be stable at the same voltage, does it matter if I set 768MHz as my minimum/idle frequency instead of 245MHz? Would is consume more power in the long run say on conservative governor?
And what about the screen-off profile? Consider a scenario when I'm playing an MP3 while screen is off and the player will still take a lot of CPU power to pre-buffer the song, apply equalizer, post-processing etc. Now would that nearly constant burn theoretically consume more power on the 245MHz or 768MHz? It still has to do the same work and 245MHz should just have higher constant load, right?
And how about complete idle. Does it really matter if I idle on 245 or 768 MHz if the voltage and actual work done is identical?
This is I'm sure something everybody is asking but nobody knows the real answer. Unless I'm speaking utter rubbish it's perhaps time to run some tests.
Even if the voltages are the same for different frequencies, I'm sure higher frequencies draw higher amounts of current (as shown in byrong's research, although his voltage tables were not stated). If you change your min cpu freq from 245 to 768 MHz I'd almost guarantee more power consumption, even when idle. I could be wrong though. If you're so curious, why don't you try and post back?
I might be wrong but my $0.02
From what I can remember in class, Power = voltage x current
To do the same amount of work, supplying lesser voltage would mean more current is consumed. That said, if less work is being done at the same voltage, less current would be consumed.
So running the CPU at a slower clock cycle means less work is being done, so less current consumption, compared to running it at full 768MHz.
I think ... ;p
Well I think I will make some empiric testing as soon as I find a way to log current current (yea funny ) to a file.
Even if your $0.02 are right, you're still talking about drawing less current over longer time or more current in a short burst. Of course there are apps like games that will probably take as much horsepower as they can get for redrawing the screen - in that case lower constant frequency is better, because higher frequency would actually have to do more work - drawing more FPS just because it can. For minimum frequency the situation is completely different as the apps only require bursts of workload.
nik3r said:
Well I think I will make some empiric testing as soon as I find a way to log current current (yea funny ) to a file.
Click to expand...
Click to collapse
I thought you read waydownsouth's link?
In the methodology section byrong states he used CurrentWidget to log current over time. You can also use Battery Monitor Widget.
By the way, his methodology is pretty excellent as it minimizes as many variables as possible, and he wrote his own script to keep the cpu working at a controlled rate. I think at a minimum, you should put the phone in airplane mode while conducting the tests.
Spreadsheet of the Battery Drain Data
BATTERY DRAIN BENCHMARKS
VIDEO of how it's done! (Do NOT try it yourself!)
NEW: Lab study done by nathanson666 see here and featured on the XDA's portal and twitter here.
Summary of Results
#1 - With screen on, if the processor is Idle, 100MHz saves the most power.
#2 - Regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%. (Click here for explanation.)
For the instability introduced by UV, it seems a 2% increase in battery life isn't really worth it! REMEMBER rebooting uses so much power, a single one would more than undo any savings made by UV.
#3 - The most power saving governor is Ondemand. If you need a high performance governor, use smartassV2, which offers some battery savings.
#4 - This is one point that everyone ought to know, but I'm including because many people seem to believe in myths: if the screen is off, and the CPU is not active, neither deep idle nor UV will have any impact on battery life.
#5 - The matr1x kernel by mathkid95 mainly saves power through UV of the INT voltages. You may need to raise these if you have freezes/reboots with your phone (in addition to raising the ARM voltages). I found that a maximum of 1 mA can be saved through INT UV, regardless of whether the CPU becomes idle (or with screen off in deep idle), so this is a constant saving. However, it is a very small saving, and doesn't apply if the phone is asleep. Remember, reboots cost more juice than UV can ever save.
#6 - If you have an amoled display, black saves a great deal of power. After that, red. If you have a black and red theme, this is saving you power!
#7 - If you are determined to UV, I found that my phone would become unstable with UV settings that were fine when the battery was fully charged. So check what UV your phone can handle when your battery is nearly empty. Again I say: Because of the high likelyhood and massive battery drain that comes with a reboot, I highly recommend you DO NOT USE EXCESSIVE UV. Also remember, even with extreme UV, you will not increase battery life more than 2%
#8 - I found that with bluetooth or GPS preventing the TOP=OFF state, there was no additional power saving from Deep Idle, i.e. the TOP=ON state does not save power.
#9 - Kernels with the 65 fps hack will cause the screen to drain about 10% more power compared to the usual 56 fps.
#10 - Conservative does not save power! For further details and exceptions, refer to my new thread: here.
#11 - This is just general advice: if you are having very poor battery life, have you tried turning auto brightness off? And if you've got no reception, you might as well be in airplane mode, because searching for reception also eats battery.
#12 - If your phone can't handle OC (or UV for that matter) it's because components in general are built to cost, which means factoring in tolerances, and every chip is made as cheaply as possible within the specified tolerances. Outside of those tolerances, whether your chip can cope or not is unfortunately down to the whether you got lucky with the individual device that dropped off the manufacturing line.
ARM document on A8 fault tolerance: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babhjhag.html
In fact I measured how UV in particular can cause errors, and saw in action the A8 using MORE power to correct the errors. From my spreadsheet:
At 100Mhz
mV 1500 4.92mA
mV 950 2.83mA (default mV)
mV 800 2.58mA (UV saves some power)
mV 750 2.96mA (Extreme UV uses MORE power)
Same test but with Deep Idle enabled:
mV 1500 1.91mA
mV 950 1.49mA
mV 800 1.29mA
mV 750 1.49mA (Same result again but with DI enabled)
Referenced from my spreadsheet starting row 41.
Recommended reading: http://everything2.com/title/wafer+yield
Stock voltages for reference:
ARM
1000MHz @1250mV
800 MHz @1200
400 MHz @1050
200 MHz @950
100 MHz @950
INT
1000MHz @1100
800 MHz @1100
400 MHz @1100
200 MHz @1100
100 MHz @1000
Summary of Power States by tchaari (thanks!)
After research, and some explanation from Steve Garon, it is clear that Deep Idle & CPU Idle are two completely different things:
1) Three main CPU states are implemented in the standard android kernel: NORMAL, IDLE and SLEEP
2) Ezekeel added an intermediate 4th state: Deep IDLE. This saves more power but only when the processor has a background task to run while screen is off. Bedalus proved here that it really saves a considerable amount of power in particular cases (e.g. music playing when screen is off). A minority of users are reporting some slight instabilities with it, but they may in fact be caused by things other than deep idle.
3) The CPU IDLE backport is a replacement of the standard android kernel drivers used to put the CPU in idle/sleep states by the new ARM methods integrated in the linux 3.2 kernel. This backport is theoretically supposed to improve battery life (with just the basic 3 CPU states). It is 100% stable but no power saving has been shown either in bedalus' amp meter measurements, or Harbb's overnight drain tests.
Where did the other benchmarks go?
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
CPU Governors and I/O Schedulers: this thread
Power Saving Governors: this thread
Thanks to all the developers, and a big shout out to: Harbb for his dedicated testing; tchaari for his motivation, great ideas and inspiration; jcolinzheng for the idea to test Deep Idle at fixed frequencies (genius); aLNG for links to interesting and useful articles; Steve Garon for demystifying esoteric kernel technicalities and his excellent kernel itself; everybody else who helped; and of course Ezekeel for making Deep Idle work, and for a stimulating debate!
Harbb joined in doing specific battery tests, using the phone's battery graph. This is based on the phone's own readings (State of Charge or SoC for short). It's not very accurate for an instant reading, but over time, it does become more and more accurate. Therefore, Harbb conducted some very long (10 hour) tests. To improve accuracy further, he waited for the level of charge to drop to around 80% before each test. This eliminates the another source of inaccuracy, that the first 10% of the battery tends to deplete rather quickly (due to normal wear and tear over its lifetime). In fact, I use Ezekeel's Battery Life eXtender (BLX) to stop the phone charging early (at a user defined level: I prefer 90%) to help slow the deterioration of the battery's maximum capacity by preventing heat damage caused as the battery tries to absorb the final dose of charge above 90%.
Harbb's Data
Harbb's spreadsheet
Here's a summary of Harbb's 10 hour test findings, in order of best battery drain:
- 15% - SmartassV2 with DI
- 16% - Conservative with DI
- 21% - Lazy with DI and SOMF
- 23% - Lazy with DI
- 36% - Conservative
- 39% - Lazy
- 39% - Lazy with CPU IDLE
- 44% - Lazy with Eugene's DIDLE
- 48% - Lazy with Eugene's DIDLE and SOMF
[where DI means Ezekeel's Deep Idle, and SOMF indicates that Screen Off Max Freq was enabled]
Power Misconceptions
1st Misconception:
There is a misconception about about 200MHz using the same power as 100MHz because the voltage is the same. There is an approximate formula for CPU power consumption:
CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared)
Capacitance is a constant, so we can ignore it. Let's fill in the values for the lowest and highest frequencies:
100 MHz V=0.95 so V^2=0.9025
1000 MHz V=1.25 so V^2=1.5625
So this shows we have roughly an extra 70% power drain due to the voltage increase. However, the maximum frequency is 10 times the minimum, i.e. a 900% increase. So the dominant factor in CPU power drain is in fact the frequency. Roughly speaking, the frequency has 13 times more influence over the power drain than the voltage.
Therefore, the governor that keeps the frequency as low as possible for as long as possible will save the most power. This appears to be consistent with Harbb's finding that conservative saves the most power.
2nd Misconception:
Some people say that if they UV they can play a game on their phone for an extra hour. The most you can get from UV is 2% extra battery life (and it is not worth the reboot risk).
See post #4 for calculations based on the actual measurements taken from the phone.
Here is a more academic proof using the same formula from the 1st misconception:
CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared)
Capacitance is a constant, so we can ignore it. Let's fill in the values for just the highest frequency with the stock voltages and then an extreme undervolt:
1000 MHz V=1.25 so V^2=1.5625 (stock volts)
1000 MHz V=1.2 so V^2=1.44 (the most UV my phone can handle with a fully charged battery)
This is an 8% saving. Happily, this exactly matches what I measured in the real test (see cell F62 in the spreadsheet).
Remember, only the CPU is saving 8%, the screen being on uses about 4 times as much power as the CPU even at its highest frequency. This reduces the power saving to at most 2%.
I am of course assuming the screen is on. For most users, this is correct, as their processor will not be under a heavy load unless the device is in use, and this almost always means the screen is on. If anyone can think of any circumstances where the CPU is under a heavy load, but the screen is off, and show that this happens to all users a high enough proportion of the time to be relevant to this calculation, please let me know. [/far fetched caveat]
Testing Methodology
Two videos are available, and note, a circuit diagram of test now linked within the battery benchmark spreadsheet. I've decided to share it publicly as I've now set up and run this test three separate times, with no major problems. So I've reclassified it from utterly reckless, to merely dangerously stupid. Do not under any circumstances try this with your own phone! You have been warned!
You cannot trust battery monitor widget. (More on that in the 4th post)
Here's a way to test Deep Idle without rewiring your phone:
Note - SOMF means Screen Off Max Frequency
Setup must be identical (apart from SOMF). Install battery monitor widget, set history update rate to 10 minutes (not particularly to monitor the battery, but just to act as a timer). Set to run without widget. Turn off all radios, turn off sync, turn off location services, put in airplane mode. Turn off any of Ezekeel's mods excepting (Deep Idle of course). Set up your music app to play the same song on a loop. Make sure all volumes are down. Phone must be in mute. Turn of auto-brightness just in case. Morfic told me that to avoid the problem of the battery not reporting itself properly you can begin both tests with the same charging procedure: charge while off overnight. In the morning bump charge for exactly one hour. Disconnect, boot, start music immediately. Power button to screen off. Leave phone for 48 hours (should be enough time to auto power off).
After the first test, check the history from battery monitor widget to see how long the phone was on for.
Repeat again but with SOMF set to on.
***
Here's more on metering the amps:
REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.
If you're thinking this is something you'd like to try, you'll need:
1) An analogue multimeter or pure ammeter because a digital one will be difficult to read with constantly changing amps.
2) Two battery caddies with space for 3 AA batteries each.
3) Six rechargeable batteries. Use rechargable ones because the volts are a bit less, 3*1.35=4.05 - close enough to the spec 3.7
4) Lots of cables with crocodile clip ends
5) Some fine copper wire
If you're thinking of soldering something onto your battery, DON'T - you may accidentally make a short circuit that will be difficult to undo, and cause the battery to explode. Plus the heat of the soldering iron certainly won't do it any good. And don't solder anything onto your phone contacts, just carefully twist a few strands of copper wire around them, so they can be easily removed. REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.
[Q] Why do I need 6 AA batteries when 3 would provide enough volts?
[A] My multimeter inserts a 600 ohm resistor into the circuit (yours may be less, and if so you will need different calculations to convert to amps). This resistor allows the multimeter to evaluate the amps by measuring the voltage drop across it. But the resistance will cause your phone to starve of power. Running a parallel battery to the phone will prevent it crashing when the voltage supply isn't sufficient for things like screen on+cpu max frequency+sdcard IO... This parallel supply should run directly to the phone, not through the multimeter. It can be disconnected when the screen is off, and will not harm the phone. Remember to reattach it before powering on your screen, or it is likely your phone will crash. I would advise to start with fully recharged batteries, and not connect the USB charger.
[Q] Won't the amps read half of what is actually being drawn?
[A] Yes, but you'll get the correct reading if you unhook the parallel battery.
[Q] Might I also be able to do that when the screen is on?
[A] Yes, but I recommend that you do that with everything possible powered off, wifi, 3G... etc... screen brightness minimum. Set your screen timeout to never, so that you have control over it with the power button. Always reconnect your parallel battery before changing from screen on to screen off, and visa versa. (Due to large power spike)
[Q] I want to try this. Should I?
[A] No, no-one should try this.
Miscellaneous
[Q] You claim you cannot increase battery life using UV beyond 2%. Justify yourself!
[A] When the processor is in use (i.e. not asleep or idle) UV does save a tiny amount of power. I tested with the most extreme UV my phone could handle. With a high performance governor, e.g. smartassv2, extreme UV would reduce CPU drain by 13%, or about 7 mA. With a governor that keeps the CPU frequency low, CPU drain would be reduced by about 18%, or 4.6 mA (weighted - see the spreadsheet starting cell H88).
Remember, these savings are limited to the processor, and only when it is active. For most users, this will mean the screen is on. For comparison, the screen on minimum brightness displaying black uses 9mA. On max brightness, displaying white, it uses 690mA. Let us assume some median value, ~350 mA.
A saving of 4.6 mA out of at least 350 mA (screen) plus 20 mA (CPU)
= 1.2%
A saving of 7 mA out of at least 350 mA (screen) plus 50 mA (CPU)
= 1.8%
So, regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%.
Articles and Documents
Diane Hackborn's article on the formula that produces the dodgy Android OS usage statistic in the battery menu:
https://plus.google.com/105051985738280261832/posts/FV3LVtdVxPT
(note, this bug is fixed as of Android 4.0.4)
Data sheet for the fuel gauge chip:
http://www.maxim-ic.com/datasheet/index.mvp/id/6621
Link to great article on SOC (State of Charge) http://www.mpoweruk.com/soc.htm >>> explains all the reasons why I don't trust battery monitor widget and the phone's own battery stats.
Great article on the difficulties of accurate metering (thanks aLNG):
http://low-powerwireless.com/blog/d...t-schemes-for-battery-powered-devices-part-1/
In the article DUT stands for Device Under Test
The implication is that DMM [Digital Multi Meter] voltage drop readings (to measure amps) take hundreds of milliseconds, a will miss instantaneous battery savings above this time window. However, I am using an analogue meter, the the needle responds to all current. Due to the mass of the needle, there is inertia to overcome, which provides a form of averaging.
Quote from the article:
"a GSM cell phone can have current pulses of 2 amperes that last approximately 500μs while the power amplifier is on and transmitting, and then drop back down to the milliampere level for the remainder of the 4.5 ms GSM cycle."
500μs is 0.5ms, so is 1 tenth of the 5ms GSM cycle. 2 amps at 1/10th of 5ms = average of 200 mA
When I ran the test with my equipment, GSM broadcasting uses at least 170 mA - see row 36. I think this is a nice proof that the analogue multimeter beats the digital multimeter hands down for dynamic amps (i.e. changes happening below the millisecond level.) I'm also very satisfied that my result is close to the result stipulated by the article. It improves faith that my readings are accurate.
[Q] What could add inaccuracy to the readings?
[A] The dBm scale assumes a resistance of 600 ohms, but the resistor has 3% accuracy which means it could be as high as 618 ohms, or as low as 584 ohms.
[A] Also, the scale is very small, so I've read the needle to the nearest fifth of a dB
Other articles (thanks aLNG)
A study of the mA drain of various components of a smartphone
http://www.usenix.org/event/atc10/te...rs/Carroll.pdf
An ARM presentation on unifying power management procedures in the kernel
http://elinux.org/images/0/09/Elce11_pieralisi.pdf
UPDATE: Undervolting the CPU tested (using nstools ARM+INT)
UPDATE: impact of different screen colours tested (amoled)
UPDATE: Running apps tested.
Please note, the running apps draw power for lots of different reasons, access RAM, CPU, I/O, Graphics, all use power, what's being displayed also uses power, eg a brighter 3D scene vs a darker 3D scene. But it does give an overall idea of what Amps might be pulled when you are using the phone normally.
Thanks for your hard works I'm impressed with the systematic research.
Many things just the theoretical possibility? just something we created in our minds...
mobile_pc said:
Thanks for your hard works I'm impressed with the systematic research.
Many things just the theoretical possibility? just something we created in our minds...
Click to expand...
Click to collapse
Indeed, i agree. Now, with no benefit to under volting, perhaps we can all suffer less reboots.
For kernel benchmarks and more, see here: http://goo.gl/mpeHI
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.
Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?
The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.
Cheers
polobunny said:
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.
Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?
The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.
Cheers
Click to expand...
Click to collapse
The frequency information is there in the first column, eg 400/400 means the min and max settings were both 400. If you're not changing frequencies you can get it down very low.
Yes, perhaps nstools is defective. However, i did get an instant reboot with the lowest setting. Want me to do a repeat in GB?
For kernel benchmarks and more, see here: http://goo.gl/mpeHI
So undervolting does nothing? That seems strange ...
Also what about using juice defender? Worth it ?
italia0101 said:
So undervolting does nothing? That seems strange ...
Also what about using juice defender? Worth it ?
Click to expand...
Click to collapse
Yeah, does nothing to save battery. I don't know what juice defender is?
Sent from my SNES
polobunny said:
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.
Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?
The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.
Cheers
Click to expand...
Click to collapse
Okay, I went ahead and tested Gingerbread (carbon, ICS themed Oxygen 2.3.1, android 2.3.7) using franco's last kernel for GB. Starts at row 329.
Neither extreme undervolting nor overvolting had any impact on the battery drain.
Juice defender is a battery saving app that basically d/cs the data and wifi when screen is off and reconnects when screen is on... also when screen is off it uses schedules to turn wifi/data on to receive stuff and sync
italia0101 said:
Juice defender is a battery saving app that basically d/cs the data and wifi when screen is off and reconnects when screen is on... also when screen is off it uses schedules to turn wifi/data on to receive stuff and sync
Click to expand...
Click to collapse
Sounds sensible enough to me!
Sent from my SNES
Some reserves
bedalus said:
2 - If you use NStools to undervolt, don't bother. No gain to be had from undervolting either ARM or INT voltages. I tested this to the extreme. Check the spreadsheet, near the bottom. (Tested in both ICS and GB).
Click to expand...
Click to collapse
First, I want to thank you for all your efforts in the benchmarks especially for the battery drain. However, I kindly have some reserves on this. Maybe undervolting does not save so much power at idle but at higher loads, energy can be surely saved. Besides, maybe the energy saved is too minimal for your analog multimeter and it can't be noticed on it.
This is the theory :
The switching power dissipated by a chip using static CMOS gates is C·V2·f, where C is the capacitance being switched per clock cycle, V is voltage, and f is the switching frequency,[1] so this part of the power consumption decreases quadratically with voltage.
Click to expand...
Click to collapse
source : http://en.wikipedia.org/wiki/Dynamic_voltage_scaling
And this a more practical reference about a study made by tom's hardware on AMD Athlon clock, voltage and power consumption. I think it can be generalized (at a smaller scale) for our ARM processor in the nexus S:
It’s only when we change the voltage that we're able to significantly save more power--about 13 watts lower consumption, or a total of 20 watts compared to running without power management. That's a savings of 25%.
Click to expand...
Click to collapse
source (you may also read the entire article. It is very significant):
http://www.tomshardware.com/reviews/processor-power-management,2453-9.html
Other scientific papers and studies can be also found stating that undervolting saves power.
Kind regards.
I also appreciate all the hard work you have done for testing, on both kernels and everything, but im going to "gingerly" throw my hat in with tchaari here...
The only way to actually test battery drain would be to attach a multimeter and let it drain all the way on every test, using every kernel, and every setting - multiple times to omit false positives. Obviously this is beyond the acceptable timeframe it would actually take to accomplish. anyone would go insane sitting there waiting.
there are nuances here that will affect results regardless how carefull one is. the program itself might suck juice, your kernel/gov choice affects how the program runs too...also the status of your battery makes a difference. is it past it's half cycle life? etc..then the multimeter is another massive factor. there are many many different types not saying yours is bad, but over the years as an electrician ive played with some that are $20 as well as $2000 - and they are a far cry from each other even though they both do the exact same functions!
The undervoltage is a prime example. there are so many factors that will affect the results it's unusual to see your sheet having barely any differences - when we know that undervolting does actually save you battery under loads.
so it's nice to see a massive sheet like you did, as it does give a good start point reference - but it should be used not as chipped into stone law either.
Thanks for taking the time to give a great, no excellent base line to work off of though and preform more intense testing if people would like to go that far.
t3xboar said:
there are nuances here that will affect results regardless how carefull one is. the program itself might suck juice... then the multimeter is another massive factor. there are many many different types not saying yours is bad, but over the years as an electrician ive played with some that are $20 as well as $2000 - and they are a far cry from each other even though they both do the exact same functions!
Click to expand...
Click to collapse
What program? I'm playing a loop of silence in the music app to keep the processor awake.
The multimeter I'm using isn't fancy, but even if it's reading 10% down, it's doing it for all readings, so it's a fair comparison.
t3xboar said:
The undervoltage is a prime example. there are so many factors that will affect the results it's unusual to see your sheet having barely any differences - when we know that undervolting does actually save you battery under loads.
Click to expand...
Click to collapse
What makes you say we know this? I want to get to the bottom of this, so i need to see a concrete source.
Tchaari posted the capacitance times volts squared times frequency formula. I know this, and when I adjust the ARM voltage by more than half a volt, i expect to see this:
0.8x0.8=0.64
1.5x1.5=2.25
That should be 3.5 times as much power use.
Now, double the power in the dB scale is a difference of ~3dB. 3.5 times ~5dB. And I can notice a change of 1/5th of a dB on my multimeter's scale. There was no change. Here is how i tested.
Start music. Go into nstools, set ondemand with min and max at the same frequency. Go to volt, select the lowest possible voltage for that freq and exit. Screen off, measure amps. Screen on, nstools, volts, highest volts this time, exit, screen off, measure amps. Result: identical.
Seriously, if you have a background in electronics, have a go yourself (NO ONE SHOULD TRY THIS THEMSELVES) and get back to me.
In theory, it should save power, but it isn't. I'd love to be able to say why. At this point i don't think it's a problem with nstools, because i got a crash the second i put the volts to minimum when i was testing on Steve's kernel in ICS.
Sent from my SNES
As contradictory as some of these results may (or may not) be, bedalus is in the right with his methodology as far as i can see. Though at this point nothing should be set in stone. Not yet at least.
A few people saying with UV that they get more screen on hours, up from 3 to 6 hours. I'll check amps pulled (with both UV and OV) with screen on next.
Sent from my SNES
bedalus said:
A few people saying with UV that they get more screen on hours, up from 3 to 6 hours. I'll check amps pulled (with both UV and OV) with screen on next.
Click to expand...
Click to collapse
That is a good idea bedalus but it seems that undervolting gain is very minimal instantly. In a long period, it can make some difference in battery life...
I have also many doubts about how sensitive your amps-meter is? Since we are dealing with small values in our case, maybe a more sensitive device can measure some difference that yours can't...
Anyway, your work is very interesting and as Harbb said : At this point, nothing should be set in stone yet.
KNIGHT97 said:
And fir the advanced users (with text reading that, in red color) some ABB settings would be good too
Click to expand...
Click to collapse
Am sure Devs, others and I too have said this across various places, so I will skip the intro to ABB and go straight to tuning it for our benefit. The only things you need to know before getting the hands dirty are ( @KNIGHT97 I know you are no newbie, but this post will cover some basics too )
Do your homework - ABB is not for the faint hearted. If you are not ready to put in some time to test multiple combination of settings, have the phone freeze on you several times until you perfect it, this is not for you. Stay with the UVing that we are used to, or stick with the -25/ -50 - 75 mV undervolting.
ABB will vary with device. You need to know the ASV of your device (/sys/devices/system/abb/abb_info - the last line in this file tells what your phone's ASV value is), and then go about changing the values keeping your ASV's values as baseline.
Anyone jumping in late, make sure you read the changelog dated 22nd April 2013 in this post. All credits for whatever I know about this goes to @AndreiLux and all that I say here are from the post I have linked and what I did from there. Another good read will be this thread, where @cba1986 has collated a lot of inputs from AndreiLux and a few others.
Before you play with ABB, have your stock gate voltages and stock body voltages handy (these are also in the third sheet of the spreadsheet I have attached).
So here is how I went about this whole task - the prerequisite is you pick a stable (preferably stock ROM, and kernel that supports ABB (of course) and is deemed stable for everyday use). This is important because you do not want a freeze occurring due to a kernel or ROM anomaly to impede on your undervolting decisions
Undervolt the gate of the device (the usual voltage we all undervolt) step by step. When I say step by step, what I mean is
Undervolting it based on a rough logic (say, -50 mV) and letting it run for a day
Then undervolt ONE FREQUENCY STEP a bit more (say by 25 mV). Let in run one more day.
If your phone didn't act weird (SoD, random freeze ups, etc.) then undervolt THE SAME STEP SOME MORE (by another 25 mV), let it run one day more
Rinse and repeat until your phone freezes up during the course of the day. And when it does, reduce the undervolting by, say, 12.5 mV and see if all goes well for that frequency (else reduce the undervolting some more)
When doing all this, make sure you are putting your phone to full use - watching videos, playing audio through bluetooth, Wi-Fi, et all. Repeating this for every frequency step will give you the maximum undervolting your phone can tolerate, Congratulations
The Body voltage - the one that ABB-enabled kernels let us play with
By default, you will have 4 sets of body voltages - one for the 200 MHz step, one for 300 to 800 MHz steps, one for 900 to 1600 MHz steps, and the last one for anything higher. Using BetterBatteryStats (or any other tool that works for this cause), find the amount of time your phone spends in each frequency step while it is awake and while on battery. Note that the voltages or their combinations I mention here on may be for a ASV 1 device, YMMV.
The frequency that almost everyone's device uses the most must be 200 MHz (we are not going to factor the Deep Sleep time here). The stock gate voltage for this step is 912.5 mV, and for an ASV 1 device, the stock body voltage is 750 mV. That is, the gate voltage is higher than the body voltage - what this means is that while the CPU will be able to clock easily, it will also have a higher static leakage (Forward Body Bias). So, for lower frequencies, we have to try and bridge the gap between these two voltages such that the gate voltage is lower than the body voltage, thereby saving on static leakage. Let's assume that you were able to get the phone undervolted to 837.5 mV (-75mV undervolting) and find it stable. You will have to overvolt the body to 850 mV so that you will have a -12.5 mV difference between the gate and the body, give you what is called a Reverse Body Bias - in this state, the CPU will find it difficult to ramp the clock, but it will not leak static current. With the same assumption of 837.5 mV at gate, and with 850 mV at body, you will have to go through the 24 hour observation cycle for freeze ups or SoDs - if they occur, it means your phone is finding it way too difficult to ramp the clock up at these voltages - in which case, you will raise the gate from 837.5 mV to 850 mV (while the body remains at 850 mV). When you do this, you are actually undervolting the gate by -67.5 mV and overvolting the body by 100 mV - while this may sound bad to achieve a 37.5 overvolting after going through too much trouble, you are actually overvolting a bit to arrest static leakage which is a higher cause of drain at lower frequencies.
For steps 300 to 800 MHz, you will follow a similar logic, and find a body voltage that, while might be a bit higher than the stock, will give you a negative or zero difference between the gate and the body as much as possible. The same procedure of validating the value you choose by letting the phone run a day's course is imperative. A Word of Caution: The 800 MHz step is a bi*ch. If you encounter a hang or a freeze, increase the gate voltage, or reduce the body voltage such that the 800 MHz step is at a low or zero RBB and keep it in observation. If this step is not the cause of the freeze up or SoD, then go through the usual cycle of manipulating the voltage of each step. Rule of the thumb from here on is to change the body voltage such that most or all of the frequencies between these steps will be in RBB (have a 0 mV difference between gate and body, or a lower positive value- like +12.5 mV). Depending on your phone's ASV, you may very well end up effectively overvolting your device here too by applying a higher than stock voltage at the body, but the same purpose as the 200 MHz step applies here - only a little less pertinent because the time your phone spends in these steps will be about 40% lower than the time it spends in the 200 MHz step.
For steps from 900 to 1600 MHz (and above), where a phone spends roughly 30% of it's time on, the more important factor is to ensure the CPU is able to scale. And, to increase the body voltage to match the gate voltage to create a reverse bias or a lower forward bias will be an overkill of an overvolt on the body. So my suggestion, at least for ASV 1 CPU is to leave the body voltage of these frequencies to stock, and be happy with whatever undervolting you achieve at the gate.
Miscellaneous points:
Forward Bias will enable higher undervolting at the gate, but will have a higher static leakage. Reverse bias will arrest static leakage to a greater extent, but it will be difficult to undervolt as much as you could in a Forward Bias setup. This is why you may have to increase the gate's voltages a bit more than without ABB, to achieve a stable system (that will have a much lower static leakage)
The most positive indication of a good ABB/ Voltage configuration is that your device will run relatively cooler because of the obvious reduction in static leakage
In most kernels, you can change the body voltage by 50 mV steps (700, 750, 800, 850, etc.) - anything else will be rounded up
You can change the thresholds for the Body voltage steps (example - change the 300 to 800 MHz step to, say, 300 MHz to 900 MHz, which will also change the next step to 1000 to 1600 MHz). But it my various, time consuming experiments, there is no perceptible gain. This is of course not true for all phones, so some of you may still benefit on a case to case basis
The process for modifying the gate and body voltages for the GPU are similar to the above. And not all kernels allow modifying the gate voltages for MIF and INT, in which case, I recommend that you do not touch the body voltages either
The BetterBatteryStats input on how much time is spent on each frequency step is useful to adjust the gate and voltage combinations such that you will create a reverse bias as much as possible in the lower frequency steps that your phone will dwell on for a longer time. The attached spreadsheet will tell you that I have configured it in such a way that I have reverse bias in the steps that my phone spends 70% of it's time on, and am achieving an average of 7% overall undervolting - yes, all this for just 7% To put that into perspective, a -50 mV undervolt across steps will give you an overall undervolt of about 3%. To find that out, find the time spent in each step, the overall undervolt/ overvolt of each step (with or without ABB), and do a SUMPRODUCT in Excel against the total time spent in all the frequencies combined. Also, while % numbers are good to say and nice to hear, what matters is how much of a difference they actually make - for me, I have a super low battery drain in screen-off and during sleep - provided that some weird app or setting does not kill my battery
Before putting a script with all your UV and ABB values in that init.d folder and giving it executable rights, make sure you put it in a harmless location (like /data/tmp), give it executable permissions and execute it from there, so that if your phone goes thermonuclear, all you would need is a hard reboot and not look at how to remove that darned script from init.d to even get to the home screen
I don't know if I caused more confusion than clearing them Ask your questions, I (and others too, who have dirtied their hands in this amazing power-tool) will try to answer them as much as possible.
An important note on the attachment - DO NOT APPLY THE VOLTAGES THERE BLINDLY EVEN IF YOU HAVE AN ASV 1 DEVICE. NOT ALL DEVICES, EVEN WITH THE SAME ASV BINNING ARE MADE EQUAL. Do your experiments, at least attempt some and apply your findings.
Yes, thanks for clearing this out. This is going to help many advanced users understand the gate and body voltage related settings and body bias related stuff.
While I read and read all the time, some of the points, I admist to have missed and you explained them thoroughly, so a big thanks to you for that.
And yes, like you said, starting from the basics, this is always good since it'll help some users get acquainted to this advanced tuning.
I ha e experimented and bencmarked carefully to get my best UV/ABB combo and I can easily manage 2 days with 6-7 hours SOT without any static leakage, plus I have quite a high UV (-90) so my device hovers around 28-33 degress in normal usage and 36-37 during heavy HD games. Stability checks, benchmarking, I/O scheduling and VM/Kernel tweaks have provided a super smooth experience.
I'll include a link to this in my signature, in case someone wants to learn about ABB basics and begin with advanced stuff
Have a good day
Regards,
KNIGHT97
KNIGHT97 said:
Yes, thanks for clearing this out. This is going to help many advanced users understand the gate and body voltage related settings and body bias related stuff.
While I read and read all the time, some of the points, I admist to have missed and you explained them thoroughly, so a big thanks to you for that.
And yes, like you said, starting from the basics, this is always good since it'll help some users get acquainted to this advanced tuning.
I ha e experimented and bencmarked carefully to get my best UV/ABB combo and I can easily manage 2 days with 6-7 hours SOT without any static leakage, plus I have quite a high UV (-90) so my device hovers around 28-33 degress in normal usage and 36-37 during heavy HD games. Stability checks, benchmarking, I/O scheduling and VM/Kernel tweaks have provided a super smooth experience.
I'll include a link to this in my signature, in case someone wants to learn about ABB basics and begin with advanced stuff
Have a good day
Regards,
KNIGHT97
Click to expand...
Click to collapse
Ah! I missed mentioning the lower device temperature point - will add that
To the extent that flickering and low charging is related to Sony thermanager, here is the permanent fix for AOSP/CM based roms. While the idea of thermal manager is good and we should credit Sony for doing it, the implementation kind of s*cks. For example, the manager kicks in when CPU/GPU temperature rises to 44 degrees. Also, several triggers are set between 54-56 degrees. This is plain wrong, because 44, 50 and 55-56 are all perfect numbers for an active device and at these temperatures, thermal manager should not be active. I have adjusted trigger numbers so that there will be no mitigation until at least 60 and surprise surprise, all screen flickering is gone away....
Attached is thermanager.xml which should be put in /system/etc/ with 644 permissions. Reboot is required. UNZIP FIRST. Also, backup your current file just in case.
A word of caution on undervolting: keep in mind that when you undervolt on high frequencies, you make your CPU work harder, as it requires more cycles to do the same task. As a result, you have overheating. So, undervolting is counter-intuitive..
Does it also will solve the touch freeze problem on cm12.1?
Gesendet von meinem Xperia Z1
sgspluss said:
Does it also will solve the touch freeze problem on cm12.1?
Gesendet von meinem Xperia Z1
Click to expand...
Click to collapse
Any touch issues related to thermanager kicking in early could be resolved. But lollipop has overheating issues related to art, which can't be solved by thermal management. That's why strictly speaking, lollipop has to be recalled. In my view it can't be fixed.
A little question
Hello optimumpro
I only need put the thermanager in the path system/etc to make it work? or need something else?. Sorry by the queastion I noob an recently I repair de display and touchscreen for my xperia z1 C6902 and a have the flickering problem.
Thanks for your help.
optimumpro said:
A word of caution on undervolting: keep in mind that when you undervolt on high frequencies, you make your CPU work harder, as it requires more cycles to do the same task. As a result, you have overheating. So, undervolting is counter-intuitive..
Click to expand...
Click to collapse
I think you have a misconception about undervolting , undervolting does not make your CPU work harder , instead it makes your CPU unstable .
so no, undervolting does not makes your cpu overheat , only overvolting does.
This works for me!
before flash this file, my Phone only receives 90ma from any changer, and now reciving 1080ma. Thanks a lot!
Room: Ressurection Remix
Android version: 5.1.1, Xperia Z1 C6943
Sent from my Xperia Z1 using XDA Free mobile app
Hi
My phone in stock rom recieves 800ma
Does it normal??
I think it charges late,from 0 to 100 it takes about 3 hours 45 mins
Do i need flash this file??
Does my charger or battery have any problem?!
Thank you so much
Here is my screen shot
Sent from my C6903 using Tapatalk
agha_jo0n said:
Hi
My phone in stock rom recieves 800ma
Does it normal??
I think it charges late,from 0 to 100 it takes about 3 hours 45 mins
Do i need flash this file??
Does my charger or battery have any problem?!
Thank you so much
Here is my screen shot
View attachment 3434889
Sent from my C6903 using Tapatalk
Click to expand...
Click to collapse
I don't think that app is accurate tbh with the fix it says no higher than 300ma for me and my phone is charging pretty well I'm using 2100ma charger as well
Sent from my Xperia Z1 using Tapatalk
Sorry bro but i don't have this file in system /etc??? Wtf???
ninjasoft said:
Sorry bro but i don't have this file in system /etc??? Wtf???
Click to expand...
Click to collapse
You are probably on kitkat. If that's the case, you don't need thermanager. If you are on lollipop, look again, the files are not necessarily in alphabetical order...
And remember, this one is for custom roms: CM and/or AOSP based. I just looked at your signature, you have stock...
zhuoyang said:
I think you have a misconception about undervolting , undervolting does not make your CPU work harder , instead it makes your CPU unstable .
so no, undervolting does not makes your cpu overheat , only overvolting does.
Click to expand...
Click to collapse
You are wrong. When cpu is unstable, it can't do the job. When it can't do the job it jumps to higher frequencies and then plugs in additional cores, which causes overheating.
optimumpro said:
You are wrong. When cpu is unstable, it can't do the job. When it can't do the job it jumps to higher frequencies and then plugs in additional cores, which causes overheating.
Click to expand...
Click to collapse
Explain why that a phone reboots automatically when you underclock too much, if your concept is correct then it should just run at higher frequencies instead of just reboot.
And also what's the purpose of overvolting?
What's the purpose of per frequency voltage table?
zhuoyang said:
Explain why that a phone reboots automatically when you underclock too much, if your concept is correct then it should just run at higher frequencies instead of just reboot.
And also what's the purpose of overvolting?
What's the purpose of per frequency voltage table?
Click to expand...
Click to collapse
Easy: when you under volt over a certain level, the cpu just shuts down, because it does not have enough energy to jump to higher frequencies. So, in that case, instead of jumping and overheating, it just dies. However, when you under volt to a lesser degree and cpu has just enough (not to die), then you will have jumping and overheating.
There is no purpose in overvolting, other than returning to your prior levels or correcting wrong default values if you don't want to fix those in kernel source.
What's the purpose of per frequency voltage table? If you adjust, you want to do it on global level, because cpu has different frequencies. There is no other way...
However, if you put your phone on performance governor, you won't need per frequency voltage. By the way, in my experience, performance governor causes less noise and overheating, because it does not spend time and energy on jumping, and it could go to idle immediately.
optimumpro said:
Easy: when you under volt over a certain level, the cpu just shuts down, because it does not have enough energy to jump to higher frequencies. So, in that case, instead of jumping and overheating, it just dies. However, when you under volt to a lesser degree and cpu has just enough (not to die), then you will have jumping and overheating.
There is no purpose in overvolting, other than returning to your prior levels or correcting wrong default values if you don't want to fix those in kernel source.
What's the purpose of per frequency voltage table? If you adjust, you want to do it on global level, because cpu has different frequencies. There is no other way...
However, if you put your phone on performance governor, you won't need per frequency voltage. By the way, in my experience, performance governor causes less noise and overheating, because it does not spend time and energy on jumping, and it could go to idle immediately.
Click to expand...
Click to collapse
__________________________________________________________________________________________________________________________________________________________________________
http://bigfatreality.blogspot.com/2012/04/complete-android-undervolting-guide.html
Advantages of undervolting Android
Thank God for Android where we can easily modify and customize our lovely Android devices to the way we want. Being said this, undervolting is one of the biggest attraction for Android! Simply by undervolting an Android you will or might experience:
A longer battery life
More responsive smartphone
Less heat produced by the phone
Super-charge your Android to go further than what it can do (overclocking Android)
Click to expand...
Click to collapse
http://techglen.com/2014/01/16/what-is-undervolting-how-to-undervolt-your-android-phone/
Note: UnderVolting is widely used as a cooling solution and in my opinion more effective than any other cooling solution available for free. Results can will show decrease in the temperature of smartphone. I recommend undervolting to anyone with enough confidence and knowledge to do so. The benefits easily outweigh the risks. I dont see why one shouldn’t do this for a cool and better smartphone experience.Undervolting will NOT compromise performance at all.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1956346
Undervolting is actually a very good thing for your smart phone when you do it correctly. Undervolting has one major positive effect on your CPU: it will extend the life of your processor by allowing it to do demanding things with lower heat generation
Click to expand...
Click to collapse
zhuoyang said:
__________________________________________________________________________________________________________________________________________________________________________
http://bigfatreality.blogspot.com/2012/04/complete-android-undervolting-guide.html
http://techglen.com/2014/01/16/what-is-undervolting-how-to-undervolt-your-android-phone/
http://forum.xda-developers.com/showthread.php?t=1956346
Click to expand...
Click to collapse
Maybe or maybe not. Blogs, especially by those who don't know what they are talking about (isn't it the purpose of blogs anyway? ) is not proof of anything.
However, you asked me to explain myself and I did. Why don't you put cpu info on the screen and experiment (so you can see live frequencies and temperature). You'll be surprised...
The point stands: when your cpu does not have enough juice, it spends more efforts to accomplish the task. If it manages not to shutdown, then it spends more cycles to do the job, thus causing overheating and excessive battery drain. And it does not matter how you call that state: unstable or whatever...
The reason I said it was counterintuitive is that people think if you provide less energy to cpu, there will be less noise and heat. The most energy is spent when cpu jumps back and force or plugs in/out cores and that's exactly what cpu does when you reduce voltage. If it is locked at the highest frequency, you eliminate jumping and extra plugging. When your phone is active, it accomplishes tasks faster. When it is done, it rushes to idle immediately and in idle state it virtually does not make any difference which frequency you are on, especially it does not matter when your phone is in deep sleep. Also, at higher frequencies cpu is often able to do the task using one core, again resulting in battery savings.
optimumpro said:
Maybe or maybe not. Blogs, especially by those who don't know what they are talking about (isn't it the purpose of blogs anyway? ) is not proof of anything.
However, you asked me to explain myself and I did. Why don't you put cpu info on the screen and experiment (so you can see live frequencies and temperature). You'll be surprised...
The point stands: when your cpu does not have enough juice, it spends more efforts to accomplish the task. If it manages not to shutdown, then it spends more cycles to do the job, thus causing overheating and excessive battery drain. And it does not matter how you call that state: unstable or whatever...
The reason I said it was counterintuitive is that people think if you provide less energy to cpu, there will be less noise and heat. The most energy is spent when cpu jumps back and force or plugs in/out cores and that's exactly what cpu does when you reduce voltage. If it is locked at the highest frequency, you eliminate jumping and extra plugging. When your phone is active, it accomplishes tasks faster. When it is done, it rushes to idle immediately and in idle state it virtually does not make any difference which frequency you are on, especially it does not matter when your phone is in deep sleep. Also, at higher frequencies cpu is often able to do the task using one core, again resulting in battery savings.
Click to expand...
Click to collapse
You're the one who don't know what you yourself is talking about.
Someone need to prove your concept right, I can't find anything about saying under clocking makes your cpu overheat.
Try find someone who agree with your concept or at least prove yourself right.
If you're able to prove yourself right I'll do you a favor and submit it to the news portal.
zhuoyang said:
You're the one who don't know what you yourself is talking about.
Someone need to prove your concept right, I can't find anything about saying under clocking makes your cpu overheat.
Try find someone who agree with your concept or at least prove yourself right.
If you're able to prove yourself right I'll do you a favor and submit it to the news portal.
Click to expand...
Click to collapse
"You're the one who don't know what you yourself is talking about"
No need to get personal. And I certainly don't need any "favors" from you.
If you need proof, just do a search anywhere including XDA where it would tell you that there is growing evidence that performance governor where your cpu is set at the highest frequency reduces "race to idle" and therefore causes less noise (jumping) and therefore better on performance and battery.
http://forum.xda-developers.com/nexus-4/development/guide-android-governors-explained-t2017715 That's just one example.
You won't find much more for several reasons: linux does not care about smart phones and only they know enough about kernels, but in the context of PCs they are not concerned about governors. They only have performance and ondemand (for laptops). Google does not deal with kernels (except for nexus) and they have no qualified engineers. Manufacturers do, but they have no incentives to invest more millions in research and development so that you can keep your device longer.
But as I have already said, do it yourself. Set cpu data on screen and experiment with performance vs other governors while watching the temperature. My experience has been that there is obviously no jumping and very little core plugging/unplugging, because 2.2-2.4 core can do a lot alone without extra efforts...
If you can't behave and maintain an intelligent conversation without resorting to personal attacks, then there is no point for me to talk to you. .
optimumpro said:
"You're the one who don't know what you yourself is talking about"
No need to get personal. And I certainly don't need any "favors" from you.
If you need proof, just do a search anywhere including XDA where it would tell you that there is growing evidence that performance governor where your cpu is set at the highest frequency reduces "race to idle" and therefore causes less noise (jumping) and therefore better on performance and battery.
http://forum.xda-developers.com/nexus-4/development/guide-android-governors-explained-t2017715 That's just one example.
You won't find much more for several reasons: linux does not care about smart phones and only they know enough about kernels, but in the context of PCs they are not concerned about governors. They only have performance and ondemand (for laptops). Google does not deal with kernels (except for nexus) and they have no qualified engineers. Manufacturers do, but they have no incentives to invest more millions in research and development so that you can keep your device longer.
But as I have already said, do it yourself. Set cpu data on screen and experiment with performance vs other governors while watching the temperature. My experience has been that there is obviously no jumping and very little core plugging/unplugging, because 2.2-2.4 core can do a lot alone without extra efforts...
If you can't behave and maintain an intelligent conversation without resorting to personal attacks, then there is no point for me to talk to you. .
Click to expand...
Click to collapse
I am not attacking you tbh.
Governors doesn't do anything besides controlling the frequencies of cpu. CPU uses correct amount of voltage according to the voltage table.
If what you're saying is correct, doesn't overvoltage makes your phone cooler? It has more energy to process things and doesn't need to jump to higher frequency right?
Kernel developers implement features for reasons. If your theory is correct, why does voltage control exist? Does kernel developers write a thousand lines of code just to do nothing?
zhuoyang said:
I am not attacking you tbh.
Governors doesn't do anything besides controlling the frequencies of cpu. CPU uses correct amount of voltage according to the voltage table.
If what you're saying is correct, doesn't overvoltage makes your phone cooler? It has more energy to process things and doesn't need to jump to higher frequency right?
Kernel developers implement features for reasons. If your theory is correct, why does voltage control exist? Does kernel developers write a thousand lines of code just to do nothing?
Click to expand...
Click to collapse
"I am not attacking you" Yes you were, I said that some bloggers don't know what they are talking about and you replied that I didn't know what I was talking about. Anyway, I accept your veiled apology.
Neither overvoltage nor undervoltage makes the phone cooler. There is an optimal regime for each cpu and if you go outside of it (in either direction), you are inviting trouble. You are not going to destroy your cpu by either under or over voltage, as there is protection in kernel. The phone runs cooler when cpu works less and the optimal regime causes the cpu work less. If you are reducing juice (voltage), you make cpu work longer, which results in overheating.
I gave you an example of performance governor to make a point that this is counterintuitive: while cpu is set at the higher frequencies, it actually performs the tasks and rushes to idle faster, which results in cooler condition. When the same cpu is set lower (and especially if it is under volted), it works longer, jumps to different frequencies, plugs/unplugs cores, which all contributes to overheating....
What is normal values for this phone ? I have diferent chargers, Samnsung - around 600mA, one HTC - around 400mA and another one with 200mA according to that app. Wich one should i use ? So far i used samsung one because it charges fast...2 hours or less, but the battery dies also fast ....so it may be because of the charger ?