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.
With Linpack I see people getting to 848mhz and even 1ghz.
I lose stability at 787mhz and I'm ok at 768. I know that different chips vary... but 1ghz difference?
Is there a way to overvolt on the Eris I don't know of?
The eris OC at 1ghz....thats a lie and some one is pulling your leg lol. The eris is not built handle that and if it did reach 1ghz the motherboard would burn up.
Yeah but 848mhz isn't so farfetched. I can do 787 for a while without any freezes. The freezes do happen though.
If you overvolt it shouldn't be impossible to get up to 848mhz.
As for the 1ghz + entries on linpack's site I think it must be another phone running Eris ROM's/ basebands.
Hungry Man said:
With Linpack I see people getting to 848mhz and even 1ghz.
I lose stability at 787mhz and I'm ok at 768. I know that different chips vary... but 1ghz difference?
Is there a way to overvolt on the Eris I don't know of?
Click to expand...
Click to collapse
I can do 806 all day with Aloysius but my buddy with the same exact setup (i setup it up, so I nkow its exactly the same) can only get stable at 768.
I have not seen anyone with proof or that is respectable, show that they can keep their phone over 806.
"Begin envy now "
I do lol
So there are NO overvolt kernels/ methods?
I can run 806 stable with evil Eris 3, most of the other roms crash when I clock them at 806.
Lucky lol my processor seems to be stuck at 768. 787 doesn't last too long and it's not worth the random FC'ing. I'm sure it would be stable with more voltage and heat hasn't been an issue for me at all at 768 even with Pandora/ Zenonia running for quite a while I haven't gotten even lose 50C.
The question is why would one want to OC that high. I see absolutely no difference in performance at 710 vs anything higher. Probably even lower than that. I just don't see why you would want to run any higher and eat up your battery as well as tax the processor and board more when there isnt a noticeable difference other than linpack scores. Just my opinion but I think all new to OC'ing should be aware that faster isnt always better.
I know that lol I mean... a lot of people who overclock computers don't do it for a performance boost, they do it because they want to see if they can. They won't get better gaming performance they just get a slightly better benchmark.
I want to do it just to do it.
Ok rock on speed demon On that note, I wonder if it could be clocked to the max in a freezer room. If the low temp would help or if it is just hardware limited.
The MAIN problem with overclocking with voltage modification would be heat/ ****ty PSU. I'm sure the Eris battery can get up pretty high, it's a matter of staying cool. I would like to see how high I can get with cooling but I don't even know if overvolting exists for the Eris lol
Dont know about over but I know you can undervolt on it.
If there's undervolting there should be overvolting... someone has to know lol I've tried searching XDA and google but I can't find anything specific.
n2imagination said:
The question is why would one want to OC that high. I see absolutely no difference in performance at 710 vs anything higher. Probably even lower than that. I just don't see why you would want to run any higher and eat up your battery as well as tax the processor and board more when there isnt a noticeable difference other than linpack scores. Just my opinion but I think all new to OC'ing should be aware that faster isnt always better.
Click to expand...
Click to collapse
I tested 710, 768 and 806. I didnt just test with linpack either. I just used apps I normally would run, running for a few days and what not and noticed a difference from 710 to 768 but not really a noticeable diff from 768 to 806. I still keep it at 806 for reasons that my battery life is better. Dont ask me how or why but it just is. I have mine set at 806/480 and for sleep, 480/240. Now most of the day my phone is just in my desk drawer so that could be the reason but i still go a full day with heavy use at the end of the day (bt, wifi, internet radio, run keeper) and still have about 30%+ left when I go to sleep at 10
I have never had a problem with battery lol since overclocking my phone I've only increased battery life. Significantly so.
There has got to be some sweet spot there for OC'ing that gives best perform with least batt consumption. Just wish I knew what it was.
People are getting high because all processors aren't the same. So some can handle, some can't. As for the 1ghz it's a big lie. According to several people including jcase linpack scores can be easily edited and faked. I wouldn't believe anything on linpack that's outrageous.
I sorta figured they wre faking somehow. And I know some processors can handle higher speeds, that's the basis of overclocking. I want to know if I can overvolt my processor.
Can't help you there. Maybe go ask in the IRC? I'm curious if you can as well.
I can hit 787 and run stable... linkpack scores around 5.3-5.4. Oddly enough, my fone refuses to run at 768. I actually have to use a txt file for setcpu to remove 768 from the equation with profiles and the setcpu "trick" my battery life is GREAT. Much better than "stock" even.
-------------------------------------
Sent via the XDA Tapatalk App
Since we are all wondering what is responsible for this rash of bricks I thought I would start a topic about it. I'm hoping some of our electrical engineering crowd will pipe in on this.
First of all I'm not an engineer and all my knowledge of electronics comes from the practical and theory side of being an amateur radio licensee and a tinkerer of electronic devices.
I think that undervolting is just plain crazy. Our phones are devised to perform in a certain manner at a specific range of voltages. Circuits that are under volted tend to destabilize and do strange things. Resistors change the circuit and the wrong input voltage can change eveything downwind so to speak. Capacitors that are undervolted may not even fire at all. With the advent of LSI's a component may get smoked and you won't even get the satisfaction of smelling the magic smoke (acrid burned smell)
Now over volting definitely has much more applicability here because it's just a plain fact that juicing the cpu results in higher clock speed. Problem here is how to dissipate the heat generated. If we were talking about a desktop we could put on a big heatsink and fan and get decent results. If we wanted to go faster we could do liquid cooling and direct freon injection (phase change) on cpu if we really want to have some fun (if anyone is interested in a world record Epic OC attempt on liquid nitrogen send me a PM). However, none of these methods is going to work well on a phone if you want to keep using it to make phone calls.
From my perspective we can easily OC any processor 10-15% without worrying about heat problems and no under/over volting needed for most phones. As mentioned in another thread, to paraprase Duracell, some can take a licking and some will quit ticking. However, outside of this narrow range we are literally asking for odd kinds of trouble. Just like what we have seen of late...
Sent from Bonsai 7.0.3
Well there is nothing wrong with undervolting..we just need to take things a step at a time...instead of undervolting everything doing 1 change at a time would be much more ideal as its easier to root out problems. One thing I notice is lately these things are released in form of 10-20 changes to try to get better then the kernel before it..instead I would rather see isolated test kernels of 1 thing at a time...so lets say UV ram was the culprit(not saying it is)...but maybe LCD UV is ok..and thats probably what most of us wanted
In my case I was running Genocide and was getting really good underclocks(better then most people) and things were stable..when I saw LCD underclocking on the Vision I just couldn't resist...even though I noticed problems from the get go and my intuition was telling me to go back to Genocide as I had better undervolts there anyways the greed of having LCD undervolt was too much to give up.
What ultimately got me was when I saw the thread about the issue in the kernel...I paniced as I have been having issues and proceeded to shut down my phone to get back into clockworkmod...if I didnt do that my phone would probably still be alive...
So ironically what bricked my phone was not only the kernel itself but the warning about the possible brick lol...thats why I quickly put up the warning to others not to panic and shut down their phones following my footsteps...I dont blame anyone but myself..
There will always be sacrifices along the way..thats just how development is...
I agree,I think we are going down the wrong road when it comes to kernels,but everything is trial and error,just wish more time was spent testing; Not just "hey it boots,testers like it" 2 hours later its uploaded...
Sent from my SPH-D700 using XDA Premium App
ecooce said:
I agree,I think we are going down the wrong road when it comes to kernels,but everything is trial and error,just wish more time was spent testing; Not just "hey it boots,testers like it" 2 hours later its uploaded...
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
Well as I said it would have been nice if we got the kernel features separated...aka 1 kernel with UV ram, one kernel with UV CPU and one kernel with UV LCD..then 10 days later if there were no issues go to UV CPU + LCD kernel and UV RAM + UV LCD Kernel..and then if everything is ok 10 days later merge them all into one..
My regret is not bricking my phone but the fact that it was bricked without providing much use...at the very least if my phone was bricked during a UV ram only test for example we would know where the issue was and not go that road..instead we are now stuck guessing the possibilities...
I guess our ambition is getting the better of us :/..slow and steady wins the race...
I totally agree with you about all the changes at one time being detrimental to good development. I've brought this up several times with the Bonsai Team. The problem from my perspective is that if you change 20 things and you have a problem you have no clue about what screwed what. Making one change and making observations is the hallmark of scientific testing. Now sometimes doctors use the shotgun approach, but only when they don't know what will work and someones life is on the line.
Sent from Bonsai 7.0.3
Top Nurse said:
I totally agree with you about all the changes at one time being detrimental to good development. I've brought this up several times with the Bonsai Team. The problem from my perspective is that if you change 20 things and you have a problem you have no clue about what screwed what. Making one change and making observations is the hallmark of scientific testing. Now sometimes doctors use the shotgun approach, but only when they don't know what will work and someones life is on the line.
Sent from Bonsai 7.0.3
Click to expand...
Click to collapse
Yeah I agree as well, however these are regular guys and gals that do this in their own free time and if they compile one thing at a time I believe it becomes way more time consuming. It could literally take months or even years to completely shake down a build, going one by one. Bleeding edge is the only way it can really be done in an open source/freelance environment like this.
epic4GEE said:
Yeah I agree as well, however these are regular guys and gals that do this in their own free time and if they compile one thing at a time I believe it becomes way more time consuming. It could literally take months or even years to completely shake down a build, going one by one. Bleeding edge is the only way it can really be done in an open source/freelance environment like this.
Click to expand...
Click to collapse
your not compiling line by line...your just compiling 1 feature at a time...it may take more time to compile, but you also end up saving time on debugging.
I mean its up to the devs to do their own thing, we can't exactly tell them what to do..but we can offer our suggestions..its up to them if they wish to try it that way or not.
And bleeding edge is not how its done in an open source environment..in an open source environment a feature is tested 1 at a time by forking the tree..then when its been properly finished and tested it gets merged back into the main tree for a release. If it fails to hit stable by time of main release it rolls over to the next release.
Of course everyone has different development policies but the above is a very common one.
Definitely agree about being real careful with undervolting just to squeeze a few percent out of the battery life. Top Nurse for not-an-engineer you are essentially correct about disrupting circuits especially transistors and diodes that function on a specified voltage drop. I, myself, thought I bricked twice only to find out I had undervolted my sleep speed of 200 Mhz by 125 mV essentially bringing it to 100Mhz. The interesting thing is Genocide has all this undervolting and 1.4Ghz speeds and yet I have not heard of any rash of bricks there. Maybe that kernel should be used as a comparison baseline.
Do you BONSAI?
If I remeber right Genocide dosnt UV the RAM...
Sent from my SPH-D700 using XDA Premium App
ecooce said:
If I remeber right Genocide dosnt UV the RAM...
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
Does it undervolt the display?
mattallica76 said:
Does it undervolt the display?
Click to expand...
Click to collapse
no it doesnt, but i dont think display is the issue..also genocide doesnt have BFQ..only CFQ
mattallica76 said:
Does it undervolt the display?
Click to expand...
Click to collapse
No vision kernel was the first kernel publicly released that uv the screen and ram
Sent from my SPH-D700 using Tapatalk
MysteryEmotionz said:
No vision kernel was the first kernel publicly released that uv the screen and ram
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
I do believe the bonsai beta 4.1.0b9 kernel had the display undervolted as well, and I believe the BFQ was enabled by default...someone correct me if I'm wrong. More commonalities I'm sure.
mattallica76 said:
I do believe the bonsai beta 4.1.0b9 kernel had the display undervolted as well, and I believe the BFQ was enabled by default...someone correct me if I'm wrong. More commonalities I'm sure.
Click to expand...
Click to collapse
I found this changelog for bonsai:
- Voodoo color
- Undervolting in several modes including Screen and RAM at certain cpu frequencies
- Overclocking and underclocking configuration for 100mhz-1120mhz is now standard
- Read_ahead tuning to 4096 bytes
- Volume switch provides silent and vibrate control
- Upgrade to CWM 3.0.2.4
- Reduced battery % limit to 5% for Camera, VideoPlayer, and MusicPlayer.
- Increased windowsmgr refresh events_per_sec from 60 to 68
- Updated Maps.apk
---
I dont see BFQ..unless they always had it...
One thing I do notice with Genocide vs VisionKernel is on Genocide kernel 100mhz never really worked...and i odnt mean crashing...I used CPU Spy and it never showed 100mhz..on VisionKernel I did have it hit 100mhz a few times..
Edit: I see BFQ was added on the 31st - r458 - Add BFQ scheduler from Paolo Valente
gTen said:
I found this changelog for bonsai:
- Voodoo color
- Undervolting in several modes including Screen and RAM at certain cpu frequencies
- Overclocking and underclocking configuration for 100mhz-1120mhz is now standard
- Read_ahead tuning to 4096 bytes
- Volume switch provides silent and vibrate control
- Upgrade to CWM 3.0.2.4
- Reduced battery % limit to 5% for Camera, VideoPlayer, and MusicPlayer.
- Increased windowsmgr refresh events_per_sec from 60 to 68
- Updated Maps.apk
---
I dont see BFQ..unless they always had it...
One thing I do notice with Genocide vs VisionKernel is on Genocide kernel 100mhz never really worked...and i odnt mean crashing...I used CPU Spy and it never showed 100mhz..on VisionKernel I did have it hit 100mhz a few times..
Click to expand...
Click to collapse
On the stock Bonsai 4.0.1 kernel, it would not scale down to 100mhz with the conservative governor, but it would with interactive. The 4.1.0 b9 kernel fixed the issue and it would scale to 100mhz with no problem. (other than bricking your phone)
mattallica76 said:
On the stock Bonsai 4.0.1 kernel, it would not scale down to 100mhz with the conservative governor, but it would with interactive. The 4.1.0 b9 kernel fixed the issue and it would scale to 100mhz with no problem. (other than bricking your phone)
Click to expand...
Click to collapse
Hmm..does any other kernel achieve 100mhz?
When I was looking at CPU Spy usually at max it would be like a few seconds on the 100mhz frequency...I would think when shutting down a phone 100mhz frequency might be used during a short interval..the only other person who claimed he got same thing and not on power down but at lock screen..which I know after waking it hits 100mhz...there might be a pattern here :/
So there are a lot of similiarities between the 2 bricking kernels and differences to genocide. Since there is no charging light when plugged in, it is still some catastrophic failure. Would RAM or video failure be enough to prevent the phone from charging? Or turn on the charge light?
Do you BONSAI?
kennyglass123 said:
So there are a lot of similiarities between the 2 bricking kernels and differences to genocide. Since there is no charging light when plugged in, it is still some catastrophic failure. Would RAM or video failure be enough to prevent the phone from charging? Or turn on the charge light?
Do you BONSAI?
Click to expand...
Click to collapse
I find it very very very very unlikely that the screen would do this..usually the screen is a separate component..In a pc for example ive had pc not turn on due to bad ram though...
gTen said:
I find it very very very very unlikely that the screen would do this..usually the screen is a separate component..In a pc for example ive had pc not turn on due to bad ram though...
Click to expand...
Click to collapse
Wasn't thinking the screen, I was thinking the video components on the circuit board due to LCD undervolting. But was def thinking dead RAM as a possibility.
Do you BONSAI?
With just Voltage Control my phone would hit 100 every blue moon. In conjunction with SetCPU on conservative it now idles fine at 100mhz and UV'd by 125. It seems to automatically revert to noop whenever I set it to bpq.
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 ?
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 ?