Related
I wanted to explain black screen issue many folks are encountering with overclocked kernels. The root cause is that voltages at higher clock speeds are not high enough to get the screen to turn on. In other words, if your screen is off and your phone scales beyond 800Mhz, the phone does not have enough power to turn the screen on. You'll almost always scale to the max the moment you hit that power button.
There are a few ways to prevent this from happening (from best to worst):
Create a "screen off" profile in SetCPU to restrict the clock to 800Mhz or below when the screen is off. I think it's obvious why this works. At the same time, a lot of people already do this, which explains why everyone hasn't been having the problem.
Use the conservative governor. Because it scales more gradually, it won't immediately jump past 800Mhz when you attempt to power the screen. There is still a chance of encountering the issue if you attempt to turn on the screen if the device has been busy for a while.
Increase voltages in the kernel. I started experimenting with this before I decided to come here and recommend the first two options. To get the screen to reliably turn on at higher clock speeds, we'd have to raise the voltages substantially. So we'd end up with more risk of damaging components, degraded battery performance and so on. Once the screen is on, the cpu does not actually need more power than it's being given in today's frequency tables. Thus, we'd effectively be increasing power consumption all the time to deal with a need for more power at screen on. Clearly a bad idea.
Unless you're using SetCPU profiles (or equivalent) or the conservative frequency governor, you're going to get black screens. Cyanogen, Pershoot, Evil's and my kernels all use roughly the same voltages, so you're going to need to apply this solution regardless.
There you have it.
*Applauds*
I bow down to your wisdom, sir!
Can you explain why this doesn't happen to me when I'm on CM 6.1.1 ROM?
With setcpu settings at 1209/368 (ondemand scaling, no profiles) I have black screens on Virtuous but neveron Cyanogen's mods.
rgl12miami said:
Can you explain why this doesn't happens to me when I'm on CM 6.1.1 ROM?
With setcpu settings at 1200/300 I have black screens on Virtuous but never
on Cyanogen's mods.
Click to expand...
Click to collapse
I'd have to do more testing to confirm but I would guess more load is generated (events triggered) with Sense ROMs at the time of wake, causing the ondemand governor to scale up to nearly max more rapidly than CM.
There's a simple way to see if it'll ever happen on CM. Set your governor to "performance", with clock speed above 1Ghz. Turn off the screen and see if it fails to turn after a few attempts at toggling it on and off.
I did what you suggested about 30 times and no one has failed. It's a shame,
because I do really love your ROM: speed is incredible. But what bothers me
the most is when the alarm sounds or I receive a call and the screen refuse to
lighten up. I will keep an eye on your rom and for sure I will be back on it soon.
Great job! The best sense rom i've ever seen.
Thanks for this. Works perfectly on my Stock SenseUI ROM with virtuous kernel
Thanks! That explains why the issue hasn't been happening since I set my profile to conservative. That was probably the most annoying issue since I got my G2.
I bet the fact that every cpu is different would also explain why it happens to some and not others.
Again every cpu is different, but here is my settings for screen off. Min 245 max 245. I started min 245 max 368, dropped max down and no adverse effects and great bat life. I have no blackscreen/wakeup issuses. I've been using setcpu to save battery since before the first oc module/kernel.
Would def test kernel that drops below 245 and/or uv it greatly.
fastludeh22 said:
I bet the fact that every cpu is different would also explain why it happens to some and not others.
Again every cpu is different, but here is my settings for screen off. Min 245 max 245. I started min 245 max 368, dropped max down and no adverse effects and great bat life. I have no blackscreen/wakeup issuses. I've been using setcpu to save battery since before the first oc module/kernel.
Would def test kernel that drops below 245 and/or uv it greatly.
Click to expand...
Click to collapse
What do you mean that every CPU is different? At the hardware, firmware, software level?
gee one said:
What do you mean that every CPU is different? At the hardware, firmware, software level?
Click to expand...
Click to collapse
I think he means every cpu handle overclocking differently, for example ive been very unlucky and my cpu cant handle anything above 1.1 Ghz and it crashes if i set it up any higher but lots of people running theirs at 1.8 and they are stable
its just like overclocking PCs every cpu handle overclocking differently even if they have the exact same spec.
I'm bumping this due to how useful this information is and how often the issue still comes up.
Sent from my HTC Vision using XDA App
rmk40 said:
I wanted to explain black screen issue many folks are encountering with overclocked kernels. The root cause is that voltages at higher clock speeds are not high enough to get the screen to turn on. In other words, if your screen is off and your phone scales beyond 800Mhz, the phone does not have enough power to turn the screen on. You'll almost always scale to the max the moment you hit that power button.
Click to expand...
Click to collapse
I don't understand why I don't encounter this issue at all with AOSP ROMs. Is there an obvious reason I'm missing?
poochie2 said:
I don't understand why I don't encounter this issue at all with AOSP ROMs. Is there an obvious reason I'm missing?
Click to expand...
Click to collapse
This was the first question asked (see the fourth post). Here's the OP's theory...
rmk40 said:
I'd have to do more testing to confirm but I would guess more load is generated (events triggered) with Sense ROMs at the time of wake, causing the ondemand governor to scale up to nearly max more rapidly than CM.
Click to expand...
Click to collapse
I haven't seen this issue before either.
ianmcquinn said:
This was the first question asked (see the fourth post).
Click to expand...
Click to collapse
My bad, I missed that.
As per the title, I have started experiencing random system lockups since yesterday. I have had to perform two battery pulls and I'm starting to worry that my ext partition won't be so lucky next time...
I have no idea what is causing the lockups, though both have occurred while using Swype. Coincidence?
For now I'm going to set my system clock back to 600Mhz and use the default input method for a while and see if I still get lockups, at which point I will probably flash another ROM unless I can find a solution, which is where you guys (hopefully) come in. Is there anything else I can do to diagnose and/or solve the problem?
- Typed from my rooted HTC Legend -
It's most likely the OC that's causing the problem, Swpye shouldn't affect the stability. Unless it's a cracked version
Try interactive governor or flash latest kernel from the other thread.
TheGrammarFreak said:
It's most likely the OC that's causing the problem, Swpye shouldn't affect the stability. Unless it's a cracked version
Click to expand...
Click to collapse
That's peculiar, as I've had the processor on 768Mhz for a while now and I've had no problems at all before now.
As for Swype... it could be. ;P
BlaY0 said:
Try interactive governor or flash latest kernel from the other thread.
Click to expand...
Click to collapse
I'll try that, but what exactly does each governor do?
segphault said:
I'll try that, but what exactly does each governor do?
Click to expand...
Click to collapse
It manages when the processor speeds up. It doesn;t run at 768MHz all the time, that's just the highest you allow. Ondemand scales the frequency up when it's needed, and lowers it again afterward. It seems to be a little bugged in our kernels though, and causes crashes.
Interactive does a similar thing, but without polling the CPU. It also ramps the frequency up a little more quickly. I use it, it makes the phone more responsive (IMO), and also eliminates the need for profiles in setCPU (to a degree)
Just checked my kernel version - I already have the latest version (2.6.32.17). I've also set the governor to interactive as suggested, but I have pushed the max clock back to 768Mhz and the min clock to 122Mhz.
While we're here, is there any way to push the min clock down even lower, or would that require fiddling with the kernel? In which case, I have two questions:
1. blay0, I've heard people who can push their min clock down to something ridiculous like 19Mhz if I recall correctly, which makes battery life last a crazy amount of time. Could you include that as the minimum clock in the next kernel for b 0.8?
2. If not, how do I go about changing it myself?
I want to learn.
segphault said:
Just checked my kernel version - I already have the latest version (2.6.32.17). I've also set the governor to interactive as suggested, but I have pushed the max clock back to 768Mhz and the min clock to 122Mhz.
While we're here, is there any way to push the min clock down even lower, or would that require fiddling with the kernel? In which case, I have two questions:
1. blay0, I've heard people who can push their min clock down to something ridiculous like 19Mhz if I recall correctly, which makes battery life last a crazy amount of time. Could you include that as the minimum clock in the next kernel for b 0.8?
2. If not, how do I go about changing it myself?
I want to learn.
Click to expand...
Click to collapse
You'd have to mess around with kernel source code. I wouldn't know where to begin, sorry
Wouldn't 19 MHz min also make the phone painfully slow to wake up? Just curious.
Sent from my Legend using XDA App
MaBlo said:
Wouldn't 19 MHz min also make the phone painfully slow to wake up? Just curious.
Sent from my Legend using XDA App
Click to expand...
Click to collapse
That did cross my mind but other users have reported success with it, so I figured I might as well give it some investigation.
I had mine go to 19 min with screen off once, it did my head in. Maybe interactive with a reasonable upper limit with screen off (like 400) would work, who knows
TheGrammarFreak said:
I had mine go to 19 min with screen off once, it did my head in. Maybe interactive with a reasonable upper limit with screen off (like 400) would work, who knows
Click to expand...
Click to collapse
Maybe not quite 19Mhz, then.
Perhaps we should do some testing to see how much processing power is needed to wake the phone quickly? Is there any way to test that?
Back on topic, I just had another lockup while using the interactive governor. This time I froze up while loading Fruit Ninja.
Now I'm at a total loss for what could be causing the lockups.
- Swyped from my rooted HTC Legend -
Seeing as nobody can seem to pin-point the problem, I'm moving to CM7 permanently as soon as it's released as stable.
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.
After reading through the Thread for the Pre Release of FuguMod Ultra in the development section of this forum I thought I would post some info up for people who are wondering why it doesn't work with their phone, and just some general info on overclocking.
- First off, not all phones will be able to run at 1366MHz. Every CPU made has a range of freuqencies it will work at, and it is different for every single one. So some may be able to handle 1366MHz and above, others may max out at 900MHz. If you are getting black screens, freezes, or random behaviour, then your CPU doesn't like the frequency you have it at, try a lower frequency.
- Always keep an eye on the temp of the CPU when testing overclocking, if the CPU gets too hot, and fail safes don't work, there is a chance you could fry your CPU.
- With the FuguMod Ultra kernel, you must also be aware that gpu bus frequencies have been changed, so if your phone is not happy with that it will black screen. (as bus speeds are like cpu speeds, every different device can handle different clock speeds)
- plls values have been changed, and these may cause problems on your phone.
So if you want to have a go at overclocking your phone, back it up, and then give it a go. Select a frequency, and test with something pretty cpu intensive (3d game, multiple quadrant passes) and see if there are any bugs/overheating during a 15min time period. If you notice any problems/too much heat, try a lower frequency, and try again. And if for some reason your phone doesn't like the kernel, you can reflash with your previous kernel or a new ROM as you have already backed up your data.
If you have any other questions about overclocking, feel free to post here and I will try my best to answer them.
--- Samsung G3, InDroid 4.3, FuguMod 2.4 B3 800MHz ---
How can you check the CPU temperature? I thought it was only battery temperature.
Sent from my GT-I5800 using XDA App
dilzo said:
How can you check the CPU temperature? I thought it was only battery temperature.
Sent from my GT-I5800 using XDA App
Click to expand...
Click to collapse
The battery temp is a good representation of how hot the processor is getting as it is right next to the battery (only a thin sheet of metal seperating it) If the battery rises in temperature by a few degrees, then you can summize that the cpu is probably getting a few degrees hotter than that. I really wouldn't recommend letting the battery get above 55degrees (celcius) as this means the CPU may be getting up close to 65degrees (celcius) which is a very bad thing.
Good post.
Note that if you want to make some stress-tests, you have to put "PERFORMANCE" governor and set the max freq you want to test.
marcellusbe said:
Good post.
Note that if you want to make some stress-tests, you have to put "PERFORMANCE" governor and set the max freq you want to test.
Click to expand...
Click to collapse
Yes, Very true!!
Must also say, Your kernels are pretty legendary! Waiting patiently for the offical release of your FuguMod Ultra
m not able to see time in state with both setcpu and cpuspy and it seems deep sleep is also not working.
Piyush Rawal said:
m not able to see time in state with both setcpu and cpuspy and it seems deep sleep is also not working.
Click to expand...
Click to collapse
How have you got your phone set up? i.e. what ROM are you using etc.
I am using stock jpq with app2sd, swap, zipalign, ramhack and stuff. Setcpu is installed with default min/max freakquency, No profiles in use and undervolt a bit.
Ok,
This may be an issue caused by XXJPQ, as it is a new release there may be some sort of conflict. Have you tried asking if anyone else has this issue in this thread? http://forum.xda-developers.com/showthread.php?t=1132697
I haven't played around with JPQ yet so don't know what the bugs are yet.
Also, are you running a stock kernel? Have you confirmed that the phone has been rooted properly as well?
It's definitely a bug in Kernel. I tried three different roms and i wasn't able to check time in state in any of them (I am talking about fugumod ultra prerelease kernel here).
With previous versions of fugumad kernel everything is fine. So definatly a bug in kernel.
Piyush Rawal said:
It's definitely a bug in Kernel. I tried three different roms and i wasn't able to check time in state in any of them (I am talking about fugumod ultra prerelease kernel here).
With previous versions of fugumad kernel everything is fine. So definatly a bug in kernel.
Click to expand...
Click to collapse
Ok cool, I'll report the bug to the developer so that he can have a look into it. Thanks for testing and proving to the kernel.
Little bit of info some might find helpful. After some recent testing, I have found that some people might experience a black screen freeze when phone is in standby for a while with 83MHz min setting and on demand governor. I am not sure of the exact reason for this, whether it is a bug, or that the processor just doesn't like going that low for extended periods of time. If you experience this type of error, just hard reset the phone then open setcpu after phone has loaded and change the "standby" profile minimum to at least the next step up on the slider. Personally I use 223 setting as it provides a smoother lock screen animation, and no significant difference in battery drain.
Sent from my super smooth GT-I5800 using XDA App
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