I've recently been curious as to how much influence my chosen CPU frequencies and screen settings have on power usage. Of course, it is common knowledge that an overclocked processor requires more current and that our displays are power hungry, but how apparent is the difference? Is the relationship between these variables and battery consumption linear, or is the increase in power demand perhaps exponential?
In an effort to explore these questions, I set up a controlled test that logged CPU frequency and screen brightness against current usage. This data should not be assumed to directly apply to all Incredibles; I was looking for correlations rather than exact calculations on how much energy a specific setting uses.
Methods (go ahead and skip down to the findings section if this is too dry for you)
AMOLED Inc
Kernel: Chad's 2.6.37.1-incredikernel-gb-2272011
ROM: CyanogenMod 7 - Nightly #11
And not that it should matter, but someone will ask so...
Radio: 2.15.00.11.19
HBOOT: 0.92
Recovery: ClockworkMod 3.0.0.8
CPU frequencies were controlled using SL4A scripts and Tasker. Max frequency can be manipulated through /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq, so a single echo command is all that is needed to adjust it. I set up a rudimentary if/then script to bump up the max frequency one notch at a time, then used Tasker to execute this script every two minutes.
When Tasker would execute the script, it would also write an entry to a log file shared with CurrentWidget. This ensured that the CPU frequency was being noted between milliamp readings. Multiple readings were taken at each level, and entries that immediately preceded or followed clock changes were discarded in an effort to use the more stable readings at each frequency.
To control for other influences, all other phone services were disabled, including GPS, Wi-Fi, and Bluetooth. The phone was also placed in Airplane Mode so that reception was not a factor.
The CPU governor was set at "performance," ensuring that it remained at its max frequency. To task the CPU, I put together another simple script which just ran md5sum commands in a never-ending loop. Before recording data, I verified that this script was enough to load the CPU and cause it to scale up to max frequency when using other governors.
The full range of frequencies was tested at the screen's dimmest factory setting (20/255) as well as the screen's brightest setting (255/255). Additionally, a separate test was run with the CPU fixed at 576 MHz and Tasker periodically bumping up the screen brightness.
Findings
My data showed an almost perfect linear correlation between clock speed and power use, as well as brightness and power use.
I was a little surprised at how big of a difference I was able to find. With the screen at its dimmest setting, 128 MHz consumed ~80 mA while 1,113 MHz consumed more than 300 mA. For a stock Inc battery (1,300 mAh) that marks the difference between (over) 16 hours of runtime and less than 4.5 hours of runtime. Of course, anyone who has tested the limits of underclocking knows that the phone is utterly useless at 128 MHz.
The influence of brightness was less of a surprise. At a given CPU frequency, the average difference that I noted between min screen brightness and max screen brightness was ~118 mA.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I would love to be able to test every single combination of CPU frequency and screen brightness, but it would take hours, and I cannot keep my phone out of use for that long. I did generate some additional projections, however, based on the trends observed in the combined tests. I've added these projected points to the graph below, based on screen settings of 80/255, 140/255, and 200/255.
Shortcomings / questions for further exploration
Given the sterile nature of the data collection, I can't just make a blanket statement like "underclocking your max CPU to 883 MHz will yield an average of 15% more battery life over leaving it set to 998 MHz." As convenient as it would be to make such a claim, it ignores a number of realities. None of us are using 100% of our processor at all times, so a more accurate prediction of runtime would need to take the phone's resting behavior into account.
We should also consider that the CPU's frequency will affect the speed at which it can perform tasks. If you clock your processor too low, you may actually end up consuming more power since your phone will have to work longer (resulting in more wake time and more screen-on time).
A more technically inclined member may want to chart CPU frequencies against power usage, while also including some sort of performance benchmark. Such a matrix would offer users an even better model on which to judge the cost/benefit of over or underclocking. But even the simple testing which I've completed above takes a fair amount of time and keeps the phone from being otherwise used, so it's not a very convenient thing to test.
What I find most interesting about the data is the implication that a user who overclocks his CPU max to 1,113.6 MHz and sets his screen brightness to 80 could use less power than a user who underclocks his CPU max to 883 MHz but uses a brightness of 200.
The easiest takeaway, of course, is an illustration of why users experience such wildly different run times on the same rom/kernel setup. Again, this should come as no surprise, but skepticism should be exercised any time someone promises you that switching to a specific rom/kernel combo will guarantee you X hours of battery life.
[This work may be freely distributed for non-commercial purposes, as long as it is passed along unchanged and in whole, with credit to author and a link back to this XDA thread.]
Wow, this is a shocker. I guess I should kill the habit of using higher brightness and be less afraid to OC.
pianoplayer said:
Wow, this is a shocker. I guess I should kill the habit of using higher brightness and be less afraid to OC.
Click to expand...
Click to collapse
I notice you have an SLCD DInc. It's worth mentioning that mine is AMOLED and I don't know if the two have similar power usage across the brightness scale.
byrong said:
I notice you have an SLCD DInc. It's worth mentioning that mine is AMOLED and I don't know if the two have similar power usage across the brightness scale.
Click to expand...
Click to collapse
Wow, I didn't notice that. I guess you're right. I read somewhere that darker themes help on AMOLED and lighter themes are better for battery on SLCD. My theme is quite light so I think that makes my on the less-consuming side for the screen.
byrong, this is awesome data. Just what I needed to see, thank you. I have the exact same setup and have been trying to figure out the best cpu/brightness settings for my device. With seeing this data its helped me determine some of the values I was going back and forth on. Now I guess I'll have to wait and see how my battery holds up.
Excellent. Thanks for the data. Even if I never put any of that into use it's still fun for the nerdy part of me (most of it ) to know! Excellent data, and just goes to show how important screen brightness is over the CPU Speed. Most users would probably get better battery life if they spent more time darkening the screen than installing a CPU governing program haha.
Great info! Kinda knew this already but cool to see it all graphed out.
Thank you for the graphs! I have the SLCD... but I think the results would be similiar regardless of screen type, especially in real-world usage.
Awesome work. Gives me some ideas about using setcpu...
Chad give me more description... what new features are in the new kernel....
Sent from my ADR6300 using XDA App
Gorilla* said:
Chad give me more description... what new features are in the new kernel....
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
Ummm? It will enable you easier entrance/exit from the matrix.
Nice work btw byrong.
Horay for empiricism!
Thanks for the legwork and for sharing. Impressive.
[I for one welcome our new Android overlords ::: DInc::SLDC::x.7.28::CWM3.0.0.8::CM7::chad's]
phaze one said:
Ummm? It will enable you easier entrance/exit from the matrix.
Nice work btw byrong.
Click to expand...
Click to collapse
Aren't we calling it "the Grid" now?
[I for one welcome our new Android overlords ::: DInc::SLDC::x.7.28::CWM3.0.0.8::CM7::chad's]
Byrong,
Fantastic write up as always..
I'm curious if you would care to do one on the effects of a task killer on battery life/CPU and RAM usage?
Since Android launched cupcake, I've been strongly opposed to the use of task killers, as Android handles processes much better than we do.. but I would love to see if fact can back up that opposition or if these apps truly don't cause any harm.
I'm just not nearly as amazing with words and data as you clearly are.
via Incredible Redemption
Man, I wish I hadn't just given my mom my DInc and instead played with it some more. I would love to help do some more long term tests to help with this.
That and seeing the variation for screen type, mine being an SLCD.
Sent from my TBolt using XDA
Thank you all for the kind words.
AdhvanIt said:
I'm curious if you would care to do one on the effects of a task killer on battery life/CPU and RAM usage?
Click to expand...
Click to collapse
Great idea.
I'm game, but I would have to think long and hard about how to design the testing parameters. In all likelihood, I'd need some suggestions / ideas from you guys to carry out such a test.
I would need recommendations on a reliable logging program for RAM, CPU Freq, and CPU Load.
Unlike most of my other power testing, I would not want to run such a test in Airplane mode. One of the reasons that people give for aggressive task-killing is shutting down processes that may be using data in the background. As such, I would need conditions that actually allowed an observable difference in data usage.
Since the phone won't be in Airplane mode, my controls take a big hit. During a test, for example, I might receive a lot of calls, texts, and emails, all of which will have a major impact on CPU, RAM, and battery. The cleanest solution I can see is running the test across multiple nights: X full nights without a task-killer and X full nights with one.
The other big question is how to set up the task killer. I.E. should I allow it to kill everything, or set up an exclusion list? I'm leaning towards the exclusion list, but then we have to decide what to exclude. We should also think of a designated interval for the task killer.
If you want to help me brainstorm these issues, I'm happy to discuss them right in this thread.
TodesEngeI said:
Man, I wish I hadn't just given my mom my DInc and instead played with it some more. I would love to help do some more long term tests to help with this.
That and seeing the variation for screen type, mine being an SLCD.
Sent from my TBolt using XDA
Click to expand...
Click to collapse
The beauty of this type of testing is that it can be done by any motivated individual, on any device that allows scaling of the CPU. If you already have that new TBolt of yours rooted, you should be able to recreate the tests on that. I'm sure fellow TBolt users would love to see your findings.
byrong said:
Thank you all for the kind words.
Great idea.
I'm game, but I would have to think long and hard about how to design the testing parameters. In all likelihood, I'd need some suggestions / ideas from you guys to carry out such a test.
I would need recommendations on a reliable logging program for RAM, CPU Freq, and CPU Load.
Unlike most of my other power testing, I would not want to run such a test in Airplane mode. One of the reasons that people give for aggressive task-killing is shutting down processes that may be using data in the background. As such, I would need conditions that actually allowed an observable difference in data usage.
Since the phone won't be in Airplane mode, my controls take a big hit. During a test, for example, I might receive a lot of calls, texts, and emails, all of which will have a major impact on CPU, RAM, and battery. The cleanest solution I can see is running the test across multiple nights: X full nights without a task-killer and X full nights with one.
The other big question is how to set up the task killer. I.E. should I allow it to kill everything, or set up an exclusion list? I'm leaning towards the exclusion list, but then we have to decide what to exclude. We should also think of a designated interval for the task killer.
If you want to help me brainstorm these issues, I'm happy to discuss them right in this thread.
Click to expand...
Click to collapse
SetCPU has a lot of the logging/current system information that you would need, including:
CPU frequency: Time in state for each freq
CPU load average
Total and available RAM
As well as a number of other things. Screenshots are attached below.
As for controls, I would think auto kill at screen wake is a commonly used setting. Or maybe go at 1/2 to one hour intervals...
If you're going to set up a blacklist within the task-killer, I would recommend not adding too much to it, as the exclusion of too many apps would alter test results. But certainly add any auto-updating widgets you have to it.
I think leaving data on is also appropriate for this test-there are a number of apps that will not start/update (mostly web based like twitter/facebook and such widgets) if there is no data connection.
Edit: Forgot to add images. Lol.
AdhvanIt said:
SetCPU has a lot of the logging/current system information that you would need, including:
CPU frequency: Time in state for each freq
CPU load average
Total and available RAM
Click to expand...
Click to collapse
The info tab in SetCPU is indeed helpful for more of a 'snapshot view', but I don't know of a way to make it log that information to a text file over time, do you?
Time in state is helpful, and can be accessed via:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
But the problem is that it doesn't tell the story of when the CPU was scaling. It would be far more useful if I could plot CPU load and CPU freq over a time line, rather than just have averages or sums.
Same story with RAM: I want to be able to plot over the course of time.
AdhvanIt said:
As for controls, I would think auto kill at screen wake is a commonly used setting. Or maybe go at 1/2 to one hour intervals...
Click to expand...
Click to collapse
I like to automate my tests as much as possible, not only to (try to) remove myself as an influence, but so that I'm not tied to the phone for hours at a time, looking at a watch. If I did a screen on/off setting, it would require me to turn the screen on and off at select times, remaining consistent between tests.
So intervals would definitely be the way for me to go. I think I'll start a poll of some sort to get an idea of how most people set theirs.
AdhvanIt said:
If you're going to set up a blacklist within the task-killer, I would recommend not adding too much to it, as the exclusion of too many apps would alter test results. But certainly add any auto-updating widgets you have to it.
Click to expand...
Click to collapse
Agreed that I want to keep the exclusion list to a minimum. I will make this part of my poll as well. I don't want to create a strawman position by setting up the task killer to be more aggressive than anyone actually uses it. For example, I don't want to set it to kill Android OS, Launcher, etc, as that would just be excessive and probably does not reflect how anyone uses them.
This will be an extremely controversial one, and if I don't strike a delicate balance, people will be quick to throw out the data completely on the grounds of, "Well that's fine and all, but that's not how I use my Task Killer."
Thanks for helping me think this through.
byrong said:
The info tab in SetCPU is indeed helpful for more of a 'snapshot view', but I don't know of a way to make it log that information to a text file over time, do you?
Time in state is helpful, and can be accessed via:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
But the problem is that it doesn't tell the story of when the CPU was scaling. It would be far more useful if I could plot CPU load and CPU freq over a time line, rather than just have averages or sums.
Same story with RAM: I want to be able to plot over the course of time.
I like to automate my tests as much as possible, not only to (try to) remove myself as an influence, but so that I'm not tied to the phone for hours at a time, looking at a watch. If I did a screen on/off setting, it would require me to turn the screen on and off at select times, remaining consistent between tests.
So intervals would definitely be the way for me to go. I think I'll start a poll of some sort to get an idea of how most people set theirs.
Agreed that I want to keep the exclusion list to a minimum. I will make this part of my poll as well. I don't want to create a strawman position by setting up the task killer to be more aggressive than anyone actually uses it. For example, I don't want to set it to kill Android OS, Launcher, etc, as that would just be excessive and probably does not reflect how anyone uses them.
This will be an extremely controversial one, and if I don't strike a delicate balance, people will be quick to throw out the data completely on the grounds of, "Well that's fine and all, but that's not how I use my Task Killer."
Thanks for helping me think this through.
Click to expand...
Click to collapse
Definitely makes sense to automate...
I'm not really sure of any way to log these things regularly unless you know how to set up a script and have it pull the logs every so often...
Agreed-It will likely get met with debate regardless, as it's always had its fanbase and its opposition. Not sure really how to get a good balance, but I think the polls are a good way to start.
Survey is up: http://www.surveymonkey.com/s/8GD2F2H
(Posted here to reach a wider audience: http://forum.xda-developers.com/showthread.php?t=1032456)
I decided to keep it as simple as possible, both to encourage more people to respond, and to simplify the collection of responses.
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.
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 ?
Hey guys, Kyuubi10 back once again with another Guide.
I thought it might be useful to pop in a couple results of my trial and error for the HTC One M8.
Note: This is not scientifically, calculated accurate, but it's close enough, based on estimates.
After following these guides:
http://forum.xda-developers.com/showthread.php?t=2769899
https://vjnaik.wordpress.com/2015/06/25/kernel-tweak-interactive-governor-paramaters-rooted-phone/
I decided to make a summary guide of the above but with specific HTC One M8 values.
Since I agree with the idea of "race to idle" embodied in the Wheatley governor, I tried emulating that on the Interactive governor while also keeping it as efficient as possible.
Here are the values (all others not mentioned, leave default):
Code:
[B]above_hispeed_delay [/B]- 80000 2265600:10000
[B]go_hispeed_load[/B] - 95
[B]hispeed_freq[/B] - 1728000
[B]io_is_busy[/B] - 1
[B]min_sample_time[/B] - 10000
[B]target_loads[/B] - 45 729000:80 883200:50 1267000:85 1497600:50 1728000:90 1958400:50
[B]timer_rate[/B] - 10000
[B]timer_slack[/B] - 5000
"above_hispeed_delay" makes sure that longer time is spent on the frequency step 1.72Ghz, before quickly raising higher into max freq.
1.72Ghz is the most energy efficient frequency with a good performance, e.g. it will not cause lag during casual usage, while it uses minimal voltage.
If the load is too high for this frequency to handle, I set the time short once it's gone over this freq step so that it will not waste time before reaching max freq. Thus dealing with the issue asap.
Another important parameter is "target_load", with this I have defined that at each efficient freq step the load needed to overcome it would be higher than normal. But it would up-scale quickly when using non-efficient frequencies.
The other parameters I have set so that the frequency is lowered as soon as CPU load is finished, so that it will rush back to idle as quickly as possible.
The interesting thing about this set-up is that for general, non heavy usage, it basecally functions as if I have underclocked to 1.72Ghz, but when the CPU is truly pushed it reaches up to 2.5Ghz which is my Overclocked max freq value.
Thus both saving battery and providing high performance.
I have felt no lag, and it's been quite a smooth experience while I used this
Combined with using GPU rendering (found in developer settings), and Seeder, the over all usage is pretty good.
Battery usage has been very efficient and I have managed to squeeze out an extra hour or two using this.
I highly recommend it!
Hope I helped you guys... don't forget to press the thanks button if you also feel that I did!:good::good:
I noticed I have some governor settings left at 0 or blank. I did some quick googling, found some other tweaks for the M8 and the interactive governor. So I played around a bit, and I think the following would be useful to add to the above tweaks.
-----------------------
sampling_down_factor: 60000
sync_freq: 1036800
up_threshold_any_cpu_load: 65
up_threshold_any_cpu_freq: 1190400
boost: 0
boostpulse_duration: 80000
--------------------
Also of note there is not a entry for " io_is_busy " under the Interactive governor under ElementalX Sense kernel v6.03. I believe it's possible to modify the governor to add the function, if it's desired.
Hope this helps others.
nice one i read the links that you posted and follow the guides there also to tweak the interactive governor on the first link that you posted is really interesting he has updated that post also, i followed his guide inspired by your guide and i have been getting good results on my phone with battery and performance i mean almost no battery drain at all while my phone is idle. thanks for the help mate!
Plugged the settings into Yankactive on DU. Quick, freqs stay low when nothings going on, seems legit. I set my timer_rate higher tho, 10000 feels a little low, makes me think that the CPU will spend too much time polling loads.
SaskFellow said:
I noticed I have some governor settings left at 0 or blank. I did some quick googling, found some other tweaks for the M8 and the interactive governor. So I played around a bit, and I think the following would be useful to add to the above tweaks.
-----------------------
sampling_down_factor: 60000
sync_freq: 1036800
up_threshold_any_cpu_load: 65
up_threshold_any_cpu_freq: 1190400
boost: 0
boostpulse_duration: 80000
--------------------
Also of note there is not a entry for " io_is_busy " under the Interactive governor under ElementalX Sense kernel v6.03. I believe it's possible to modify the governor to add the function, if it's desired.
Hope this helps others.
Click to expand...
Click to collapse
Some of those actually make no difference. Since they are overruled by other perameters. E.g. up_threshold aren't used in interactive, since they follow target_load instead.
Sampling_down_factor on the other hand is overrulled by the timer features of interactive.
When you use ondemand, or conservative, sampling_down_factor is a fun parameter to play with, but not interactive.
While Sync_Freq I don't like using because it raises minimum frequency to its value...although temporarily, the timer features can already deal with CPU loads efficiently.
lil_kujo said:
nice one i read the links that you posted and follow the guides there also to tweak the interactive governor on the first link that you posted is really interesting he has updated that post also, i followed his guide inspired by your guide and i have been getting good results on my phone with battery and performance i mean almost no battery drain at all while my phone is idle. thanks for the help mate!
Click to expand...
Click to collapse
Great The links are important!! They are my sources, and often contain much more detail than what I use in my guides. I attempt creating a well ordered summary, but my sources are better if you don't mind reading loads.
I'm glad I could help
munkyvirus said:
Plugged the settings into Yankactive on DU. Quick, freqs stay low when nothings going on, seems legit. I set my timer_rate higher tho, 10000 feels a little low, makes me think that the CPU will spend too much time polling loads.
Click to expand...
Click to collapse
That's the idea. And never heard of Yankactive...but I'm gonna assume it's good lol.
And about time_rate, you are right, but you are also wrong.
There isn't a true right answer unless someone performs a scientific experiment in order to fully test which one is better.
But I'll explain why I put my one short... I want the frequencies returning to IDLE asap. While yes, you are right it's polling often, it also returns to idle much faster, rather than staying at higher frequency uselessly wasting battery.
I'll try to run some tests checking CPU load, if CPU load considerable lowers I'll come back and report.
Yankactive is Interactive with some under the hood tweaks, I believe, same tunables. I also looked at some documentation on Interactive and I think the target_loads have to be in ascending order based on load when paired with clock speeds, I'm gonna mess with them a bit and see what I get. Link
munkyvirus said:
Yankactive is Interactive with some under the hood tweaks, I believe, same tunables. I also looked at some documentation on Interactive and I think the target_loads have to be in ascending order based on load when paired with clock speeds, I'm gonna mess with them a bit and see what I get. Link
Click to expand...
Click to collapse
And no, target_loads has to be in ascending order based on FREQUENCY. You are applying load percentages to frequency ranges, therefore it is imperative that its the frequency defining the order.
e.g. 50 4:80 10:20 12: 50 means:
50% load before going to the next frequency step, until you reach frequency 4, then use 80% instead until frequency 10, then use 20% instead until 12, then use 50% until max frequency.
Feel free to play with them as much as you want, just make sure to keep the idea of using efficient frequency steps in mind.
Kyuubi10 said:
And no, target_loads has to be in ascending order based on FREQUENCY. You are applying load percentages to frequency ranges, therefore it is imperative that its the frequency defining the order.
e.g. 50 4:80 10:20 12: 50 means:
50% load before going to the next frequency step, until you reach frequency 4, then use 80% instead until frequency 10, then use 20% instead until 12, then use 50% until max frequency.
Feel free to play with them as much as you want, just make sure to keep the idea of using efficient frequency steps in mind.
Click to expand...
Click to collapse
Thank you for the knowledge dump, been scraping the barrel for weeks trying to figure out tunables!
munkyvirus said:
Thank you for the knowledge dump, been scraping the barrel for weeks trying to figure out tunables!
Click to expand...
Click to collapse
Hehe it's a pleasure.
It's a way I find to give back to the community, since I learn so much through it. I can try help make life easier for those who follow the same path I did.
Hello kyuubi10 thanks for your help, would it be ok to change mp decision to battery saver mode ? Whats your take on that?
Wow, this is awesome! I had the performance gov on, which just destroyed my battery. Now, I have a question for you!
What is your take on "Multicore Power Savings" ? I'm using a flarport kernel which has it set to aggressive by default. Should this be changed to anything else while using your gov settings? Thanks for any assistance!
lil_kujo said:
Hello kyuubi10 thanks for your help, would it be ok to change mp decision to battery saver mode ? Whats your take on that?
Click to expand...
Click to collapse
I have never heard of mpdecision having a battery saver mode XD
Would you please expand on that? Also tell me which tweaking app you are using?
Kyuubi10 said:
I have never heard of mpdecision having a battery saver mode XD
Would you please expand on that? Also tell me which tweaking app you are using?
Click to expand...
Click to collapse
It's in the ex app mate, it uses a less aggressive version of mpdecision to saver on battery power but I can't say that I noticed much improvement TBH.
Sent from my HTC One_M8 using Tapatalk
Anonaru said:
Wow, this is awesome! I had the performance gov on, which just destroyed my battery. Now, I have a question for you!
What is your take on "Multicore Power Savings" ? I'm using a flarport kernel which has it set to aggressive by default. Should this be changed to anything else while using your gov settings? Thanks for any assistance!
Click to expand...
Click to collapse
You had performance on?? You do realise that the perf gov basically keeps your CPU cores running on max frequency all the time right?
No wonder your battery was dying XD
Anyhoo....good thing you found my guide
Now, about multicore power savings, as usually with most things you will be compromising something to gain something else...always keep that in mind.
With MPS you'll be giving up some multitasking, in order to gain some battery savings.
Why (you may ask)?
Well, think about a to-do list, and for each list you have one person completing the tasks within that list. Let's say you have four lists and 4 people completing those tasks.
What MPS does is it takes as many tasks as possible and places them within a single list, for one person to do. At the end of the day that one person will have done a lot of work, while the other 3 will have done very little work. The drawback? The work was completed much slower, because only one person was doing it.
Why can MPS be good? It is the way it chooses which CPU to use to add the tasks to, it chooses CPUs which are already turned on, rather than turning a new one on.
The frequency voltages on each core range from the lowest of 775mV, to the highest of 1075mV. That's a 300mV increase in battery consumption between lowest frequency and highest. (Mind you, 1075 for me is an overclocked value, if you are not OC then it will be even less)
When CPU cores have nothing to do they get turned off....they don't idle at 775mV....they are literally off. Therefore around 0mV usage XD
If you get tasks which would have run on 2 CPUs at minimum frequency, using only 775mV each, and put them to run on only 1 CPU at MAX frequency at 1075mV, you still have about 400mV battery savings. Now lets say its something which would have used 4 CPUs, but you end up using only two.... then the battery savings double to 800mV.
Final answer...it depends on your tastes, what do you prefer most? Multitasking or battery saving.
Personally I keep it enabled, but not aggressive.
But if you really don't care about multitasking, you may as well leave it as aggressive.
lil_kujo said:
Hello kyuubi10 thanks for your help, would it be ok to change mp decision to battery saver mode ? Whats your take on that?
Click to expand...
Click to collapse
smeejaytee said:
It's in the ex app mate, it uses a less aggressive version of mpdecision to saver on battery power but I can't say that I noticed much improvement TBH.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Well, I use adiutor, so I don't have that option.
I am happy with my phone how it is (if it wasn't for the damned plug issues XD)
But @lil_kujo, as @smeejaytee said....he hasn't noticed much improvement.
So I'd trust his advice
Kyuubi10 said:
You had performance on?? You do realise that the perf gov basically keeps your CPU cores running on max frequency all the time right?
No wonder your battery was dying XD
Anyhoo....good thing you found my guide
Now, about multicore power savings, as usually with most things you will be compromising something to gain something else...always keep that in mind.
With MPS you'll be giving up some multitasking, in order to gain some battery savings.
Why (you may ask)?
Well, think about a to-do list, and for each list you have one person completing the tasks within that list. Let's say you have four lists and 4 people completing those tasks.
What MPS does is it takes as many tasks as possible and places them within a single list, for one person to do. At the end of the day that one person will have done a lot of work, while the other 3 will have done very little work. The drawback? The work was completed much slower, because only one person was doing it.
Why can MPS be good? It is the way it chooses which CPU to use to add the tasks to, it chooses CPUs which are already turned on, rather than turning a new one on.
The frequency voltages on each core range from the lowest of 775mV, to the highest of 1075mV. That's a 300mV increase in battery consumption between lowest frequency and highest. (Mind you, 1075 for me is an overclocked value, if you are not OC then it will be even less)
When CPU cores have nothing to do they get turned off....they don't idle at 775mV....they are literally off. Therefore around 0mV usage XD
If you get tasks which would have run on 2 CPUs at minimum frequency, using only 775mV each, and put them to run on only 1 CPU at MAX frequency at 1075mV, you still have about 400mV battery savings. Now lets say its something which would have used 4 CPUs, but you end up using only two.... then the battery savings double to 800mV.
Final answer...it depends on your tastes, what do you prefer most? Multitasking or battery saving.
Personally I keep it enabled, but not aggressive.
But if you really don't care about multitasking, you may as well leave it as aggressive.
Click to expand...
Click to collapse
Hah, thanks for the guide-- I am pretty well versed in task / resource allocation on multi-threaded systems, though
Main reason I was asking was because I haven't a clue what some of the values are on this interactive gov. Just wanted to make sure they didn't clash! I'll chance it to "Enabled" rather than "Aggressive," because a compromise between the two sounds the best
As for Performance gov-- default setting on this flarport kernel, didn't bother to check it until I noticed that any time a core was on, it was racing at 2.5ghz, even with nothing going on. Battery pretty much committed suicide
Anonaru said:
Hah, thanks for the guide-- I am pretty well versed in task / resource allocation on multi-threaded systems, though
Main reason I was asking was because I haven't a clue what some of the values are on this interactive gov. Just wanted to make sure they didn't clash! I'll chance it to "Enabled" rather than "Aggressive," because a compromise between the two sounds the best
As for Performance gov-- default setting on this flarport kernel, didn't bother to check it until I noticed that any time a core was on, it was racing at 2.5ghz, even with nothing going on. Battery pretty much committed suicide
Click to expand...
Click to collapse
LOL I suggest you change kernel asap! If the dev uses uses Performcance gov as his default he doesn't know what he is doing XD
And no, as far as I know governor tunables won't ever clash with MPS.
Thanks!
rjavc said:
Thanks!
Click to expand...
Click to collapse
You're welcome! Pleasure to help.
But I'd appreciate if you press the thanks button on the relevant posts which helped you. That's the XDA way :good::good:
Kyuubi10 said:
You're welcome! Pleasure to help.
But I'd appreciate if you press the thanks button on the relevant posts which helped you. That's the XDA way :good::good:
Click to expand...
Click to collapse
Hi mate, I wondered if I could ask your advice, I want to set interactive up on my maw Android TV box it's quad 1.5gb and I want maximum performance as its constantly plugged in, there is no battery so that's not an issue,
Sorry if you think this OT but I thought I'd ask you as you know the governor well, thank you in advance mate.
Sent from my HTC One_M8 using Tapatalk
Following the advice of @shadowstep and @Davey126 I have created a thread to separate this from the whole Interactive guide thread by @soniCron. This is due to (1) one, the thread is no longer updated for almost a year and (2) two; to explain the tweak, establish baselines/guides for testers and to gather more interested individuals to try it out.
-------------------------------------------
Introducing GlassCannon!
Description: A sound modification to the famous interactive parameters. Provides the smoothest interface, great performance while bestowing the lowest frequencies available. Ramping up quickly to maximize "inputs" from I/O overheads then immediately ramping down once tasks are done. The perfect balance between lowering down your frequency, and finishing up tasks quickly.
Why Glasscannon? Why not?
Who am I? I came from the hammerhead scene. I have been modding interactive parameters for more than 2 years and owns a community called: Android Battery Community whom has its own fair share of followers but has been quite stagnant for almost a year ever since my hammerhead broke. Though, I have been tweaking things with other devices; LG G4, Samsung Note 6, OPO and other smartphones that I got my hands on. Now I think it's time for me to get into the Nexus 6P scene. And after just literally 2 days after I posted the tweak, there are messages and posts tempting me to port it to N5X and LG G4, and with enough encouragement as well as a promise of testers; I edited the values matching my GlassCannon tweak with the former LG G4 .txt file I have in my desktop and here it is!
The difference? After years of being a paranoid about my battery (literally looking at dashboards, cpu cycles etc. you know, that guy who just tends to not be satisfied about everything) I finally settled down and read a lot of things and made it as my basis. Most tweaks in here uses target load as an optimal way to force cores to stick into lower frequencies but we won't be doing that with GlassCannon. We will be using two underrated tunables: above_hispeed_delay and input_boost. This two underrated tunables are being neglected for years, though some used it quite efficiently; I have yet to see a tweak that maximizes the two tunable's potential. We would be using above_hispeed_delay as a substitute to the unpredictable target_load. Instead of assigning too much within a tunable that we can't even lay our finger on how it works properly, why not let the SoC handle it and assign a delay along with timer_rate so it can run efficiently? And let input_boost jump up here and there to provide quick surge whenever there are tasks running under the hood.
Look under (Version: N5X l G4):
Code:
[COLOR="Gray"]/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor interactive
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 384000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1440000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 93
/sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0 600000:19000 787200:20000 960000:24000 1248000:38000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 50000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 600000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack 380000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 29 384000:88 600000:90 787200:92 960000:93 1248000:98
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 60000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
/sys/devices/system/cpu/cpu4/cpufreq/scaling_governor interactive
/sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 384000
/sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq 1824000
/sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load 150
/sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay 20000 960000:60000 1248000:30000
/sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate 60000
/sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq 960000
/sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_slack 380000
/sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads 98
/sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time 60000
/sys/devices/system/cpu/cpu4/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu4/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu4/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu4/cpufreq/interactive/boostpulse_duration 0
/sys/module/cpu_boost/parameters/input_boost_freq 0:600000 1:600000 2:600000 3:600000 4:960000 5:960000
/sys/module/cpu_boost/parameters/sync_threshold 1248000
/sys/module/cpu_boost/parameters/boost_ms 40
/sys/module/cpu_boost/parameters/migration_load_threshold 15
/sys/module/cpu_boost/parameters/load_based_syncs Y
/sys/module/cpu_boost/parameters/shed_boost_on_input N
/sys/module/cpu_boost/parameters/input_boost_ms 300
/sys/module/cpu_boost/parameters/input_boost_enabled 1
/sys/module/msm_performance/parameters/touchboost 0
/sys/module/msm_thermal/core_control/enabled 0
/sys/module/msm_thermal/parameters/enabled Y[/COLOR]
Explanation:
go_hispeed_load: Anything between 85-94 is average by my tests, it tends to stick to hispeed_load 40-60 which is what I think would be "optimal" for our cat.
above_hispeed_delay: The most important part of our tweak along with input_boost. This should set up the perfect "delay" so cpu cores could adjust and decide before ramping up to higher frequencies. Our frequency set as hispeed from little cluster is 600000.
target_loads: We won't be dwelling much in this. We put a small amount so that our frequency could ramp up if needed and take a pause on frequencies we deemed to be really significant; 600mhz, 672mhz, 960mhz and 12348mhz. Along with hispeed_delay, it should provide low consumption and tend to stick on 384mhz and 600mhz 89% of the time.
timer_slack: Put it to 380000, just trust me.
max_freq_hysteresis: Asking why theres jitters and a bit of stuttering on your screen? this is the culprit. Turn it to 0 and you will be fine as long as you correct the other tunables. This is because hysteresis actually uses "former" frequencies to calculate which frequency would be best to ramp up to next. If you tend to stick to lower frequencies more, with this on then you will be sticking at low frequencies almost forever, which obviously isn't something good.
input_boost: Now, to explain why this is important; there are two things I would like to emphasize. (1) One, this value was made so that under the hood tasks as well as simple bumps to your frequency if there is a notification, sync etc. would be possible. (2) this value is extremely useful to provide that quick boost to complete tasks with ease. The big clusters would have an input_boost of 633000 which was supposed to be the stock mhz. Why? I deemed that the big cluster isn't that necessary unless you are running an extremely graphic heavy game. So tone it down to 384mhz underclocking it and provide input boost to the mhz that was supposed to be the stock frequency, increasing battery life without sacrificing anything.
Will this be updated? NO, NEVER. I am asking myself why does this other "tweaks" update from time to time if there are no kernel parameters that are changing? Aren't all those tweaks supposed to be tested hundreds of times before releasing? Then why change the parameters again? Am I asking too much? Am I fat? NO. Just NO. EXCEPT if there will be changes within the interactive parameters then sure.
Maximal, Minimal and Nominal Frequencies? Not to hurt anyone's heart but I personally think that this is a retardified(if that is in fact a word) version of "I shall say something smart". I don't see the point of determining what the nominal, maximal and minimal frequencies are as we can't even put a finger what they literally mean. This is actually "subjective" and I really find this so called nominal frequencies irrelevant. Please don't hate.
Do note that most of the explanations above were not edited and is still pretty much the same as N6P description because I'm lazy af.
Credits: @soniCron, @xSilas43, @shadowstep for pointing out the missing timer_slack and input_boost, google for many things to read, this website for music while typing, that website for providing me more things to read, a bucket of fries and two chickens to make me company.
Go ahead and feel free to download the .txt file below and happy tweaking!
======================A SINCERE THANKS TO EVERYONE WHO TESTED AND PARTICIPATED
Tips Hat
After many things happening and after more than a month, I am really glad that we have succesfully ported GlassCannon to N5X and LG G4 (or any other device with same cpu structure). I am proud to present to you the fruits of the small labors of both me and the team as well as others behind the scene testing GlassCannon for your devices.
What has been the verdict? Overall, via landslide; the GlassCannon's Beta2.0 has come out on top. I figured and of course realized after the alphatest that people in N5X community complained (though in small dose) about stutters and a small lag in some apps. Most were debunked especially if you are using an online app but I had to wrap around everything and investigate further. Even though I promised that the Beta would be more battery efficient, I adjusted it so that it should provide a much better performance and smoothness without compromising the battery life of our cats. And thus, the verdict is Beta 2.0 *autistic screeching*
Special thanks to: @Curlyfry2121 @shadowstep @crian @spartan268 @IcyGlacial @Lazerlord
Just a headsup, I will be leaving the Alpha below for other people to download if they still want some!
Grab a copy below! Enjoy!
Official Testers:
@shadowstep N6P
@Lazerlord
@Curlyfry2121
@mesmurized
@@spartan268
@deani77 N6P
@igoorsoouza
@CazeW
Credits to:
Everyone whom are secretly using the GlassCannon profile. To my Kentucky Fried Chicken for keeping me company. @Davey126 for encouragement and other stuffs, @The Flash because you are the fastest man alive, @shadowstep for being a MTG fan, @flar2 for being an awesome developer and supporting this kind of tweaks, @soniCron for starting this and many more. Huge thanks! and I hope this will go on for the better!
Thanks
Sent from my Pixel using Tapatalk
Firefox, Google plus, and Snapchat, with a little Hangouts during school where the data connection is little to none half the day.
Curlyfry2121 said:
Firefox, Google plus, and Snapchat, with a little Hangouts during school where the data connection is little to none half the day.
Click to expand...
Click to collapse
Thanks for the second full cycle *takes notes*
Well thats a huge steep slope we have. I can see where thise battery drains come from and you really have to do something about those. Have you ever considered airplane mode while you are at an area where there's little to no signals? Those red marks should have drained your battery like crazy! At first I was skeptical when you said you have a bad signal lol.
Now about the cpu times etc.:
(1) One, that is pretty much a great cpu stats for both little and big. I can see that it sticks to 600mhz the way I tuned it too. Those little percentage above 600mhz are pretty nice, that means thst they never got stuck in that number for more than 30-40ms (above_hispeed_delay and timer_rate) doing the trick. (2) Two, I can even see the big cluster's cpu5 off, what more can I ask for? (Purely intentional to set a really high ts
Arget_load and go_hispeed_load at lowest frequency to make this happen) this means everythung works fine as intended (the way I tweaked it to be.)
Anyway this is to be expected for light usage. Btw could you please install accubattery for me and turn on "cpu core" on the overlay settings within the app? There should be 6 overlay batteries at your bottom right continuously changing to see cpu frequencies. Now with thst try a full cycle again and note this:
*At what apps does most of the cores get to red (above 3/4)
*In your observation, how long does it stick to yellow (1/2 above) and red frequencies? (Above 3/4)? Please tell in miliseconds e.g. red at 20ms most of the time etc.
You will see what I'm talking about when you install the app
Anyways continue again with a normal full cycle bro and I'll be waiting for the next update!
phantom146 said:
Thanks for the second full cycle *takes notes*
Well thats a huge steep slope we have. I can see where thise battery drains come from and you really have to do something about those. Have you ever considered airplane mode while you are at an area where there's little to no signals? Those red marks should have drained your battery like crazy! At first I was skeptical when you said you have a bad signal lol.
Now about the cpu times etc.:
(1) One, that is pretty much a great cpu stats for both little and big. I can see that it sticks to 600mhz the way I tuned it too. Those little percentage above 600mhz are pretty nice, that means thst they never got stuck in that number for more than 30-40ms (above_hispeed_delay and timer_rate) doing the trick. (2) Two, I can even see the big cluster's cpu5 off, what more can I ask for? (Purely intentional to set a really high ts
Arget_load and go_hispeed_load at lowest frequency to make this happen) this means everythung works fine as intended (the way I tweaked it to be.)
Anyway this is to be expected for light usage. Btw could you please install accubattery for me and turn on "cpu core" on the overlay settings within the app? There should be 6 overlay batteries at your bottom right continuously changing to see cpu frequencies. Now with thst try a full cycle again and note this:
*At what apps does most of the cores get to red (above 3/4)
*In your observation, how long does it stick to yellow (1/2 above) and red frequencies? (Above 3/4)? Please tell in miliseconds e.g. red at 20ms most of the time etc.
You will see what I'm talking about when you install the app
Anyways continue again with a normal full cycle bro and I'll be waiting for the next update!
Click to expand...
Click to collapse
Gotcha! And yeah I did use airplane mode one time but I forgot to today lol. I will install it and I'll follow your instructions for tomorrow's cycle, and yeah now you get what I meant ?
phantom146 said:
Thanks for the second full cycle *takes notes*
Well thats a huge steep slope we have. I can see where thise battery drains come from and you really have to do something about those. Have you ever considered airplane mode while you are at an area where there's little to no signals? Those red marks should have drained your battery like crazy! At first I was skeptical when you said you have a bad signal lol.
Now about the cpu times etc.:
(1) One, that is pretty much a great cpu stats for both little and big. I can see that it sticks to 600mhz the way I tuned it too. Those little percentage above 600mhz are pretty nice, that means thst they never got stuck in that number for more than 30-40ms (above_hispeed_delay and timer_rate) doing the trick. (2) Two, I can even see the big cluster's cpu5 off, what more can I ask for? (Purely intentional to set a really high ts
Arget_load and go_hispeed_load at lowest frequency to make this happen) this means everythung works fine as intended (the way I tweaked it to be.)
Anyway this is to be expected for light usage. Btw could you please install accubattery for me and turn on "cpu core" on the overlay settings within the app? There should be 6 overlay batteries at your bottom right continuously changing to see cpu frequencies. Now with thst try a full cycle again and note this:
*At what apps does most of the cores get to red (above 3/4)
*In your observation, how long does it stick to yellow (1/2 above) and red frequencies? (Above 3/4)? Please tell in miliseconds e.g. red at 20ms most of the time etc.
You will see what I'm talking about when you install the app
Anyways continue again with a normal full cycle bro and I'll be waiting for the next update!
Click to expand...
Click to collapse
Accubattery requires me to pay to use the overlays, and I have no money what so ever on my play account :crying: is there anything else I could use instead?
Curlyfry2121 said:
Accubattery requires me to pay to use the overlays, and I have no money what so ever on my play account :crying: is there anything else I could use instead?
Click to expand...
Click to collapse
I forgot about all of that ? well I dont really recommend the other alternatives since most are outdated. Though cpu float should do the trick
I'm going to start all over with my testing again in case my previous one was skewered for some strange reason. Downloaded gboard instead of bb keyboard and rebooted my phone. I'll reset the CPU stats as well after my app updates are done since that'll likely tax things a little too much. I'll have proper results probably 24 hours from now.
My main culprit right now is that the g4 skin is more heavyweight than thought to be so a nudge more CPU power is needed for general tasks to account for it if that makes any sense. Otherwise i run my phone fairly lean as it's debloated and i make use of greenify, amplify, and powernap so there's minimal services and apps in the background at most times.
spartan268 said:
I'm going to start all over with my testing again in case my previous one was skewered for some strange reason. Downloaded gboard instead of bb keyboard and rebooted my phone. I'll reset the CPU stats as well after my app updates are done since that'll likely tax things a little too much. I'll have proper results probably 24 hours from now.
My main culprit right now is that the g4 skin is more heavyweight than thought to be so a nudge more CPU power is needed for general tasks to account for it if that makes any sense. Otherwise i run my phone fairly lean as it's debloated and i make use of greenify, amplify, and powernap so there's minimal services and apps in the background at most times.
Click to expand...
Click to collapse
Not to jump on some hate-wagon here but I am really against powernap, thought that's just me.
I have gboard as well and has chosen a substratum dark overlay for it (if you don't have a substratum support just get the material black theme) also, gboard consumes battery a little tinsy bit than your normal keyboard, don't forget to disable the snippets and share to google statistics in the preference tab to avoid continuous syncing. I'll be waiting for the results and if everything still seems to lag, I might cook something different especially for you
Reasons for new thread:
3) This is a different method to the once described before.
Android O, Naptime FORCE DOZE, My previous stats are as follows;
(This was using my custom governor tweaks and the skipped/unknown lost battery in the middle is a bootloop)
Forgot this xD
After 2-3 days on the latest version, I continue to see overnight battery usage (sleep+doze+battery) trending a bit lower then with my prior profile HawkFlyv1.2. This along with a noticeable increase in responsiveness, puts GlassCannon at the top of my current list.
Good work @phantom146. I'll try to work on providing details for this alpha test in the next day or so
LazerL0rd said:
Reasons for new thread:
3) This is a different method to the once described before.
Click to expand...
Click to collapse
LazerL0rd said:
Android O, Naptime FORCE DOZE, My previous stats are as follows;
(This was using my custom governor tweaks and the skipped/unknown lost battery in the middle is a bootloop)
Click to expand...
Click to collapse
That instagram... :laugh:
LazerL0rd said:
Forgot this xD
Click to expand...
Click to collapse
Any stutters or jitters? phone freezes etc.?
About the battery life, any comments on that? and the one we talked about the pm (regarding the ramping down and input_boost) any thoughts after this cycle?
Will wait for your answer
Mesmurized said:
After 2-3 days on the latest version, I continue to see overnight battery usage (sleep+doze+battery) trending a bit lower then with my prior profile HawkFlyv1.2. This along with a noticeable increase in responsiveness, puts GlassCannon at the top of my current list.
Good work @phantom146. I'll try to work on providing details for this alpha test in the next day or so
Click to expand...
Click to collapse
I am glad you are liking this profile and will wait for more results, also; it would help me if you can try GlassCannon with heavy usage using heavy graphical games such as need for speed asphalt, nba etc. I really want to see if we have any kind of lags or stutters using high performance games. Thanks for the continuous support!
phantom146 said:
That instagram... :laugh:
Any stutters or jitters? phone freezes etc.?
About the battery life, any comments on that? and the one we talked about the pm (regarding the ramping down and input_boost) any thoughts after this cycle?
Will wait for your answer
I am glad you are liking this profile and will wait for more results, also; it would help me if you can try GlassCannon with heavy usage using heavy graphical games such as need for speed asphalt, nba etc. I really want to see if we have any kind of lags or stutters using high performance games. Thanks for the continuous support!
Click to expand...
Click to collapse
Was getting stuttering with Geo Dash ?? but I think it's just the settings I've enabled and or it's bad optimisations. Battery is equal to or slightly less than my previous governor. After a while I don't see much stuttering (btw i had stuttering before on Geo Dash too xD). There's one thing I enabled that you didn't though. And it's a value called fast_ramp_down. I'm gonna try without it now and see if there's still stuttering.
Just checked and stuttering is MASSIVELY reduced by disabling that option. Well, I thought it would be good. Anyway here are today's stats;
PS - I've decided to keep it, with a few of my own changes xD and sorry about the recharging, I was watching some TV shows ?
LazerL0rd said:
Was getting stuttering with Geo Dash but I think it's just the settings I've enabled and or it's bad optimisations. Battery is equal to or slightly less than my previous governor. After a while I don't see much stuttering (btw i had stuttering before on Geo Dash too xD). There's one thing I enabled that you didn't though. And it's a value called fast_ramp_down. I'm gonna try without it now and see if there's still stuttering.
Click to expand...
Click to collapse
LazerL0rd said:
Just checked and stuttering is MASSIVELY reduced by disabling that option. Well, I thought it would be good. Anyway here are today's stats;
PS - I've decided to keep it, with a few of my own changes xD and sorry about the recharging, I was watching some TV shows
Click to expand...
Click to collapse
well thats good to hear I was really wondering why you were getting stutters as 4 of my testers never got them. Its cool it is your phone to begin with so just tweak away but thanks for keeping the tweak it means a lot to me that somebody will use them as a daily profile :good:
Btw, those stats are crap hahahaha I can't even see where to begin with those charging cycles haha :silly:
phantom146 said:
well thats good to hear I was really wondering why you were getting stutters as 4 of my testers never got them. Its cool it is your phone to begin with so just tweak away but thanks for keeping the tweak it means a lot to me that somebody will use them as a daily profile :good:
Btw, those stats are crap hahahaha I can't even see where to begin with those charging cycles haha :silly:
Click to expand...
Click to collapse
Tomorrow I'm trying a mix of yours and a few I've created before. I done a little research and it seems my idea should work. But it's more experimental than Android O :laugh:
---------- Post added at 07:41 PM ---------- Previous post was at 07:40 PM ----------
The day after I'll test yours again, and I'll stay with whatever is better ?
So here’s what I got: It’s not about getting more power out of your processor. It’s something else..
As a PC Overclocker, getting more power out of the Phone’s processor was the first thing I thought was behind Phone Overclocking. But that should be impossible right? I mean.. how the hell are you gonna cool that thing? You can’t.. And it is. That’s why benchmarks give you the finger after you OC your phone. At best you’ll get about 15% more “points”, which of course is laughable.. But then again why do people do it? Is it a fetish? Well it’s not. It’s about these three things:
UI Reaction Time – UI Animations Smoothness – Memory Management
Three things that determine the quality of your daily experience with your phone.
Every vendor makes his own adjustments to the Kernel that determines the behavior of the hardware in response to the software. Some make it right, some don’t. And when you find yourself hostage to the latter, the only way you can break free and restore your phone’s true potential, is with a custom Kernel that allows you to adjust it. And it’s not even necessary to increase the frequencies! Tightening the timings, or even better eliminating them, can make all the difference in the world! But since a Mobile Chip has a built in protection against overheating, and raising the frequencies could not possibly harm it, then what hell.. why not?
And that god damn memory management that doesn’t let you have more that 4 - 5 apps in the background, even though you have 4 GB of RAM!.. what the hell is that! Well you can fix that too.
So you see, appearances can be deceiving. Phones are different creatures that the PCs. We do different things with them, so we need different things from them. And if you’re willing to give up just a little bit of your battery life.. man..you will NOT wanna go back!
So that’s it!
PS. Speaking of battery life, there is also that thing called “Underclocking”. It can even double your battery life, but of course the price would be the exact opposite effects of the above. Every man has his poison!..
Conpsycon said:
......But since a Mobile Chip has a built in protection against overheating, and raising the frequencies could not possibly harm it, then what hell.. why not?....
Click to expand...
Click to collapse
That is false. Even with thermal protection, the lifespan of the cpu can be drastically reduced if its overclocked and constantly running hot.
And many users overclock in order to get a better experience playing games.
barrack1 said:
That is false. Even with thermal protection, the lifespan of the cpu can be drastically reduced if its overclocked and constantly running hot.
And many users overclock in order to get a better experience playing games.
Click to expand...
Click to collapse
That is true in general. It's called electromigration and it doesn't matter if you cool it well enough. It is caused by the increased kinetic energy of the electrons. But phone CPUs don't get stressed enough to see it happening. Even in PCs where actual overcloking takes place, it would take many years to actually see it happening, and a very serious increase in performance.
So in comparison one could say that it really is safe.
One interesting thing that someone said to me last night though, is that custom kernels don't have a perfect temperature throttling when necessary. So one should check the temps in the initial stage of testing to make sure that it doesn't get too hot.
Two useful links about CPU Temperatures:
https://www.xda-developers.com/processor-temperature-results-for-tens-of-socs-how-hot-is-your-chip/
https://www.quora.com/What-is-the-safe-temperature-of-mobile-CPU
Conpsycon said:
That is true in general. It's called electromigration and it doesn't matter if you cool it well enough. It is caused by the increased kinetic energy of the electrons. But phone CPUs don't get stressed enough to see it happening. Even in PCs where actual overcloking takes place, it would take many years to actually see it happening, and a very serious increase in performance.
So in comparison one could say that it really is safe.
One interesting thing that someone said to me last night though, is that custom kernels don't have a perfect temperature throttling when necessary. So one should check the temps in the initial stage of testing to make sure that it doesn't get too hot.
Click to expand...
Click to collapse
I would've disagree with that. Overclocking used to work reasonably well a long time ago but for about 10-15yrs the headroom in desktop cpu's have shrunk and overclocking does not give stable results. My own experiences coincides with what I've heard with people who work in IT who build/sell pc's - overclocked cpus will encounter much more errors and intermittent problems and will require resetting back to stock clocks or even underclocking in order to be stable.
barrack1 said:
I would've disagree with that. Overclocking used to work reasonably well a long time ago but for about 10-15yrs the headroom in desktop cpu's have shrunk and overclocking does not give stable results. My own experiences coincides with what I've heard with people who work in IT who build/sell pc's - overclocked cpus will encounter much more errors and intermittent problems and will require resetting back to stock clocks or even underclocking in order to be stable.
Click to expand...
Click to collapse
Check this out for example: I underclock my CPU to 1689MHz from 2000MHz, but I change the governor to Performance, which keeps the cores constantly to that frequency WHEN operational. The result is a MUCH snappier behavior with no apparent latency, zero stress to the CPU, and battery compensation by the lower frequency.
Could you do that otherwise? That's what I'm talking about! Full flexibility!
Conpsycon said:
Check this out for example: I underclock my CPU to 1689MHz from 2000MHz, but I change the governor to Performance, which keeps the cores constantly to that frequency WHEN operational. The result is a MUCH snappier behavior with no apparent latency, zero stress to the CPU, and battery compensation by the lower frequency.
Could you do that otherwise? That's what I'm talking about! Full flexibility!
Click to expand...
Click to collapse
Thats not overclocking and you did not talk about flexibility. Even the title of your thread says "Overclock".
You said overclocking cpus on pc's and phones were safe and would take "many years" to see any degradation.
barrack1 said:
Thats not overclocking and you did not talk about flexibility. Even the title of your thread says "Overclock".
You said overclocking cpus on pc's and phones were safe and would take "many years" to see any degradation.
Click to expand...
Click to collapse
I said both of them, and they do not conflict with each other. I explained it in my first post.
Underclocking is a bad thing. unless you can't overclock much because of battery and temperature limitations, underclocking is not recommended. It depends on your governor, a stupid governor will slow you down and be visible on weak devices. your case is due to have stupid governor in phone, but suitable with strong device & want to save battery but don't need to lock freq at maximum
barrack1 said:
Thats not overclocking and you did not talk about flexibility. Even the title of your thread says "Overclock".
You said overclocking cpus on pc's and phones were safe and would take "many years" to see any degradation.
Click to expand...
Click to collapse
cpu will not degrade in life no matter how high frequency, overclock and runs continuously but its life cycle will be affected by high temperature and high voltage
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}