{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
To everyone complaining, I've heard you!
Glasscannon, is an interactive profile designed to provide smoothness and great UI performance without sacrificing battery life, or so I have planned. There have been a lot of hiccups lately which I and a handful of people are experiencing. I as the creator, is responsible on fixing this issues and providing a much better and more fluid glasscannon experience. Issues that are present should be addressed in here and will be mentioned and tackled one-by-one so that we will know what caused the problem. If you wanna test this new parameters out, please do follow the instructions and do not attempt to change them whatsoever because it will make the tests obsolete.
The issues I have compiled via pm, own experience and post related stuffs are mentioned below:
Slow wakeup coming from deepsleep/doze which sometimes leads to freezes on panic.
Slow application loading time as reported by some users, some even said that it crashes some apps.
Freezes, stutters and lags when changing from one app to another especially if there are a lot in the background.
Unintentional drops from both clusters even with high cpu load.
Bad idle drain.
A quick note from the issues provided above:
Slow wakeup from doze has been an issue not only by glasscannon or by other kernel profiles but also with the whole android system and SystemUI itself. It started appearing at Nougat update (Marshmallow rarely encountered this issue) and this has yet to be solved by google. Some discussions and proofs for these: Slow Wakeup from Doze - Nexus6p and Slow/Unresponsive wakeup from doze - Nexus5x. I however, would also blame the profile for increasing this load time, this is to be explained by "understanding kernel parameters" below.
Application loading times are all mostly user-based. Some apps are just poorly coded that the UI experience is downright bad. One for example is using SwiftKey Keyboard; there are a lot of freezes coming from this app and due to that I really suggest users to try Gboard. Users who experience stutters on updated apps are however special cases and cpu frequencies not putting small "boosts" to its cores and not recognizing loads coming from the applications are to be pointed at. Don't worry, I think I found the fix.
Idle battery drain is something I have never experienced from GC. People whom are experiencing this should check alarms, kernel wakelocks and partial wakelocks. A tool that can help you with these is: BetterBatteryStats. Also, the cpu would RARELY get to a high frequency on screen-off especially if you have a screen-off limiter. On the other hand, I might have not experienced this because I am managing partial wakelocks and alarms really well coming from my own experience so I still would like to know what the community would say.
FOUR VITAL KERNEL PARAMETERS explained:
There are four major parameters that I am looking at which in theory should fix the problems. Everyone should read this carefully and I hope you understand my explanation as to why and how it will change the way the device runs. Changing these values always has pros and cons so just a heads-up; read thoroughly.
timer_slack: probably the reason why there is some idle drain coming from glasscannon, and also the reasons why on some profiles your cat is sticking on high frequency too much. The thing is, setting timer_slack to a high frequency such as 380000 ensures faster UI experience because it will wait for 380ms before going back to "interactive" state which means it'll ramp down back from the highest frequency to a more "suitable" frequency based on timer_rate or cpu load computed at that time. However setting it too low such as -1 makes the highest frequency to ramp down as fast as barry allen. Setting it too low would cause some unstable things such as freezes and stutters because it'll contradict the cpu load computed at that time. To make things simpler: high timer_slack: higher battery drain but smooth UI experience, low timer_slack: lower battery drain but slower UI experience. This might also be the issue concerning the idle drain some people talk about. Finding the "best" spot in between the pros and cons is the one we should be aiming, please do see the beta test section below.
timer_rate: the one responsible for checking the cpu load. This thing is pretty self-explanatory; set it, to 60000 then it means every 60ms the kernel will check the load of the cpu and tell the cores to ramp up or down depending on how heavy the load is. Setting it high af would means it'll compute less often which UNFORTUNATELY with my tests should give you slower UI experience and stutters. Why? we all know that cpu loads are highly based on applications we are using. Accessing recents, going from this app to another changes the cpu load every ms. Then higher timer_rate is good right? NO, higher timer rate means it allows checking less and more often than not would not allow frequencies to ramp up. Let's say you are playing a CPU intensive game then all of a sudden you click on "home" then load another app. If you set it high, it'll work cpu frequency up with a much higher delay compared to a lower value, therefore not providing the "boost" we are all aiming for.
target_loads: the original glasscannon interactive parameters are pretty good tbh but this doesn't mean it's perfect. I will say this, it is coded to specifically NOT stay on the lowest frequency to avoid slow UI but there is one problem (look below)
above_hispeed_delay: the problem. Even though glasscannon had set target_loads lower than anything else, the delay caused by this parameter ensures a much slower ramp up and thus providing those stutters we are all avoiding. I find the values now are absurdly high and is a pain in my sexy butt. This should be fixed soon so please look at the test thread below.
These are my inputs so please read them. Below, you will see the beta test section where the four (4) values would be changed to correspond the issues and hopefully fix them soon. Once everything is looking good, I will post the FINAL update for glasscannon and hopefully the devs would still love the profile as much as I do.
CREDITS:
@frap129, @The Flash, @flar2, @shadowstep, @NYCHitman1, @DEVILOPS 007, @Bobbaloo, @Mrcactuseater
BETA TEST SECTION:
Hello there! so you wanna try something that'll help me? Alright hop in! First of all, this beta test will be divided into four (4) phases. Each phase will correspond on one value changed. After one complete cycle and reporting you can go to the next phase, please look below for more details:
INSTRUCTIONS: Each phase will correspond one change at a time. For example, the first phase you need to change above_hispeed_delay. You need to report back as to what you think changed and if it feels smoother, also; please do report with a cpu frequency shot either by kernel apps or bbs. Then reset your cpu frequency from your kernel app and then add the next parameter for the next phase and so on.
REPORT EVERY CYCLE/PHASE. ADD CPU FREQUENCY SCREENSHOTS THEN RESET BEFORE APPLYING THE SECOND PHASE WITHOUT CHANGING THE VARIABLES EDITED BEFORE. EACH PHASE WILL CORRESPOND TO ONE CHANGE AT A TIME AND ONE CPU CYCLE AT A TIME, if you want, YOU CAN TRY TWO CYCLES PER PHASE WHICH IS BETTER.
Phase 1:
above_hispeed_delay: 0 600000:19000 960000:24000 1248000:28000 (small cluster) - 20000 960000:24000 1248000:28000 (big cluster)
Click to expand...
Click to collapse
Phase 2:
timer_slack: 80000 (both clusters)
Click to expand...
Click to collapse
Phase 3:
timer_rate: 20000 (both clusters)
Click to expand...
Click to collapse
Phase 4:
target_loads: 75 960000:93 1248000:98 (little cluster) - 90 960000:95 1248000:28000
Click to expand...
Click to collapse
All tests results and inputs coming from the angler community are really and highly appreciated! Thank you and have a great testing ahead!
Reserved
Good to see development continuing! As you stated, many of these issues aren't caused by glasscanon specifically and plague many profiles. Personally, I think these are just some of the drawbacks of the interactive governor. Using conservative based governors like chill and relaxed, I don't have slow wakeup or slow app launch, but I do have worse idle drain. Just some thoughts, nothing concrete
frap129 said:
Good to see development continuing! As you stated, many of these issues aren't caused by glasscanon specifically and plague many profiles. Personally, I think these are just some of the drawbacks of the interactive governor. Using conservative based governors like chill and relaxed, I don't have slow wakeup or slow app launch, but I do have worse idle drain. Just some thoughts, nothing concrete
Click to expand...
Click to collapse
While I do think some are actually android issues and interactive governor's fault, I am pretty sure we as the almighty people behind who can tinker everything in the cpu can do something about it or lessen its impact. Right now (1 week of testing), as far as I am concerned, I have already fixed several issues namely:
*Lags on wakeup
*Application loading time and
*Freezes
About the drain though, I cannot concretrly prove that the profile is using battery on idle as I have bluetooth on all the time with mi fit, so I would need someone to aid me for it.
You have a good eye conservative governors have some problem reeling down to frequencies when needed. I havebon my hammerhead days tried to tinker it but gave up because I can only make it into two things, too aggressive to ramp up and down or just too friggin slow like my grandma.
phantom146 said:
While I do think some are actually android issues and interactive governor's fault, I am pretty sure we as the almighty people behind who can tinker everything in the cpu can do something about it or lessen its impact. Right now (1 week of testing), as far as I am concerned, I have already fixed several issues namely:
*Lags on wakeup
*Application loading time and
*Freezes
About the drain though, I cannot concretrly prove that the profile is using battery on idle as I have bluetooth on all the time with mi fit, so I would need someone to aid me for it.
You have a good eye conservative governors have some problem reeling down to frequencies when needed. I havebon my hammerhead days tried to tinker it but gave up because I can only make it into two things, too aggressive to ramp up and down or just too friggin slow like my grandma.
Click to expand...
Click to collapse
What help do you need with idle drain? I'm on phase 3 as I forgot to do it last night.
DEVILOPS 007 said:
What help do you need with idle drain? I'm on phase 3 as I forgot to do it last night.
Click to expand...
Click to collapse
Same screenshots of frequencies but with additional SoT screenshot, battery info screenshot under battery settings to see those cute lines if a phone wakes up and app drains percentage again coming from battery settings
phantom146 said:
While I do think some are actually android issues and interactive governor's fault, I am pretty sure we as the almighty people behind who can tinker everything in the cpu can do something about it or lessen its impact. Right now (1 week of testing), as far as I am concerned, I have already fixed several issues namely:
*Lags on wakeup
*Application loading time and
*Freezes
About the drain though, I cannot concretrly prove that the profile is using battery on idle as I have bluetooth on all the time with mi fit, so I would need someone to aid me for it.
You have a good eye conservative governors have some problem reeling down to frequencies when needed. I havebon my hammerhead days tried to tinker it but gave up because I can only make it into two things, too aggressive to ramp up and down or just too friggin slow like my grandma.
Click to expand...
Click to collapse
I'm not saying that its impossible, but It may be difficult to achieve all of the goals (keeping your insane battery life while improving performance). However, you could look into scheduler tunables. Rather than changing how the cpu frequency reacts to tasks, you may be able to achieve better battery by modifying how tasks are scheduled to begin with. Here are some in-kernel examples, though I'm unsure of the sysfs paths for them.
https://github.com/frap129/angler/commit/c2ed7fb6b7150e04ca4a8406e50e012fa066d120
https://github.com/frap129/angler/commit/1352b5a5cb6e83b1099964e5429cb91ec10ff838
https://github.com/frap129/angler/commit/ac750e9f3c8497c3561d28b6a31b9233814e7988
frap129 said:
I'm not saying that its impossible, but It may be difficult to achieve all of the goals (keeping your insane battery life while improving performance). However, you could look into scheduler tunables. Rather than changing how the cpu frequency reacts to tasks, you may be able to achieve better battery by modifying how tasks are scheduled to begin with. Here are some in-kernel examples, though I'm unsure of the sysfs paths for them.
https://github.com/frap129/angler/commit/c2ed7fb6b7150e04ca4a8406e50e012fa066d120
https://github.com/frap129/angler/commit/1352b5a5cb6e83b1099964e5429cb91ec10ff838
https://github.com/frap129/angler/commit/ac750e9f3c8497c3561d28b6a31b9233814e7988
Click to expand...
Click to collapse
I 100% agree with you about this. The problem is, everyday users are only familiar about cpu frequencies and tunables and not sysctl. That's why I have posted several days ago documentations regarding vm tuning and sysctl but I think ppl in angler see it as a "too much of a read" lol.
Just a quicj question, the valued coming from here are default or you fine tuning it?
phantom146 said:
I 100% agree with you about this. The problem is, everyday users are only familiar about cpu frequencies and tunables and not sysctl. That's why I have posted several days ago documentations regarding vm tuning and sysctl but I think ppl in angler see it as a "too much of a read" lol.
Just a quicj question, the valued coming from here are default or you fine tuning it?
Click to expand...
Click to collapse
Those are not the default values, those are tuned values that both me and Flash have picked into our kernels.
EDIT: a few things
1. Not sure if you knew, but I found the sysfs controls for sched tunables in /proc/sys/kernel
2. I've started messing with voltages on my kernel and noticed a few things. On BIG cores, 302MHz and 633MHz use the same freq, so we can run min freq at 633 without any battery impact
frap129 said:
Those are not the default values, those are tuned values that both me and Flash have picked into our kernels.
EDIT: a few things
1. Not sure if you knew, but I found the sysfs controls for sched tunables in /proc/sys/kernel
2. I've started messing with voltages on my kernel and noticed a few things. On BIG cores, 302MHz and 633MHz use the same freq, so we can run min freq at 633 without any battery impact
Click to expand...
Click to collapse
I do know about the sysfs controls. #2 got my attention, but we need tests to prove that. Franco already knew it (I presume) because his big cores are set to 633mhz minimum. Still, I don't believe that voltages = battery because of the results on 5x's tests before. This is because I don't believe that same voltages have the same "bias" towards SoC cpu freq choice. To put it simply, if 633mhz has the same voltage as 302mhz, and I set min frequency to 302mhz and put delays and heavy target_loads on 633mhz, it still tends to stick to a different frequency much higher than that of 633mhz therefore I believe that each SoC has their own unique frequency "bias" (damn so hard to explain...).
HOWEVER, I have never tried nor attempted to put 633mhz to minimum frequency, I think it is best to try it out (will try it out )
Could you please check other frequency voltages as well? or have you done it already and only 302 and 633mhz on big cluster is the same?
phantom146 said:
I do know about the sysfs controls. #2 got my attention, but we need tests to prove that. Franco already knew it (I presume) because his big cores are set to 633mhz minimum. Still, I don't believe that voltages = battery because of the results on 5x's tests before. This is because I don't believe that same voltages have the same "bias" towards SoC cpu freq choice. To put it simply, if 633mhz has the same voltage as 302mhz, and I set min frequency to 302mhz and put delays and heavy target_loads on 633mhz, it still tends to stick to a different frequency much higher than that of 633mhz therefore I believe that each SoC has their own unique frequency "bias" (damn so hard to explain...).
HOWEVER, I have never tried nor attempted to put 633mhz to minimum frequency, I think it is best to try it out (will try it out )
Could you please check other frequency voltages as well? or have you done it already and only 302 and 633mhz on big cluster is the same?
Click to expand...
Click to collapse
I may be getting a little too physics-y here, but what you said makes sense. Frequencies with the same voltage can have different drains if they have different current. Voltage is equal to Joules (energy) per coulomb (unit of charge) and current is coulombs per second. So if current is higher, having the same voltage doesn't matter. I'll look into the kernel source and see if the frequencies have significantly different currents, but I doubt they do.
frap129 said:
I may be getting a little too physics-y here, but what you said makes sense. Frequencies with the same voltage can have different drains if they have different current. Voltage is equal to Joules (energy) per coulomb (unit of charge) and current is coulombs per second. So if current is higher, having the same voltage doesn't matter. I'll look into the kernel source and see if the frequencies have significantly different currents, but I doubt they do.
Click to expand...
Click to collapse
Please do and will be waiting for your answers. I will be testing it once you've got some useful data in here
phantom146 said:
Please do and will be waiting for your answers. I will be testing it once you've got some useful data in here
Click to expand...
Click to collapse
Turns out current varies core to core, not just cluster to cluster. You can find the values at https://github.com/frap129/angler/blob/dev/ng-mr2/arch/arm/boot/dts/qcom/msm8994.dtsi from line 79 to 388, but I'll shorten the info and post it below.
Code:
CPU0: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a53";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 24140 //384000 kHZ
27200 //460800 kHZ
32300 //600000 kHZ
36940 //672000 kHz
41570 //768000 kHZ
49870 //864000 kHZ
57840 //960000 kHZ
79800 //1248000 kHZ
88810 //1344000 kHZ
102400 //1478400 kHZ
110900>; //1555200 kHZ
};
CPU1: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a53";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 9415 //384000 kHZ
10608 //460800 kHZ
12597 //600000 kHZ
14407 //672000 kHz
16212 //768000 kHZ
19449 //864000 kHZ
22558 //960000 kHZ
31122 //1248000 kHZ
34636 //1344000 kHZ
39936 //1478400 kHZ
43251>; //1555200 kHZ
};
CPU2: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a53";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 9656 //384000 kHZ
10880 //460800 kHZ
12920 //600000 kHZ
14776 //672000 kHz
16628 //768000 kHZ
19948 //864000 kHZ
23136 //960000 kHZ
31920 //1248000 kHZ
35524 //1344000 kHZ
40960 //1478400 kHZ
44360>; //1555200 kHZ
};
CPU3: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a53";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 10139 //384000 kHZ
11424 //460800 kHZ
13566 //600000 kHZ
15515 //672000 kHz
17459 //768000 kHZ
20945 //864000 kHZ
24293 //960000 kHZ
33516 //1248000 kHZ
37300 //1344000 kHZ
43008 //1478400 kHZ
46578>; //1555200 kHZ
};
CPU4: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a57";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 86830 //384000 kHZ
103240 //480000 kHZ
129380 //633600 kHZ
155210 //768000 kHZ
177990 //864000 kHZ
195550 //960000 kHZ
265090 //1248000 kHZ
292770 //1344000 kHZ
322130 //1440000 kHZ
348190 //1536000 kHZ
370180 //1632000 kHZ
401551 //1728000 kHZ
437840 //1824000 kHZ
481070>; //1958400 kHZ
};
CPU5: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a57";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 50361 //384000 kHZ
59879 //480000 kHZ
75040 //633600 kHZ
90144 //768000 kHZ
103234 //864000 kHZ
113419 //960000 kHZ
153752 //1248000 kHZ
169807 //1344000 kHZ
186835 //1440000 kHZ
201950 //1536000 kHZ
214704 //1632000 kHZ
235196 //1728000 kHZ
253947 //1824000 kHZ
279021>; //1958400 kHZ
};
CPU6: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a57";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 59913 //384000 kHZ
71236 //480000 kHZ
89272 //633600 kHZ
107240 //768000 kHZ
122813 //864000 kHZ
134930 //960000 kHZ
182912 //1248000 kHZ
202011 //1344000 kHZ
222270 //1440000 kHZ
240251 //1536000 kHZ
255424 //1632000 kHZ
279802 //1728000 kHZ
302110 //1824000 kHZ
331938>; //1958400 kHZ
};
CPU7: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a57";
// The currents(uA) correspond to the frequencies in the
// frequency table.
current = < 62518 //384000 kHZ
74333 //480000 kHZ
93154 //633600 kHZ
111902 //768000 kHZ
128153 //864000 kHZ
140796 //960000 kHZ
190865 //1248000 kHZ
210794 //1344000 kHZ
231934 //1440000 kHZ
250697 //1536000 kHZ
266530 //1632000 kHZ
291967 //1728000 kHZ
315245 //1824000 kHZ
346370>; //1958400 kHZ
};
};
With this and the voltages (viewable in KA), you can calculate energy per second by multiplying voltage * current. Hopefully this is useful!
I know you understand laziness so I'm too lazy to make lots of different links in a pm so here are my results from using phase 3. I've had my phone all day and it's been in idle for a few hours now.
frap129 said:
With this and the voltages (viewable in KA), you can calculate energy per second by multiplying voltage * current. Hopefully this is useful!
Click to expand...
Click to collapse
Got ya there mate. Let me reflash everything and get back to clean slate and compute the numbers here, will post what I found out soon.
DEVILOPS 007 said:
I know you understand laziness so I'm too lazy to make lots of different links in a pm so here are my results from using phase 3. I've had my phone all day and it's been in idle for a few hours now.
Click to expand...
Click to collapse
You actually have pretty good stats tbh. The little cores are actually doing their job (being quite aggressive) and the big cluster is doing its slow boosts from your cpu frequency. Please do get back with a 100% battery reading tho, it is much better if I can see how you use your phone daily to see if there's something wrong.
Also, anyone here have problems with browser freezes lately? Angler runs really smooth, all apps are doing great but browsers (tried 3: yandex, canary and tuga) are doing freezes which Idk why.. Yandex has been really good but had to ditch it due to high foreground usage but canary and tuga has really the worst freezes (I imagine this might be a problem with chromium browsers?) Any thoughts are welcome.
EDIT:
@frap129 I will be providing you a data/excel sheet regarding all the computations and also its equivalent ma. If everything succeeds this would be legen..
phantom146 said:
If everything succeeds this would be legen..
Click to expand...
Click to collapse
Wait for it..
will you provide us with the profile later on ?
i am currently on the normal glasscannon profile, it is just okay i guess.
feels like most other profiles to me somehow ._.
i feel like at times they work and at times they dont.
frap129 said:
Wait for it..
Click to expand...
Click to collapse
Still waiting...
(Just got home from somewhere, will get to my desktop to compute as soon as I get some sleep, nighttime here)
leondestiny said:
will you provide us with the profile later on ?
i am currently on the normal glasscannon profile, it is just okay i guess.
feels like most other profiles to me somehow ._.
i feel like at times they work and at times they dont.
Click to expand...
Click to collapse
Yes of course, as of the moment its still a work in progress but dont worry I am pretty sure this will be a different profile as we are working on measuring watts(power drain from current and voltage) of each frequency together with @frap129. You guys just have to be patient
So this time its not just something about target_loads and other cpu related stuffs.. It is also about the accurate average of power consumption per frequency, and we will base the profile on that.
phantom146 said:
Still waiting...
(Just got home from somewhere, will get to my desktop to compute as soon as I get some sleep, nighttime here)
Yes of course, as of the moment its still a work in progress but dont worry I am pretty sure this will be a different profile as we are working on measuring watts(power drain from current and voltage) of each frequency together with @frap129. You guys just have to be patient
So this time its not just something about target_loads and other cpu related stuffs.. It is also about the accurate average of power consumption per frequency, and we will base the profile on that.
Click to expand...
Click to collapse
Real power consumption will fluctuate with load and other conditions, so the calculations can only give us rough estimates. What I'm hoping is that we'll find a quirk that could be beneficial, for example, finding that a certain frequency on the big cores is actually as/more power efficient than one on the little cores
Related
Alright, below this, I will include an almost full guide to setting up STweaks (for those who do not want to use the provided profiles)
The CPU section contains the frequencies and voltages that you want to run at.
200mHz is the minimum speed, 1800mHz is the maximum speed. You can change these to affect your overall performance or battery life. Mine is currently set to 200mHz minimum, 1800mHz maximum. I have seen no hit on battery life at all (might be miniscule.)
Now for the voltages.. Each and every person will have a different set of voltages, as every CPU will be a little bit different. You can manually set your frequency to a certain level, use a CPU stress testing app (stability test) and drop the voltage by SMALL increments until you start to lose stability (system crashes, app force closes, etc.) I usually go UP one voltage step over the borderline stable voltage. I will post my voltages, but take caution, as my voltages are set pretty low compared to stock values on the kernel.
1800mHz - set to 1200000 uV or 1.2 volts.
1704mHz - set to 1175000 uV or 1.175 volts.
1600mHz - set to 1112500 uV or 1.1125 volts.
1500mHz - set to 1100000 uV or 1.1 volts.
1400mHz - set to 1062500 uV or 1.0625 volts.
1300mHz - set to 1025000 uV or 1.025 volts.
1200mHz - set to 1000000 uV or 1 volt.
1100mHz - set to 975000 uV or 0.975 volts.
1000mHz - set to 962500 uV or 0.9625 volts.
900mHz - set to 937500 uV or 0.9375 volts.
800mHz - set to 912500 uV or 0.9125 volts.
700mHz - set to 887500 uV or 0.8875 volts.
600mHz - set to 862500 uV or 0.8625 volts.
500mHz - set to 837500 uV or 0.8375 volts.
400mHz - set to 812500 uV or 0.8125 volts.
300mHz - set to 800000 uV or 0.8 volts.
200mHz - set to 787500 uV or 0.7875 volts. * BE CAREFUL WITH THIS ONE, it can cause your device to lock up when the screen is off, and need a battery pull if the voltage is too low.
CPU Scaling Section - this controls how your device will turn up the speed when it needs to.
Governor - This contols how the device will respond overall (power management, sleep, etc.) I will keep mine set to the Pegasusq governor unless I am running a benchmark, in that case, use perfomance (which locks the device to full speed and all 4 cores online)
Sampling Rate - how often the device will 'think' about changing the CPU speed. I have mine set to 15000 uS (15 milliseconds) so it is more responsive.
Sampling Down Factor - This enables you to create 'lag' when the device is at full speed, so it doesn't jump down frequencies when you don't want it to. I leave mine at default 1 sample, because I see no need for this.
Up Threshold - When a core hits this % utilization at a set frequency, then it will scale up to the next frequency. I have mine set to 96%, so the device will scale up slower and more reliably (keep in mind it makes this decision every 15 milliseconds.)
Down Differential - When the device scales down, (drops frequency) it must get below this % utilization to scale down ( UP THRESHOLD minus DOWN DIFFERENTIAL ) I have mine set to 5%, so it drops frequency at or below 91% utilization.
Frequency for Responsiveness - This helps keep the device smooth at lower frequency, and when the frequency is below the set spot, it will use a DIFFERENT up threshold so the device scales up faster and doesn't lag. My frequency setting is 500mHz, and the up threshold for it is set at 70%.
Frequency for Fast Down - this sets the frequency at which the device can use aggressive down scaling, much like the opposite of frequency for responsiveness. I have mine set to 1400mHz, and the up threshold is set to 98%, so the device only scales up if it really needs to.
Frequency Step - This applies to the Fast Down setting, and whenever the device gets above 98% utilization, then it will increase the frequency by a SET percentage of the maximum frequency. So if you set 10%, and are have 1800mHz max, it will increase to the closest step that adds 180mHz. I have mine set to 6%, so it increases by 108mHz.
The up threshold and frequency step decrease confuse me for this, but I have the up threshold set to 2%, and the frequency step set to 3%.
I didn't touch the flexrate settings, as everything else should control this area.
CPU Hotplug - This section will control how the device turns its cores on and off.
CPU Up Rate - How many samples you want to take until a core decides to turn on. (Sampling rate times your setting) I have mine set to 12, so if the conditions are correct, it takes 180 milliseconds to turn a core on.
CPU Down Rate - How many samples you want to take until a core decides to turn off. (Same thing as CPU up rate) Mine is set to 10, so it takes 150 milliseconds to turn off a core if it isn't being used.
Core Upbring Count - How many cores you want to bring online when the conditions are right. Mine is set to 1, I'm sure more will increase performance and hurt battery life.
Configuration Overrides - These can set you device to always have a certain amount of cores online, I don't use them (leave at 0.)
Hotplug Conditionals - These perameters are set to control when the cores turn on and off. Below are MY values
Hotplug 1 Core to ONLINE (make 2 cores online) - 600mHz
Hotplug 2 Cores to OFFLINE (make 1 core online) - 500mHz
Hotplug 2 Cores to ONLINE (make 3 cores online) - 700mHz
Hotplug 3 Cores to OFFLINE (make 2 cores online) - 600mHz
Hotplug 3 Cores to ONLINE (make 4 cores online) - 800mHz
Hotplug 4 Cores to OFFLINE (make 3 cores online) - 700mHz
The rest of this section, I left at DEFAULT values, because I did not understand them.
GPU - This section controls the frequencies and voltages of your GPU.
Maximum Frequency - How high you want your GPU to clock to, mine is set to 733mHz.
Minimum Frequency - How low you want your GPU to clock to, mine is set to 108mHz.
Up Threshold - Like the CPU setting, the percentage of utilization you achieve before the GPU scales up. Mine is set to 90%.
Down Differential - When you want your GPU to scale down lower, (Up threshold minus down differential.) Mine is set to 10%, so when the GPU hits 80% utilization on a speed, it drops to a lower frequency.
Utilization Timeout - Basically is the sampling speed of the GPU (how fast you want it to make decisions to change speed.) Mine is set to 25 milliseconds.
Voltages - Test these the same way as the CPU, get a GPU stress testing app, and set a certain frequency. When you see artifacts or glitches on your screen, then the voltages are too low. Below are MY values.
54mHz - 825mV
108mHz - 875mV
160mHz - 950mV
266mHz - 975mV
350mHz - 1050mV
440mHz - 1100mV
533mHz - 1125mV
640mHz - 1150mV
733mHz - 1175mV
800mHz - 1200mV (This clock speed proved to be slightly unstable at 1175mV, though still usable)
I/O section - These values/settings control how your device writes/reads things from the SD card, or internal storage.
I left both of my storage schedulers at ROW but you can change them and play around. I believe that deadline is the best for overall performance, but can be unstable sometimes.
I/O Read Ahead - These control the cache file on the internal/external storage. I have my internal set to 1536kB, and external set to 2048kB, because those values gave me overall good write/read speeds.
Dynamic Fsync - From what I know, this helps keep the data from being corrupted by creating a buffer between data being written and the storage. Correct me if I'm wrong. I kept it enabled.
The entire audio section is pretty self explanatory, and I'm getting tired of typing all of this, so if you need help, PM me or comment.
Again, take this entire post with caution. What works with my device, may make yours unstable. I only provided mine to give you a baseline, my values offer good performance and battery life anyways. Feel free to correct any of my errors by PM or comment, and I will gladly change my post to accommodate for my errors.
Here's my more performance oriented settings. Averages 19500 on Antutu, and 7400 on Quadrant Standard (Advanced version adds 1000 to score) This doesn't lag at all between screens, animations, etc. The only lag I've seen is when my apps rarely crash.
CPU Max - 1800mHz
CPU Min - 200mHz
Voltages from OP
Pegasusq governor
Sampling Rate - 15000uS
Sampling Down Factor - 1
Up Threshold - 90%
Down Differential - 10%
Frequency for Responsiveness - 600mHz
Up Threshold @ Min Freq - 60%
Frequency at Fast Down - 1400mHz
Up Threshold at Fast Down - 94%
Frequency Step - 25%
Up Threshold Differential - 5%
Frequency Step Decrease - 10%
Flexrate Enabled - 700mHz, 10000uS
CPU Up Rate - 8 samples
CPU Down Rate - 10 samples
Core Upbring Count - 1
*Default Configuration Overrides*
1 Core to Online - 300mHz
2 Cores to Offline - 200mHz
2 Cores to Online - 400mHz
3 Cores to Offline - 300mHz
3 Cores to Online - 500mHz
4 Cores to Offline - 400mHz
*Runqueue Depths*
1 Core to Online - 155
2 Cores to Offline - 155
2 Cores to Online - 250
3 Cores to Offline - 250
3 Cores to Online - 340
4 Cores to Offline - 340
CPU Online Load Bias - 2 cores
CPU Online Bias Up Threshold - 50%
CPU Online Bias Down Threshold - 30%
GPU Max - 733mHz
GPU Min - 160mHz
Up Threshold - 85%
Down Differential - 5%
Utilization Timeout - 25ms
Voltages from OP
Internal/SD Card Schedulers - SIO
Internal/SD Card Read Ahead - 2048kB
Dynamic FSync - Enabled
Hi,
how can I be sure the cpu hoptplug section is turned on?
gannjunior said:
Hi,
how can I be sure the cpu hoptplug section is turned on?
Click to expand...
Click to collapse
The governor, Pegasusq, does the hotplugging. So it's on by default when selecting it. I don't know if it applies to Performance too.
EDIT: Please share the performance oriented profile! What do you mean you need help posting it? You should have reserved another post. But I'm definitely interested!
Thanks for the info OP.
DroidOnRoids said:
The governor, Pegasusq, does the hotplugging. So it's on by default when selecting it. I don't know if it applies to Performance too.
EDIT: Please share the performance oriented profile! What do you mean you need help posting it? You should have reserved another post. But I'm definitely interested!
Click to expand...
Click to collapse
I don't know how to create a flashable zip. I can just post the settings later.
I left my phone unplugged overnight, only lost 2% battery. So it's good with battery too.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my SCH-I605 using xda premium
Here ya go: [GUIDE] How to make a cwm recovery flashable zip
DroidOnRoids said:
Here ya go: [GUIDE] How to make a cwm recovery flashable zip
Click to expand...
Click to collapse
Thanks. I'll set one up as soon as I get my new computer (Monday) I'll just post my settings in the 2nd comment.
Sent from my SCH-I605 using xda premium
ChaoticWeaponry said:
Thanks. I'll set one up as soon as I get my new computer (Monday) I'll just post my settings in the 2nd comment.
Sent from my SCH-I605 using xda premium
Click to expand...
Click to collapse
I appreciate the performance settings! Really notice a difference!
I'm just going to bump this. People should take a look at this! You did a really good job with it!
Ive been using your Performance profileall week and loving it! Great work
I have also had very good luck with the OPs settings.
I didn't think my phone would even handle voltage settings this low, but it's been perfectly stable for the past 2 days.
ChaoticWeaponry said:
Here's my more performance oriented settings. Averages 19500 on Antutu, and 7400 on Quadrant Standard (Advanced version adds 1000 to score) This doesn't lag at all between screens, animations, etc. The only lag I've seen is when my apps rarely crash.
CPU Max - 1800mHz
CPU Min - 200mHz
Voltages from OP
Pegasusq governor
Sampling Rate - 15000uS
Sampling Down Factor - 1
Up Threshold - 90%
Down Differential - 10%
Frequency for Responsiveness - 600mHz
Up Threshold @ Min Freq - 60%
Frequency at Fast Down - 1400mHz
Up Threshold at Fast Down - 94%
Frequency Step - 25%
Up Threshold Differential - 5%
Frequency Step Decrease - 10%
Flexrate Enabled - 700mHz, 10000uS
CPU Up Rate - 8 samples
CPU Down Rate - 10 samples
Core Upbring Count - 1
*Default Configuration Overrides*
1 Core to Online - 300mHz
2 Cores to Offline - 200mHz
2 Cores to Online - 400mHz
3 Cores to Offline - 300mHz
3 Cores to Online - 500mHz
4 Cores to Offline - 400mHz
*Runqueue Depths*
1 Core to Online - 155
2 Cores to Offline - 155
2 Cores to Online - 250
3 Cores to Offline - 250
3 Cores to Online - 340
4 Cores to Offline - 340
CPU Online Load Bias - 2 cores
CPU Online Bias Up Threshold - 50%
CPU Online Bias Down Threshold - 30%
GPU Max - 733mHz
GPU Min - 160mHz
Up Threshold - 85%
Down Differential - 5%
Utilization Timeout - 25ms
Voltages from OP
Internal/SD Card Schedulers - SIO
Internal/SD Card Read Ahead - 2048kB
Dynamic FSync - Enabled
Click to expand...
Click to collapse
Are your settings similar to any of the flashable profiles listed under Perseus kernel?
GermanGuy said:
Are your settings similar to any of the flashable profiles listed under Perseus kernel?
Click to expand...
Click to collapse
Somewhat. I edited most of the settings.
Sent from my SCH-I605 using xda premium
This gave me the perfect reason to use multi window, no wonder why this phone doesn't have a dedicated recents button!! Looking forward to testing this.
Sent from my SCH-I605 using Tapatalk 2
jsminnis said:
This gave me the perfect reason to use multi window, no wonder why this phone doesn't have a dedicated recents button!! Looking forward to testing this.
Sent from my SCH-I605 using Tapatalk 2
Click to expand...
Click to collapse
Omg bro lmao I just noticed what you meant about the multi window wow I totally forgot about that lmao I just finished setting up these settings but my dumb ass wrote all those settings from the OP to 2 pieces of paper wow what a retarded move I just pulled ha ha ha.
Sent from my SPH-L900 using Tapatalk 2
yellowman82 said:
Omg bro lmao I just noticed what you meant about the multi window wow I totally forgot about that lmao I just finished setting up these settings but my dumb ass wrote all those settings from the OP to 2 pieces of paper wow what a retarded move I just pulled ha ha ha.
Sent from my SPH-L900 using Tapatalk 2
Click to expand...
Click to collapse
Lmao, i dreamed of situations like these when I knew I was getting this phone.
Anyway, about the settings. I recommend not setting on boot till you've had the screen of for awhile. I got a boot loop, most likely from the voltage settings so I will play with those some more.
Tip: If you get a bootloop, instead of pulling the battery just wait for when the phone restarts then press and hold vol up, home and power to go to recovery. I do this rather than taking the back off and risking breaking the little clips like I did on my nexus.
Sent from my SCH-I605 using Tapatalk 2
jsminnis said:
Lmao, i dreamed of situations like these when I knew I was getting this phone.
Anyway, about the settings. I recommend not setting on boot till you've had the screen of for awhile. I got a boot loop, most likely from the voltage settings so I will play with those some more.
Tip: If you get a bootloop, instead of pulling the battery just wait for when the phone restarts then press and hold vol up, home and power to go to recovery. I do this rather than taking the back off and risking breaking the little clips like I did on my nexus.
Sent from my SCH-I605 using Tapatalk 2
Click to expand...
Click to collapse
Thanks for the tip but instead of a bootloop my phone just frozed so I had to do a battery pull and about the voltages you have to increase back up a bit when playing with them right?
Sent from my SPH-L900 using Tapatalk 2
yellowman82 said:
Thanks for the tip but instead of a bootloop my phone just frozed so I had to do a battery pull and about the voltages you have to increase back up a bit when playing with them right?
Sent from my SPH-L900 using Tapatalk 2
Click to expand...
Click to collapse
Yes. Crashes are usually from too low of voltages. Go up a step or two from my settings.
Sent from my SCH-I605 using xda premium
thanks for the tweak using it now, very fast.
Hi XDA'lers,
I think it would be interesting to collect some stats on the undervolting capabilities of our mantas. Hopefully it helps others who also intend to save some energy by doing this. If you want to participate, please post your lowest possible settings exactly like this:
CPU:
Code:
% MHz= [ 100, 200, 300, 400, 500, 600, 700, 800, 900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100];
BR
900, 900, 900, 900, 900, 912, 925, 950, 962, 987,1012,1037,1075,1100,1137,1187,1225,1250,1275,1300,1325; % [email protected]_kernel_name_and_version (hotplugging_state)
% BR
GPU:
Code:
% MHz= [ 100, 160, 266, 350, 400, 450, 533, 612, 667, 720];
BR
900, 900, 925,1000,1050,1100,1150,1200,1250,1300; % [email protected]_kernel_name_and_version
% BR
... and don't forget to replace the default mV values in the third line by your own ones. Please write your username, kernel, and hotplugging state where indicated.
You can find out whether hotplug is enabled or not, if you have a look at your governor adjustments, or watch the state of the second core when idle (for example in the KTweakerT app).
~ Rules ~
Each CPU value should run stable for at least 30 minutes under stress-testing conditions. (Use some tool like for example the "Classic Stability Test" within the app "StabilityTest", or "SetCPU".) Don't use HD videos or something like that for stress testing, they are a joke to our CPU. :laugh:
If you don't adjust certain values, like for example CPU frequencies above 1700 MHz: Do not write '0'. Please leave it at the default value.
Be honest. We love you for your personality, not your Android. (If you want to submit anonymously, you can write me a PM as well.)
Don't let your kernel config app set test values on boot. :silly:
Your settings should not impair the usability of your device at all. (Crashes upon governor scaling for example.)
GPU voltages can sometimes be set below device minimum, however, we want to collect values that allow an unimpaired experience with no graphical glitches at all.
If you want to copy values from others, be aware that their best settings are not the best for you. Every Nexus 10 is different, and there is the risk that some voltage is unstable on your system. If it works anyway, you save power by applying the settings, but chances are that you could find even more efficient values! To maintain statistical significance, please do not post settings that you copied from someone else.
~ CPU Release 2013-04-29 ~
~ GPU Release 2013-04-29 ~
Top: A graph that estimates the total amount of dissipated power. Beware of the horizontal line, as it is the highest value that Samsung and Google have designated. Here you can see, how undervolting and overclocking can combine to higher performance without higher heat emission (with Enigma's Crème de la Crème Preset up to 1900MHz CPU clock). This way you actually can safely overclock the CPU. (pingguo is not responsible for any damages on devices other than his own. They are in perfect condition, though. I'm just saying this because everyone does.)
On the left, you can see the differences between the default voltages and custom values.
The right side indicates the power consumption compared to default values. This might be the most important graph!
Source: http://en.wikipedia.org/wiki/CPU_power_dissipation
Matlab-Sourcecode, for the enthusiasts:
Code:
ping = [ 100, 200, 300, 400, 500, 600, 700, 800, 900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100];
guo = [ 900, 900, 900, 900, 900, 912, 925, 950, 962, 987,1012,1037,1075,1100,1137,1187,1225,1250,1275,1300,1325; % DEFAULT
800, 800, 825, 850, 875, 875, 900, 900, 925, 950, 975,1000,1025,1050,1075,1100,1125,1160,1200,1250,1290; % Butterlicious, Margarine 2013-04-24
750, 750, 775, 800, 825, 825, 850, 850, 875, 900, 925, 950, 975,1000,1025,1050,1075,1110,1150,1200,1240; % Crème de la crème 2013-04-24
785, 785, 785, 785, 785, 790, 795, 815, 835, 865, 890, 915, 955, 985,1015,1055,1095,1125,1165,1205,1325; % PINGGUO
% 760, 760, 760, 760, 760, 765, 770, 790, 810, 840, 865, 890, 930, 960, 990,1030,1070,1125,1165,1205,1325; % PINGGUO-AGGRESSIVE
];
ref = ones(length(guo(:,1)),1)*guo(1,:);
pingg= ones(length(guo(:,1)),1)*ping;
hvhf = ones(1,length(ping)) *1700*1225^2; % max. f*V^2 with default settings
subplot(2,1,1);
plot(ping,[pingg.*guo.^2;hvhf]);
axis([ping(1),ping(length(ping)),0,4E9]); % set Y limit so that it looks nice
xlabel('Frequency / MHz');
ylabel('f * V^2 ~ Power Consumption (Arbitrary Units)');
title('Total Power Consumption; Horizontal Line = Maximum with DEFAULTS');
subplot(2,2,3);
plot(ping,guo-ref);
axis([ping(1),ping(length(ping)),-200,20]); % adjust Y range if necessary
xlabel('Frequency / MHz');
ylabel('Voltage Offset (V - V_{DEFAULT}) / mV');
title('Nexus 10 CPU Undervolting: Voltages');
grid;
subplot(2,2,4);
plot(ping,(guo./ref).^2*100);
axis([ping(1),ping(length(ping)),0,110]);
legend('DEFAULTS (KTManta-04-19-2013)','PRESETS Butterlicious, Margarine (EniGmA1987)','PRESET Crème de la crème (EniGmA1987)','[email protected] (Hotplugging OFF)','Location','SouthEast');
xlabel('Frequency / MHz');
ylabel('(V / V_{DEFAULT}) ^2 ~ Power Consumption (Percentage)');
title('Relative Power Consumption');
grid;
Most of this ugly piece of code works automatically for everything, just write into the matrices and check the lines with commentaries. :silly:
Cheers,
苹果
Bus overclocking is not something the user controls, the kernel sets that. The previous 3 versions of the KTmanta kernel all have a 25% bus overclock, Trinity also has this same thing. But the latest version of KTManta does not have a bus overclock. So people need to specify which kernel version they are on so that everyone knows what features it has.
EniGmA1987 said:
Bus overclocking is not something the user controls, the kernel sets that. The previous 3 versions of the KTmanta kernel all have a 25% bus overclock, Trinity also has this same thing. But the latest version of KTManta does not have a bus overclock. So people need to specify which kernel version they are on so that everyone knows what features it has.
Click to expand...
Click to collapse
Thanks for the comment, I updated the code template.:good:
Preview online, just to let you know what I intended.
Currently I am trying to fix the sleep of death that my Nexus 10 is suffering from... Advice would be highly appreciated.
(It does not wake up when I press the power button after some screen off time. Only a hard reset brings it back to life.)
Edit: I am not yet sure about it, but seemingly, the problem does not occur when I use a governor which keeps both cores running at all times...
pingguo said:
Preview online, just to let you know what I intended.
Currently I am trying to fix the sleep of death that my Nexus 10 is suffering from... Advice would be highly appreciated.
(It does not wake up when I press the power button after some screen off time. Only a hard reset brings it back to life.)
Edit: I am not yet sure about it, but seemingly, the problem does not occur when I use a governor which keeps both cores running at all times...
Click to expand...
Click to collapse
Are you using the KTmanta kernel? If you have hotplugging enabled and you undervolt too much, sleep of death will occur.
For me, I have to raise my minimum voltage to 830 with hotplugging enabled to prevent sleep of death.
If I have hotplugging disabled, I could undervolt way low than that
c19932 said:
Are you using the KTmanta kernel? If you have hotplugging enabled and you undervolt too much, sleep of death will occur.
For me, I have to raise my minimum voltage to 830 with hotplugging enabled to prevent sleep of death.
If I have hotplugging disabled, I could undervolt way low than that
Click to expand...
Click to collapse
Yup, I'm on KTManta. Also, hotplugging seems to be exactly the reason for my SODs.
Now the big question is: What is more efficient - Hotplugging and thus saving 50% of the power, or stronger undervolting, saving 25%, and maybe more effective racing to idle with both cores?
BTW, are you implying that hotplugging is always performed at the lowest possible frequency?
Edit: There is still one thing that puzzles me: Hotplugging while the screen is on works perfectly fine at the voltages which cause the SOD...
pingguo said:
YWhat is more efficient - Hotplugging and thus saving 50% of the power, or stronger undervolting, saving 25%, and maybe more effective racing to idle with both cores?
Click to expand...
Click to collapse
Hotplugging doesn't save 50%. The theory of it does but actual execution that is not even close to possible. It saves 2-3% battery
This may seem like a very noob question, but I am running the nightly builds of CM10.1 and I just installed the KTmanta kernel but I don't see where to change any governor settings. Is it an app I need to install? Help?
EniGmA1987 said:
Hotplugging doesn't save 50%. The theory of it does but actual execution that is not even close to possible. It saves 2-3% battery
Click to expand...
Click to collapse
Well, then I feel very comfortable with undervolting only. :laugh:
parakalien said:
This may seem like a very noob question, but I am running the nightly builds of CM10.1 and I just installed the KTmanta kernel but I don't see where to change any governor settings. Is it an app I need to install? Help?
Click to expand...
Click to collapse
Install the KTweakerT app from the kernel forum thread.
Updated the CPU graph with some overclocking data. Please let me know whether or not it is true that OC with no increase in heat emission is safe.
Update:
Graphs should be more comprehensible and informative.
Added full source code for you source lovers.
Cheers!
pingguo said:
Updated the CPU graph with some overclocking data. Please let me know whether or not it is true that OC with no increase in heat emission is safe.
Click to expand...
Click to collapse
The three most damaging things to a processor are: amperage, voltage, and heat. Heat is tricky, because every processor has a maximum heat limit it is designed for. The more heat you have the less life your processor will have. However, if you stay within its maximum heat limitations then the processor will still last many many years, as soon as you get above that heat limit you start damaging the processor extensively, greatly lowering its lifetime and possibly causing irreparable damage in that you can no longer run at the higher core speeds stably anymore. So you always want to stay within heat limitations, preferably as cool as you can.
Amperage is also highly damaging to processor silicon, but thankfully we dont really control this up or down on most processors. One good example of this can be seen with RAM, which you can control amperage on. The best example here is RAS to RAS timings, which is when the RAM chips get pulsed with large amounts of amperage. It has been many many years since I looked into the technical details of this, but I *think* this happens when a row of addresses is pre-charged before access or something like that. Normally this happens every 4-6 cycles on average. Many people in order to increase stability of their RAM overclocks would lower this, I even did some stuff for a while with a setting of 1 for this timing. Because of low values on this timing the RAM is getting pulsed with large amounts of amperage quite frequently and this was causing massive degradation of the cell structure and creating micro-holes in the silicon. These holes then in turn require more amperage to remain stable at your MHz speed in order to overcome the damage, and with the higher amperage needed you continue to accelerate the damage. It is just a snowball effect of damage to the RAM chips that leads to complete death of the chip in a few months. This was why you saw large failure rates on DDR2 RAM at one point "back in the day" when D9GKX and GMH chips were all the rage. So all that to say, large amperage is bad for computer chips.
Next up is voltage, which we do control. More voltage is needed for high MHz speeds as we need to make the transistors switch faster and have more power to give in order to achieve higher speeds. Higher voltage leads to greatly increased heat output, greatly increased battery drain, and also if you are using voltage above the chip's specifications causes damage to the processor itself. Lowering voltage is the best thing we can do to keep our processors running at their best. A tiny decrease in voltage will often be 1-2 degrees cooler in temperature, and usually means a few less watts as well (depends on chip architecture). Just last week I was overclocking an Intel i7-3930K processor. I had fun playing around with it and observing the changes happening. I observed with 1.4v and 4.5GHz core speed than power draw was 198 watts under 100% load. Going to 4.6GHz raised power draw up to a nice even 200 watts (2 watts more for 100 MHz). I then went back down to 4.5GHz speed and increased the voltage from 1.4v to 1.42v, and saw a temperature increase of 4-5 degrees on all the cores and a 6-7 watt power consumption increase. Just from raising the voltage that little bit.
So the best thing we can do for our tablets is to undervolt. But when overclocking, as long as you stay within the chip's voltage limits and heat limits, the extra core speed doesnt really affect the chip's lifetime at all, until you get many MANY MHz ahead of its design. if you can overclock up an extra 300MHz while still dropping voltage a bit you will see both a reduction in power consumption (even with the extra speed) and a reduction in heat. Although these reductions will not be as much since we are also generating small bits more of power draw and heat from the higher speeds too.
TL;DR
overclocking is fine and wont damage your processor as long as you remain at the same or less voltage and heat output.
Searched a lot of posts but cannot find any useful post (-25 mv or -50 mv) for LG G2 so decided to make my own UNDERVOLTING TABLE
Why undervolting is important?
With rising freq needs more voltage and more voltage makes device hot
If tempature stays a little bit lower and not rising fastly device will be use high frequencies with low tempatures(according to old frequency tempature)
It can stays old tempature with high frequency!
It means more smooth user interface and less laggy gaming performance
(not lower tempature on high pressure but lower when regular use)
Under high pressure (gaming or benchmak test) device frozed so I rised voltage a little bit for stability.
v 4 BETA
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Applied with dorimanx kernel v4.6
I will be honest with you; it's not efficient undervolting table because of heating (Waiting for next kernel or use v4..2 with v3 undervolting table)
Adjusted for performance profile and as you can see 1.04 GHz is nearly undervolted -5 mV.
You can change % and build your own undervoltage table.
Kernel settings
MASTER CORE
4 x Intellimm
Touch boost: DISABLED
CPU Freq: 2.5 (or optionally 2.4)
Max screen off freq: 1.04 GHz
THERMAL CONTROLS
CPU Temp Control: Intelligent temp control only
Temp Pull Timer: 200 ms
Hotplug Thermal CPU Control: Enabled
Max Online CPU's: ALL CORES ON
INTELLI CORE MAX HEAT: 76
See frequencies real time with Trepn Profiler and CPU tempature
Found a tool to undervoltage instead of 2 applications
Download Kernel Toolkit from google play
Here is how you can set voltages
v 3
Tested for 2 days (Dorimanx kernel v4.2)
v2 not freezing but rebooting so changed undervoltage values about %5 for safety.
Update: Tested a lot of combinations but v3 is the best for now.
Added 2.4 GHz for performance, you can use optionally but I recommanded using 2.4 GHz It makes phone very smooth without heating and draining battery. Use yellow mV table when you apply.
Recommended Kernel Settings
4 x intellimm
Touchboost: Disabled
CPU TEMP CONTROL: Intelligent Temp Control Only
Hotplug thermal control: Enabled
Max Online CPUS : Core 0,1,2 (3 cores)
Hotplug Driver: Intelligent Hot Plug
v 2
Used percentage instead of iteration.
After hours testing table v2 more stable, gives more performance and less laggy
Under high load on cpu with gaming CPU stays 68-71 C and can't see any "big" lag just micro lags (tested with Real Racing 3 and Sky Force)
Cores stays 1.5 GHz on Sky Force and 1.2 GHz on Real Racing 3
Changed Max Online CPUS 2 to 3
Tried also 4 cores but best is 3 for smoth
v 1
Finding the correct value is hard for a first timer here is values:
Tested for 3 days some voltages mekes device laggy or frozen (Tested with Trepn Profiler for frozen Cpu frequencies)
Tested with LG G2 D802 (v1.2) Dorimanx lollipop kernel (v 4.2)
Most setting fits with your phone with these settings
But what happens if you want to make your own UNDERVOLTAGE TABLE ?!
There are two situations:
1. Mostly frozen on while you set the voltage so we know which freq needs more voltage
2. Sudden freze and you don't know which freq causes? Use Trepn Profiler; it shows every time which cpu core on which freq
If your device frozen you can know (or you can suspect) (Makes a little bit laggy. At highest tempature cores will be stay same frequency and you can close trepn and see not lagging results while testing)
Let me know how it works for your device :fingers-crossed:
I've found that -40mv was the best for me. Except on the lower speeds, in which I went just a little bit lower. I put everything -40 across the board and then I'd bring the 300MHz down to 0.7v and the two frequencies higher would be slightly higher than 0.7v. Sometimes I'll even set the 2nd step to the same as the first. The furthest I'd go with lowering values even further is the 4th step.
If you want clarification, I can give it to you. Oh, keep in mind, my CPU was given a bin rating of 4, so I'm a bit better off than average. http://forum.xda-developers.com/showthread.php?t=2489998
tehbigbug said:
I've found that -40mv was the best for me. Except on the lower speeds, in which I went just a little bit lower. I put everything -40 across the board and then I'd bring the 300MHz down to 0.7v and the two frequencies higher would be slightly higher than 0.7v. Sometimes I'll even set the 2nd step to the same as the first. The furthest I'd go with lowering values even further is the 4th step.
If you want clarification, I can give it to you. Oh, keep in mind, my CPU was given a bin rating of 4, so I'm a bit better off than average. http://forum.xda-developers.com/showthread.php?t=2489998
Click to expand...
Click to collapse
I know every device has different processor but I don't know that kinf of classification Thanks
Mine PVS bin 2 and speed rating 2.3 GHz
Step-by-step undervolting good idea I did it firstly then I make an iteration Really obsessed I know.
Most default values makes graph linear so I follow this way and find max and min frequency voltages then found values between these voltage values.
Tested on high pressure and adjust a little bit.
Hi,
thanks for pushing the kernel and phone tuning even further.
My phone is PVS bin 2 too.
I tried a more simple approach. I had "A1 CPU Tool" installed already and checked the most used frequencies. So I started modifying those in the first place (-25mv)
I am curious if it will have any day by day measurable effect.
And last but not least, if the phone will remain stable.
Sent from my LG-D802 using XDA Free mobile app
silent_silver said:
Hi,
thanks for pushing the kernel and phone tuning even further.
My phone is PVS bin 2 too.
I tried a more simple approach. I had "A1 CPU Tool" installed already and checked the most used frequencies. So I started modifying those in the first place (-25mv)
I am curious if it will have any day by day measurable effect.
And last but not least, if the phone will remain stable.
Sent from my LG-D802 using XDA Free mobile app
Click to expand...
Click to collapse
Trepn Profiler shows real time while you testing the undervolting settings when device frozen it helps to find which frequency
If A1 CPU Tool usable then use it but I recommanded If you follow my way
Testing testing testing and already had 2 freze [Solved with v2]
If I can lock on a frequency I will test all of them and compare "CPU load"
Thanks for this! So far it's stable for me, and especially the Phone is not that warm now
tryman87 said:
Thanks for this! So far it's stable for me, and especially the Phone is not that warm now
Click to expand...
Click to collapse
When screen off more reduced tempature but while gaming will be heating the same
Check out v3, it would be more stable
lynxrz said:
When screen off more reduced tempature but while gaming will be heating the same
Check out v3, it would be more stable
Click to expand...
Click to collapse
I'm a bit confused with the v3 graph, which one should i follow? There's the yellow, green and brown.
tryman87 said:
I'm a bit confused with the v3 graph, which one should i follow? There's the yellow, green and brown.
Click to expand...
Click to collapse
Follow yellow one, forgot to note down
I'm adding to post now.
Thanks for your attention
nice guide!!
i found out that my CPU can stay stable at -45-40mvs
i did some manual undervolting such as 300mhz at 700mv
on the other hand at 1200-1700mhz range i kept the -45mv undervolt as i had some freezes with -50mvs (still a work in progress)
kernel:dorimanx 4.2 ,default profile ,no touchboost ,ondemand guvernor
CPU bin: 3
testing done with:vellamo / day to day usage + trepn profiler
No need for lame programs with Dorimanx kernel. Here is 4.4.2 example:
Code:
[B]# get vdd table:[/B]
cat /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
[B]# we can decrease all values...[/B]
echo "-25000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
[B] # ... or just one value we need:[/B]
echo "2419200 975000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
And 5.0.2 example:
Code:
[B]# get vdd table:[/B]
cat /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
[B]# we can recalibrate all settings here from min to max frequencies...[/B]
echo "750 760 770 780 790 800 810 820 840 860 880 900 920 950 1000 1020 1060 1090 1120" > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
After some testing you just add modded values to init.d script. Profit!
GK_222 said:
No need for lame programs with Dorimanx kernel. Here is example:
Code:
[B]# get vdd table:[/B]
cat /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
[B]# we can decrease all values...[/B]
echo "-25000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
[B] # ... or just one value we need:[/B]
echo "2419200 975000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
After some testing you just add modded values to init.d script. Profit!
Click to expand...
Click to collapse
If I can build a init.d script I'll add this (probably in next version) thanks for info :good:
bogdy5 said:
nice guide!!
i found out that my CPU can stay stable at -45-40mvs
i did some manual undervolting such as 300mhz at 700mv
on the other hand at 1200-1700mhz range i kept the -45mv undervolt as i had some freezes with -50mvs (still a work in progress)
kernel:dorimanx 4.2 ,default profile ,no touchboost ,ondemand guvernor
CPU bin: 3
testing done with:vellamo / day to day usage + trepn profiler
Click to expand...
Click to collapse
Thanks
Try to change % in v4 Freq table
Usage of cpu depends on your governor and carefully watch cores frequencies, yes ALL of them in the same time
Mostly high frequencies not used because of heating and these frequencies has more flexible undervoltages BUT sometimes high frequencies cause freze at cold stuations (mostly seen while waking up the device) so using % helps a lot.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Revamped Advanced Interactive Governor Tweaks
This thread was originally made by Corndude which for some apparent reason, decided to delete his account. The task to update this thread is then passed on to @The Flash but unfortunately because the purple person is busy atm, I stole it from him. So I will try to keep this up to date with informations and everything about the interactive governor. I will also add helpful descriptions on each parameters just to help people who are into tweaking and give them a little push to start tinkering.
The original thread made by SoniCron can be found here: Advanced Interactive Governor Tweaks for the 5X
Helpful Links
Linux Documentation - CpuFreq
Most Up-to-date guide on CPU Governors by @Saber
Table of Contents
Download Section
Applications that Allow Kernel Profiles Setup
Diving Deep into Interactive Governor
Interactive Tweaks Explained
timer_slack: The amount of time in miliseconds; that the cpu will stay in the highest frequency before it applies "interactive" tunings again. Basically, if there is a cpu intensive application and you have a high cpu load; timer_slack delays ramping down to lower frequencies in a given "X" time. Also, since timer_rate will be erratic, this should help to decrease stutters.
(higher value: higher battery drain, better performance)
timer_rate: The amount of time in miliseconds; that the cpu will check how heavy the cpu load is. E.g. if you have set this to 20000, it'll compute every 20ms to see if any changes on the cpu load is making and will therefore adjust the frequency based on target_loads.
(higher value: less battery drain, performance impact subjective)
target_loads: The amount of load, in theory on percentage; where the actual frequency should be used. Target_loads can be setup per frequency to provide certain "bias" on cpu clocks. An example "35 475600:88 600000:21 960000:98" means that anything before 475Mhz would have a target load of 35%. At 475Mhz before ramping up there should be at least 88% of cpu load, once this threshold is broken it'll ramp up to 960Mhz immediately since 600Mhz is set less than 475Mhz. Therefore the two "bias" created on the sample above is 475Mhz and 960Mhz. It is not recommended to provide any values higher than 98 as this will reduce performance on your cat greatly.
(higher value: less battery drain, worse performance)
min_sample_time: The minimum amount of time the governor must wait at a given frequency until it can decide to reduce the frequency.
(higher value: better performance, battery impact HIGHLY subjective)
hispeed_freq: This would be the frequency that the user "assumes" would be enough to handle a boost in cpu load. Too high value would greatly impact the user's UI performance but would definitely worsen the battery life.
(higher value: higher battery drain, better performance)
go_hispeed_load: The load assigned to the cpu where it is recommended to go to the hispeed_freq. Set this quite high as this bypass almost everything in the interactive tunables.
(higher value: less battery drain, performance impact subjective)
above_hispeed_delay: A delay setup in frequency:miliseconds to slow down and "delay" aggressive ramp ups. E.g. 19000 600000:24000; provides 19ms delay to cpu frequencies not specified after reaching hispeed_frequency, before ramping up to a higher frequency. If, for example you have your hispeed_frequency set up to 960Mhz, and your above hispeed_delay to 30000 1248000:22000 1354000:40000; the 30ms will only be used at 960Mhz up until 1248Mhz where the delay is 22000. Please note that 30000(30ms) from the example above will NOT BE APPLIED to all frequencies BELOW the set hispeed_frequency (anything below 960Mhz). Also, specified "frequency:delay" ratios should be written in ascending order according to cpufreq linux documentations.
(higher value: less battery drain, worse performance)
align_windows: With the value of "1" for On and "0" for Off. If "1" is designated, the cluster for cpu clocks (divided into big and little) will fire at short quick intervals, usually by 1ms to provide a reliable boost to what timer_rate has converted cpu loads/clocks into.
(If ON: better performance)
max_freq_hysteresis: Checks the cpu for "hysteresis" or previous cpu clock records and base the next ramp up on frequencies previously used. If your cpu tends to have a bias towards lower cpu clocks, with this on a high value; it should frequently stick to lower cpu frequencies.
(higher value: less battery drain, performance impact subjective)
powersave_bias: Value of "1" to turn ON and "0" for OFF. If your cpu decides to go for 960mhz, with powersave_bias ON it'll go to a frequency one step below 960mhz.
(turn ON: less battery drain, worse performance)
use_migration_notif: Value of "1" for ON and "0" for OFF. Reevaluate the cpu frequency if "notified" (unclear, we can assume this as either an unschedule app notification or a "timed" boost) to fire in 1ms. This aids timer_rate in quick changes with system loads.
(turn ON: better performance, battery impact subjective)
ignore_hispeed_on_notif: Value of "1" for ON and "0" for OFF. Ignores the hispeed_load, hispeed_frequency and above_hispeed_delay once a cpu is "notified". Therefore, if a cpu is "notified" if this is set to "1" the cpu can ramp up to frequencies computed by timer_rate without any delays coming from hispeed frequency logic.
(turn ON: heavy battery drain)
fast_ramp_down: Value of "1" for ON and "0" for OFF. Ignores min_sample_time which provides delay on cpu frequencies in miliseconds. This holds true ONLY if a cpu is "notified" and therefore avoids unreliable "bias" on certain clocks due to quick shift of cpu loads.
(turn ON: less battery drain, performance impact HIGHLY subjective)
I highly encourage people to tweak their interactive governors on their respective kernels as this highly amounts to bettery performance and battery life. With that said, this concludes a simple revamp of this thread and I hope more and more people within the angler community would be interested to tinker. Imagine the possibilities!
CREDITS TO:
@The Flash - for letting me steal his thread because he slow af.
@soniCron - the main contributor for all of this, I don't know if he still exists.
Corndude - dude
@shadowstep - for being a good friend though he "mistakenly" killed his angler *retarded screeching*
@Saber - for providing the Most-up-to-date CPU frequency guide
@frap129 - for being really awesome and providing the community fraps.
And to EVERYONE that has made all this possible, I give the sun to you!
Download Links
Profile Download Links
Profiles by Alcolawl from @Alcolawl[/b]
[*]Profiles by Xsilas43 from @Xsilas43[/b]
[*]Profiles by .hEimDaLL from @.hEimDaLL
[*]Wingoku Profile from @fapste
[*]GlassCannon from @phantom146
[*]EXkm Profiles from @xperator
[*]Project Zhana OP3 Port from @deani77
Apps that Allows Kernel Profile Setups
Apps that Allows Profile Setups
Exkernel Manager App by @flar2
Spectrum Kernel Manager by @frap129
Kernel Profiler by @frap129
Diving Deep into Interactive Governor
Diving Deep into the Interactive WorldUnderstanding how parameters co-exist and the OP's viewpoint regarding cpufreq.
The interactive governor has been around for years and is without a doubt the most popular cpugov present in the linux archives. The development of this linux-based core has been ongoing, patches and evolutions to interactivex has been widely appreciated by android enthusiasts and non-enthusiasts alike. Interactive governor is also without a doubt, the majority baseline for new governors being developed which goes to prove that it is one of the most efficient and optimal cpugov within the world of android fanboys.
Before we start, take a look at this graphic thingy:
There is no such thing as a "perfect" balance. I myself, live by a code to never ever let my phone slow down just for the sake of bragging that I got this SoT *autistic screeching*. If you have to choose between the two of those, I would wholeheartedly suggest to finish tasks first (yielding better performance) than just idle in despair looking at your battery percentage the whole day. Lastly, please do bring a powerbank with you.
Enough with this, let's talk facts:
I will be breaking down the parameters here, how they should co-exist with other parameters and what you should change in order to provide a smoother experience. We will also be digging deeper as to how each parameters should help you with your daily usage. Let's begin.
Hispeed_Frequency Logic:
The hispeed logic is what makes your angler boost, not gradually; but burst through the set optimal load you deemed necessary for task completion. We consider this very important as this provide the overall smoothness, task completion time and if used properly along with other parameters; may yield to better battery.
hispeed_frequency: This is the bread and butter of the interactive governor. What makes interactive unique to others is the user can set a specific frequency "bias", where he/she finds it optimal(according to usage). When paired with input_boost, this significantly increases responsiveness and smoothness to overall android feel. Personally, I would never recommend to set hispeed_frequency to the lowest cpu clock e.g. 384mhz because it will defeat its purpose of "burst" boosts. In the past, many users attempted to set hispeed_frequency to the lowest clock to prevent sudden scaling from cpu frequencies however, in turn, they have to sacrifice the responsiveness of the device A LOT. If you want to still try it, I'll bet my scrotums again that switching between apps and opening your angler coming from deep sleep/doze without a fingerprint_boost (featured in Flash kernel and Electron) would stutter and cause you to at least lag for a second.
From tests, my best recommendations for a hispeed_frequency are:
600/634mhz - If you are a typical light user, opens your device to read a lot of stuffs about growing back your pubes and ruining the timeline, like barry. Whenever you are switching from a light app (reddit, 9gag, fb) to a heavy app such as Youtube, you should experience a slight stutter but you could still live.
960mhz - Good enough to balance almost everything. From light users to heavy users, this should be optimal. Personally never experienced jitters coming from hispeed_frequenciy set to this (except with really low timer_rate).
1248mhz - Fast and extremely reliable but unfortunately should give you a little more drain. On the flipside tho, it is the default input_boost/hispeed_freq from interactive itself as well as other variations of the governor. If you use heavy apps a lot such as games and likes switching stuffs a lot, stick to this.
Anything above 1248mhz I would really not recommend. Coming from personal tests, It does run phenomenal but it is too much of a waste. That performance isn't worth the battery expended so with all due respect just stick to a lower frequency.
go_hispeed_load: Provides the desired load from 0-X depending on the user's preference. This bypasses your set target loads from below your hispeed frequency e.g. if your hispeed_freq is set to 960 mhz, anything under 960 mhz is bypassed whenever the "assigned" load threshold you input in this parameter is reached. Meaning, even if you set 302mhz as 999 on your target loads, whenever your timer_rate computes a load that has at least reached to your assigned go_hispeed_load it should automatically ramp up to your hispeed_frequency. However, this does not mean you can abuse the power of your target_load. Setting your target_load too high below your hispeed_freq would still give you lags especially if your timer_rate is above 50000. Just a tip: you can make this to 0 if your input_boost is set to your hispeed_freq.
input_boost: Technically not part of the interactive parameters but still worth the mention as this copies the hispeed_frequency logic and helps maintaining boosts. The input_boosts increases your frequency to the assigned value whenever a task is loaded in your device. This does not work like touchboost as touchboost is a nuclear waiting to explode. Input_boosts scales even if your screen is off (but rarely) and wouldn't increase your phone's clocks whenever you touch it (boop boop). Rather, it only boosts your device whenever necessary (e.g. IO overheads, task completion, downloads, alarms syncing).
If you really like the most optimal performance your cat can achieve, aim to put input_boost the same as your hispeed_frequency values'. It should not waste too much battery and should still be controlled by above_hispeed_delay.
Controlling your Hispeed_Frequency:
There are only two parameters that can actually control your hispeed_frequency scaling namely go_hispeed_load (mentioned above) and above_hispeed_delay. However, a third one which is quite special; ignore_hispeed_on_notif can also impact at how the governor performs, let's dig in to it:
above_hispeed_delay: Is a "delay" timer in miliseconds set by the user with the format "Initial delay, frequency:delay miliseconds". The intiial delay is applied to all frequencies EQUAL TO OR ABOVE the hispeed_frequency, whilst the frequency:delay ratio is applied per specific frequencies again EQUAL TO OR ABOVE the set hispeed_freq. E.g. if you set your hispeed_frequency to 960mhz, and you have set your above_hispeed_delay to (X 384000:Y 600000:Z 960000:M), Your X value would be aligned to all frequencies above 960mhz (since you specified a delay in 960mhz) whilst your Y and Z is IGNORED, because you're retarded short-sighted enough to not read what I and the linux archives just said.
I personally, do not recommend hispeed_delay to be above 35000 unless you're eager to "suspend" or provide "bias" on a specific frequency. This is because I find 35000 and anything above that to be too long for a delay and should provide you nothing but lags and would just piss you off instead of providing a better battery. If you do want to suspend a cpu clock make sure that it is efficient enough (e.g. 1248mhz or above) to handle heavy loads.
ignore_hispeed_on_notif: Turn on by input of "1" and must have use_migration_notif to "1" also otherwise it won't work. The ignore_hispeed_on_notif (damn that's long) as the name puts it; ignores the hispeed logic, meaning your above_hispeed_delay and go_hispeed_load is ignored whenever the hrtimer (a special timer) coming from use_migration_notif triggers. This usually yields better performance but at the cost of a huge battery drain, since hrtimers also trigger on deep sleep, therefore; most likely, your cpu would scale up even though you think there's no task happening in the background. I do not recommend turning this on, please do not, you kennot.
The Caviar of Target Loads:
The most sought to parameter in the interactive kernel is the target_loads. Along with hispeed_frequency, target_loads is another parameter that makes the interactive governor the most flexible, controllable and probably battery-friendly cpugov. You can adjust this to function as a performance-like governor, a powersave or even imitate how conservative governor gradualy boosts. Below, you will see tons of explanations and what criticisms I personally got about target_loads:
target_loads: Computes the load per frequency ratio, in the format of "X 600000:Y 960000:Z" and so on, depending on the users' perceptive usage. Where X, is the initial load given to all frequencies below the first specified frequency:ratio stated (therefore in the example, anything below 600mhz), and Y/Z are loads given to specific cpu clocks. The target_loads unlike above_hispeed_delay, isn't linear. You can start off with a high frequency ratio of 384000:88 then go down to 487600:22 and get back up to 90 at 600mhz. Because of the latter, you can provide "bias" on certain frequencies you deem to be fast enough to handle specific loads.
Just a heads-up. I do not believe in optimal and nominal frequencies. I think those were just bullshified terms that was made so people would have something to bias the loads to. The optimal frequency should be your "preferred" frequency. There is no 960mhz when watching youtube nor the specific frequency for just reading webpages at 600mhz. There are certain apps that are relies on heavy foreground (e.g. whatsapp and snapchat) or sometimes even fb, and if you're gonna stick to 600mhz because somebody told you its the optimal frequency for users that just reads, you can kiss my grandma. Everything differs, a good android enthusiast should and will explore what frequency they think their usage fits. It's just that simple.
Before trying to input random numbers on your target load, try to see what your perceptive usage is. If you would like your device to stay on lower frequencies as much as possible, put a value between 75-92 on clocks below your hispeed_frequency. Anything above that might lead to stutters depending on your min_sample_time and timer_rate.
Provide higher load thresholds on your hispeed_frequency and above. Since you have set your hispeed_freq to be the most optimal cpu clock all-around your dynamic loads, provide a higher threshold to it (e.g. 90 and above) so your kernel will bias to it more unless heavy loads are on play.
Put a value of 98-99 to frequencies you deem to be the most efficient on heavy loads. I personally like 1248mhz a lot and therefore use it as my cpufreq for heavy loads. Setting your load to 99, rarely makes your frequency go higher than the specified cpu clock, whilst setting it to 98 is decent enough to gradually let frequencies ramp up from it.
An important note. You can create certain "bias" towards cpu clocks as I have stated above, target_loads aren't linear and therefore, frequencies you deemed to be slow enough to handle cpu stressmay be given less priority. This is done by providing any loads below 50. E.g. 384000:75 487600:22 600000:88 672000:35 960000:95 by using the example given, your cpu clocks should bias towards 384mhz, 600mhz and 960mhz respectedly, eliminating the need for 487mhz and 672mhz. We do this to provide better responsiveness for our cats and I personally recommend trying this until you find your sweet spot.
Providing the Delays of Responsiveness:
Delays aren't only used to slow down the ramp up of your cpu clocks. They are also used to delay things such as the given time of each cpu frequencies before ramping down. Because of this control, the interactive governor provides a better all-around smoothness than any other governors out there, combined with your target_loads and hispeed_frequency; fluidity should never be an issue!
min_sample_time: If above_hispeed_delay provides a delay before the cpu scales up, min_sample_time is the other way around. Min_sample_time is a timer in miliseconds with X0000 format, used as a delay for all cpu clocks per cluster, before it ramps down, assisted by computations coming from timer_rate. As one of the core parameters in android to provide fluidity universally, this parameter could be swapped for input_boost delay and providing a higher timer for this with lower timer_rate, in my own experience; provides you the capability to totally negate input_boost.
Experiment on this one as this is very subjective. I do suggest that if you have a high timer_rate , provide a higher min_sample_time value or else your kernel won't be as responsive as you would like it to be.
timer_slack: to assist timer_rate to provide a stable and constant performance track, timer_slack in miliseconds, provides a delay on the highest frequency of the governor. Because timer_rate especially if below 40000, computes the frequency of the current load given to the cores, min_sample_time aids to slow down timer_rate's aggressive approach to either ramp up/ramp down the frequency. An example of this is moving to another app from one foreground to another, if timer_rate has been set low enough that it computes the switching to provide a higher frequency then within 20ms to ramp down because the load has settled down, timer_slack prevents this from happening, and thus should create responsiveness to our devices. This again is highly subjective. Play on its values depending on your needs, most developers or interactive enthusiasts use -1 to prevent timer_slack from delaying the high frequency which provides a better battery life.
Underrated Parameter; the Timer Rate:
timer_rate: is probably the most undervalued and underrated parameter there is in the interactive governor. Most governors have this parameter and is rarely, I mean rarely! appreciated. You have to change that notion starting now. Timer_rate provides things two ways. Lower value equates to faster response and performance while higher value provides longer battery life. Of course the latter means you'll be sacrificing your device's fluidity.
The default timer_rate is 20000. This means that every 20ms, your governor will compute the loads burdened to your kernel and timer_rate will provide the signals to target_loads to adjust depending on the values given.
An "efficient" timer_rate clocks in between 20000 and 40000. By my own tests, anything above 40000 slows down the "frequent" change of cpu clocks. As a proof, you can check your kernel manager's dashboard and set your timer_rate higher than 40000; you will notice that it won't be jumping from one frequency to another too much.
A high timer_rate could still be efficient given that you have a high min_sample_time and a reasonable timer_slack. This three holy trinity, when tweaked properly, should give you better performance without the significant drop of battery life for our angler.
The Special Parameters:
There's a (3)three parameters that I would like to call special. This is because they can be turned off and wouldn't cause any significant changes to the interactive governor and from the fact that they need use_migration_notif turned ON to function. Also, just a quick mention, during my long tests; I find some of these parameters intrusive so I wouldn't really recommend them turned ON unless you are willing to experiment on things.
use_migration_notif: can be turned on with the value of "1". This is the core switch for fast_ramp_down and ignore_hispeed_on_notif (please see hispeed logic for description) to work. With this on, migration timers also known as hrtimers (see Hrtimers - Linux Archive for spot-on description) are allowed to be computed as a "load". This can be comparable to ignore_nice_load from other governors however, unlike the latter, use_migration_notif needs to be turned on to work. To summarize, with hrtimers computed as loads, this should provide more gradual boosting than before, especially that hrtimers for linux kernels are made to "optimize timer-wheel" but the battery impact is highly subjective. Also, hrtimers may fire while on deepsleep, though it won't break doze, this would increase your cpu frequency as it is computed as a positive load from your kernel and should therefore drain a little more battery, especially when you have ignore_hispeed_on_notif set to 1.
fast_ramp_down: can be turned on by setting value to "1". This simply ignores min_sample_time for hrtimers and therefore should provide you better battery life. Whenever your cpu clocks ramps up due to hrtimer, min_sample_time would delay the cpu frequency before going down but with fast_ramp_down if the load computed by your kernel is indeed an hrtimer, it'll ignore min_sample_time value and proceed to ramp down the frequency in 1ms.
Turning the three: use_migration_notif, ignore_hispeed_on_notif and fast_ramp_down ON is something that I would never recommend, unless you're experimenting, doing your own tweaks or holding on to your dear life. There is no way we can accurately measure this three unlike the other parameters provided, also; hrtimers are being patched from one kernel to another and is being updated constantly, I am pretty sure in the future we would be taking advantage on that parameter soon.
This is great, I've been following this work in the Nexus 5X forum and I've got to say this is a great way to fine tune and optimize our 6P.
Edit. I'm currently on the maddog profile and experiencing excellent performance and superb batter life, 630 sot avr.
Second this. Been following on the 5x page as well and was using Ghostpepper until earlier today. For me ghostpepper got me the best SoT(5hrs)with average usage (mainly whatsapp, Facebook mobile site, instagram, Spotify and some GPS usage with it on high accuracy). Now using Butterfly and so far performance is outstanding, excited to see what the battery life will be. Huge thanks to @soniCron for the work!
moraytadroidz said:
This is great, I've been following this work in the Nexus 5X forum and I've got to say this is a great way to fine tune and optimize our 6P.
Edit. I'm currently on the maddog profile and experiencing excellent performance and superb batter life, 630 sot avr.
Click to expand...
Click to collapse
Any info on what is the best for battery life? Don't really care about performance, it's fine on stock imo. So far I have not noticed any difference in battery life between this and stock.
Glad there is a separate thread for these tweaks on the Nexus 6P. I'll continue to update that post with the newest scripts for this device, but always remember that I CANNOT test the scripts for the Nexus 6P because ai simply don't own the phone. Progress and updating scripts will heavily rely on testing and feedback from participants in this thread. This is paramount, as its difficult to maintain scripts for a device I don'tactually have access to. Please make sure to either mention me or PM me when giving feedback on the scripts I've uploaded.
Thanks again, @Corndude!
Alcolawl said:
Glad there is a separate thread for these tweaks on the Nexus 6P. I'll continue to update that post with the newest scripts for this device, but always remember that I CANNOT test the scripts for the Nexus 6P because ai simply don't own the phone. Progress and updating scripts will heavily rely on testing and feedback from participants in this thread. This is paramount, as its difficult to maintain scripts for a device I don'tactually have access to. Please make sure to either mention me or PM me when giving feedback on the scripts I've uploaded.
Thanks again, @Corndude!
Click to expand...
Click to collapse
Thank you. Glad to have you checking on this thread as well!
I'm not sure it's necessary to copy the text to each of the posts verbatim... I'd suggest linking to the original posts and then add on 6P-specific info (such as frequency ranges, voltage levels, etc) so as to not overwhelm your users. (I also recommend this because the OP guide on the 5X forum is going to get a full rewrite incorporating everything we've learned thus far, sooner than later.)
I have no problem with you duplicating the text, mind you. I just think it might be better for your users if you linked rather than duplicated. (Especially if it's not updated with the 6P in mind.)
I'll try to keep track of this thread for a while, but if anyone urgently wants my attention, PM me.
Great work, guys!
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
shawnaye said:
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
So far people are mainly using it on Elemental X and Kylo. Butterfly has been working great for me on Elemental
Franco works just as well. It's only important that you can disable touchboost.
shawnaye said:
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
I use franco on Pure Nexus, and under the franco app I turn the performance to power saving. No hiccups or lag on anytjing I do and I score 7+ hours SOT every charge
+1 on thread! Test it yourself.. I've had great success on GhostPepper.
Evolution101 said:
So far people are mainly using it on Elemental X and Kylo. Butterfly has been working great for me on Elemental
Click to expand...
Click to collapse
I must have my wires crossed. Thought I read that Butterfly required Kylo kernel as ElementalX has no Intellactive governor?
nadiros said:
I must have my wires crossed. Thought I read that Butterfly required Kylo kernel as ElementalX has no Intellactive governor?
Click to expand...
Click to collapse
I think you might be thinking of the Redhawk alpha. Butterfly is for the interactive governor
Gytole said:
I use franco on Pure Nexus, and under the franco app I turn the performance to power saving. No hiccups or lag on anytjing I do and I score 7+ hours SOT every charge
Click to expand...
Click to collapse
Really ? Gonna give that a go!
Thanks for starting this thread
I'm finding ghoststepper to be very smooth - butterfly was certainly a sipper but slightly less smooth for me I think.
@Corndude Glad to see this here, too - I've been following the OP on the N5X forum since soniCron posted it.
One suggestion: maybe put "[WIP]" or "Work In Progress" at the start of the thread title as I know the 6P is having less than desirable results in comparison to the huge benefits they're seeing on the 5X & it would be a shame if people were put off by bad reviews/comments of the tweaks before we (as a community) can stabilise the settings to give great battery life without affecting the performance at all.
I know GhostPepper is very close to getting there (6.5-7.25 hrs SOT for me), but I still think we can squeeze much more out of this theory - I mean, we have a much larger battery with the same software specs, so we should technically be able so squeeze at least another 1/2 hours SOT out of the 6P if 5X users can get 8/9hrs SOT.
ps. just a heads up - your "head on down to the 2nd post" in the OP links to the 5X OP & the OP also includes 5X frequencies - these should probably be swapped out of the 6P frequencies, otherwise people might try inputting them to their 6P's (which will result in target_loads not saving)
edit: 6P Maximal/Minimal loads for OP.
CPU #1 Maximal Efficient Loads
384000:75
460000:69
600000:80
672000:79
768000:80
864000:81
960000:69
1248000:84
1344000:82
1478000:86
1555000:0
CPU #1 Minimal Efficient Loads
460000:20
600000:30
672000:12
768000:14
864000:13
960000:11
1248000:30
1344000:8
1478000:10
1555000:5
CPU #2 Maximal Efficient Loads
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:84
1344000:84
1440000:84
1536000:85
1632000:85
1728000:85
1824000:84
CPU #2 Minimal Efficient Loads
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1728000:6
1824000:6
1958000:7
For you gamers out there
Finally I solved the thermal throttling problem in this lovely device.
BEWARE **YOUR PHONE WILL HEAT MORE**
first using your root explorer go to system/etc, you will find 3 files related to thermal throttling:
1. thermal-engine-8996-normal.conf
2. thermal-engine-8996-perf.conf
3. thermal-engine.conf
These files related to the configuration in the settings->power manager->power plan.
If you chose performance then your phone will use the perf.conf
If you chose Smart power-save your phone will use normal.conf
Edit:
After further investigation it seems that no matter what setting I choose the file that is active always the normal.conf.
perf.conf seems not affecting anything at all. Needs futher investigation.
That is the mechanic, now for the fun part:
Open the file you wish to edit using text editor.
The key is in these two sections
Code:
[SKIN_CPU_MONITOR]
#algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 59000 62000
thresholds_clr 56000 60000
actions cluster0+cluster1 cluster0+cluster1
action_info 1400000+1700000 1500000+1824000
override 5000
[SKIN_GPU_MONITOR]
#algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 41000 42000
thresholds_clr 39000 40000
actions gpu gpu
action_info 510000000 401800000
override 5000
As you can see the values above are a little bit different from yours, it's because I already change a bit.
The parts you should take consideration are thresholds, thresholds_clr, actions, and action_info.
Thresholds means in what temperature the device should throttle
Thresholds_clr means in what temperature the device will stop throttling
Actions mean which item to be throttled
Cluster0 = Little CPU
Cluster1 = Big CPU
GPU = GPU
so for example above
thresholds 59000
thresholds_clr 56000
actions cluster0+cluster1
action_info 1400000+1700000
Means it will start throttling at 59 celcius and stop throttling at56 celcius, the item to be throttled are little CPU which become 1400 mhz and big CPU which become 1700 mhz
You can add many parameters just by using spaces like example above.
Okay, hope it helps. If you confuse, just use my values above and unleash the 60fps beast. Muahahaha
Edit:
This is my current setting
Code:
[SKIN_CPU_MONITOR]
#algo_type monitor
sampling 1000
sensor tsens_tz_sensor11
thresholds 48000 50000
thresholds_clr 45000 49000
actions cluster0+cluster1 cluster0+cluster1
action_info 1500000+1824000 1400000+1700000
override 5000
Instead of emmc thermostat I use tsens_tz_sensor11 which is the temperature of the CPU core itself, I think it is better
Finally someone make magisk module for this (thanks nfsmw_gr), not yet tried it myself though
https://forum.xda-developers.com/showpost.php?p=76793058&postcount=14
I've already moved on to stock b01 oreo rom, now it is located in /system/vendor/etc/thermal-engine.conf
Here is my current config
Code:
[SKIN_CHG_LIMIT]
algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 39000 41000
thresholds_clr 38000 40000
actions battery battery
action_info 1 2
[SKIN_CPU_MONITOR_NORMAL]
algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 36000 39000 42000
thresholds_clr 35000 38000 41000
actions cluster0+cluster1 cluster0+cluster1 cluster0+cluster1
action_info 1500000+1824000 1400000+1700000 1300000+1438000
override 5000
[SKIN_GPU_MONITOR_NORMAL]
algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 41000 42000
thresholds_clr 39000 40000
actions gpu gpu
action_info 510000000 401800000
override 5000
Thank you so much.
Is this valid for destroying the phone without voiding the warranty?
aLexzkter said:
Is this valid for destroying the phone without voiding the warranty?
Click to expand...
Click to collapse
Lol, I'm pretty sure there's a failsafe for temps
You'd probably want to also undervolt if you are removing thermal throttling to give yourself a little more headroom. Hellsgate kernel supports undervolting
Been doing similar for months and mentioned about it a few times in various places.
I don't think using the CPU temperature sensor is suitable for throttling as it peaks largely and fluctuates rapidly with corresponding load. The reason emmc_therm (quiet_therm in AOSP ROMs) is probably used for a suitable consistent reading. The related default temperature throttles need to be adjusted to reflect the changed sensor and it's nature. What will happen on your config is sudden throttling on CPU load that will unthrottle rapidly when load is decreased but the battery/device isn't likely any cooler.
Btw on AOSP I can't get any changes to stay after rebooting with disemmcwp system writable too. I'm guessing the kernel or something regenerates the defined values at startup. I found having the file modified through a Magisk module works however.
Sent from my Xperia Z3C using XDA Labs
I know this sounds super lazy but can this possibly be made into a magisk module for convenience for and for ease of enabling/disabling
dalebaxter01 said:
I know this sounds super lazy but can this possibly be made into a magisk module for convenience for and for ease of enabling/disabling
Click to expand...
Click to collapse
I would like this as well if it's not much hassle.
dalebaxter01 said:
I know this sounds super lazy but can this possibly be made into a magisk module for convenience for and for ease of enabling/disabling
Click to expand...
Click to collapse
put your changed file into this template https://forum.xda-developers.com/mi-5/how-to/how-to-disable-thermal-throttling-t3636574
Infy_AsiX said:
Been doing similar for months and mentioned about it a few times in various places.
I don't think using the CPU temperature sensor is suitable for throttling as it peaks largely and fluctuates rapidly with corresponding load. The reason emmc_therm (quiet_therm in AOSP ROMs) is probably used for a suitable consistent reading. The related default temperature throttles need to be adjusted to reflect the changed sensor and it's nature. What will happen on your config is sudden throttling on CPU load that will unthrottle rapidly when load is decreased but the battery/device isn't likely any cooler.
Btw on AOSP I can't get any changes to stay after rebooting with disemmcwp system writable too. I'm guessing the kernel or something regenerates the defined values at startup. I found having the file modified through a Magisk module works however.
Sent from my Xperia Z3C using XDA Labs
Click to expand...
Click to collapse
Yeah, this is also what I found. At first I just looked at which temp is the highest and use that sensor for the trigger. But then when I use cpu-z to observe the reading, I found that emmc_therm is the most consistent and not fluctuate drastically so much. Therefore I'm back using emmc_therm right now
Seeing this thread gives me flashback in the Android M days where a xposed module was needed to disable a system task killer that would kill my games if they used too much battery once I turn off screen _-_
Never again will I use my phone gaming while overheating message comes up.
It almost killed my phone, not turning on and charging. I had to disassemble the phone and remove the battery to make it charge again.
otaconremo said:
Never again will I use my phone gaming while overheating message comes up.
It almost killed my phone, not turning on and charging. I had to disassemble the phone and remove the battery to make it charge again.
Click to expand...
Click to collapse
You should always keep your eyes on the temp. My rule of thumb is under 55 degree is ok, above that is no no. If your games always reach above 55 then you should re-tweak your thermal config.
Use dev check pro to observe the temp, though it doesn't have widget for emmc_therm only the cpu therm, you can still see what's going on under the screen
Okay, so after reading through the comments I made a magisk module for myself to test, using the template from the Mi 5 thread.
I modified all 3 files to be sure it works (my device boots so yeah, try it and let me know).
Also made a copy of the modded files at /system/etc to cover all scenarios because in the ROM I run the files are located in /system/vendor/etc, not in /system/etc as in the OP .
It shouldn't affect anything I think.
Anyway without stalling you'll find the file attached at the bottom, as always you flash at your own risk, have a nice day!
(P.S. If this is ok I'll put it on my thread with my Jojoc mod.)
otaconremo said:
Never again will I use my phone gaming while overheating message comes up.
It almost killed my phone, not turning on and charging. I had to disassemble the phone and remove the battery to make it charge again.
Click to expand...
Click to collapse
No idea how you got that. I've never seen a overheating message on stock N or RR-O. I've gotten the device to overheat shutdown plenty of times after increasing the secondary CPU throttle (hasn't been described here) from 95degC to 105degC. Even on fan with enough load at maximum frequencies the CPU temp can spike to the presumedly 120degC Qualcomm shutdown (dropping one step on big cores is fine). This secondary throttle behaves differently by interrupting performance and unthrottling rapidly. Still boots fine after. I've yet to try if undervolting will allow that final big frequency step, on fan, increased to 105degC, no secondary throttle and no shutdowm.
I'd guess instead your battery voltage dropped too severely low being old degraded and too high a current draw, requiring a reset of the battery PCB or something.
iyancoolbgt said:
You should always keep your eyes on the temp. My rule of thumb is under 55 degree is ok, above that is no no. If your games always reach above 55 then you should re-tweak your thermal config.
Use dev check pro to observe the temp, though it doesn't have widget for emmc_therm only the cpu therm, you can still see what's going on under the screen
Click to expand...
Click to collapse
55 isn't high at all for a CPU. You mean floating monitor overlay? It can select two custom temperatures to show on the dashboard and float monitor. The only real concern is battery temp. Other components are designed and rated to handle high temperatures. FWIW I've been running around 100degC CPU, keeping battery <50degC on fan with battery voltage limited to 3.85V for several months playing various high end games at maximum performance without notable ill effect. Well except that constant heat on the battery even at the safe low voltage will cause degradation, unavoidable cost for higher performance on a phone.
nfsmw_gr said:
Okay, so after reading through the comments I made a magisk module for myself to test, using the template from the Mi 5 thread.
I modified all 3 files to be sure it works (my device boots so yeah, try it and let me know).
Also made a copy of the modded files at /system/etc to cover all scenarios because in the ROM I run the files are located in /system/vendor/etc, not in /system/etc as in the OP .
It shouldn't affect anything I think.
Anyway without stalling you'll find the file attached at the bottom, as always you flash at your own risk, have a nice day!
(P.S. If this is ok I'll put it on my thread with my Jojoc mod.)
Click to expand...
Click to collapse
That location sounds like how it was when I tried AEX-O. Don't know if anything's changed there but no files could affect ROM thermal throttling on it then. The files there are different too, maybe generic Sd820 config or something, whereas RR-O uses the same sensors, values and config as stock N. I did also try the stock config modded to AEX but still no go. The only file with effect where it works is the -normal.conf.
Infy_AsiX said:
No idea how you got that. I've never seen a overheating message on stock N or RR-O. I've gotten the device to overheat shutdown plenty of times after increasing the secondary CPU throttle (hasn't been described here) from 95degC to 105degC. Even on fan with enough load at maximum frequencies the CPU temp can spike to the presumedly 120degC Qualcomm shutdown (dropping one step on big cores is fine). This secondary throttle behaves differently by interrupting performance and unthrottling rapidly. Still boots fine after. I've yet to try if undervolting will allow that final big frequency step, on fan, increased to 105degC, no secondary throttle and no shutdowm.
I'd guess instead your battery voltage dropped too severely low being old degraded and too high a current draw, requiring a reset of the battery PCB or something.
55 isn't high at all for a CPU. You mean floating monitor overlay? It can select two custom temperatures to show on the dashboard and float monitor. The only real concern is battery temp. Other components are designed and rated to handle high temperatures. FWIW I've been running around 100degC CPU, keeping battery <50degC on fan with battery voltage limited to 3.85V for several months playing various high end games at maximum performance without notable ill effect. Well except that constant heat on the battery even at the safe low voltage will cause degradation, unavoidable cost for higher performance on a phone.
That location sounds like how it was when I tried AEX-O. Don't know if anything's changed there but no files could affect ROM thermal throttling on it then. The files there are different too, maybe generic Sd820 config or something, whereas RR-O uses the same sensors, values and config as stock N. I did also try the stock config modded to AEX but still no go. The only file with effect where it works is the -normal.conf.
Click to expand...
Click to collapse
Mind sharing your own config?
Infy_AsiX said:
No idea how you got that. I've never seen a overheating message on stock N or RR-O. I've gotten the device to overheat shutdown plenty of times after increasing the secondary CPU throttle (hasn't been described here) from 95degC to 105degC. Even on fan with enough load at maximum frequencies the CPU temp can spike to the presumedly 120degC Qualcomm shutdown (dropping one step on big cores is fine). This secondary throttle behaves differently by interrupting performance and unthrottling rapidly. Still boots fine after. I've yet to try if undervolting will allow that final big frequency step, on fan, increased to 105degC, no secondary throttle and no shutdowm.
I'd guess instead your battery voltage dropped too severely low being old degraded and too high a current draw, requiring a reset of the battery PCB or something.
55 isn't high at all for a CPU. You mean floating monitor overlay? It can select two custom temperatures to show on the dashboard and float monitor. The only real concern is battery temp. Other components are designed and rated to handle high temperatures. FWIW I've been running around 100degC CPU, keeping battery <50degC on fan with battery voltage limited to 3.85V for several months playing various high end games at maximum performance without notable ill effect. Well except that constant heat on the battery even at the safe low voltage will cause degradation, unavoidable cost for higher performance on a phone.
That location sounds like how it was when I tried AEX-O. Don't know if anything's changed there but no files could affect ROM thermal throttling on it then. The files there are different too, maybe generic Sd820 config or something, whereas RR-O uses the same sensors, values and config as stock N. I did also try the stock config modded to AEX but still no go. The only file with effect where it works is the -normal.conf.
Click to expand...
Click to collapse
I believe my battery is too degraded already. That only happens when my batt is below 20% and I was still gaming. That's why I'm very careful already when I'm getting lowbat. Btw, I'm using stock chinese mf5 version. The overheating message is from the Mi-Assistant app (Power Manager).
nfsmw_gr said:
Mind sharing your own config?
Click to expand...
Click to collapse
I did awhile back but I guess it's a little scattered across posts. I was about to edit in another paragraph with more info but I'll put it here now instead. I'll consider cleaning up the new stuff to share, performance profiles is just a varied collection of performance levels.
I've setup various CPU GPU performance profiles to switch between using Tasker. From testing, the highest I'd go without a fan is 1600/1800 big and 1300 small. With a constant load at these frequencies the battery will still hit up to around 50degC, matching the much higher perf allowed with a fan.
Here's a tidbit to get y'all thinking about environmental impact on heat. Stock Daydream sets a Sustainable Performance mode that uses all cores at 1200MHz. In the Daydream Headset V1, the back of the phone actually has an air gap behind it because of raised nubs inside the headset. Yet with all this the battery can rather easily heat to over 55degC after a few dozen minutes. The headset v2 has a built in heatsink, with minor improvement apparently. Also on an off-topic note, that Sustained Performance mode gets stuck to on after using Daydream on stock N. Things no one notices unless you actually monitor
---------- Post added at 10:12 PM ---------- Previous post was at 10:09 PM ----------
otaconremo said:
I believe my battery is too degraded already. That only happens when my batt is below 20% and I was still gaming. That's why I'm very careful already when I'm getting lowbat. Btw, I'm using stock chinese mf5 version. The overheating message is from the Mi-Assistant app (Power Manager).
Click to expand...
Click to collapse
Yeah sounds like my guess about an undervolted degraded battery. Oh I had that frozen so never got that alert. I'd assume it occurs when battery is 55degC or so, that's when Daydream alerts too for example.
Infy_AsiX said:
No idea how you got that. I've never seen a overheating message on stock N or RR-O. I've gotten the device to overheat shutdown plenty of times after increasing the secondary CPU throttle (hasn't been described here) from 95degC to 105degC. Even on fan with enough load at maximum frequencies the CPU temp can spike to the presumedly 120degC Qualcomm shutdown (dropping one step on big cores is fine). This secondary throttle behaves differently by interrupting performance and unthrottling rapidly. Still boots fine after. I've yet to try if undervolting will allow that final big frequency step, on fan, increased to 105degC, no secondary throttle and no shutdowm.
I'd guess instead your battery voltage dropped too severely low being old degraded and too high a current draw, requiring a reset of the battery PCB or something.
55 isn't high at all for a CPU. You mean floating monitor overlay? It can select two custom temperatures to show on the dashboard and float monitor. The only real concern is battery temp. Other components are designed and rated to handle high temperatures. FWIW I've been running around 100degC CPU, keeping battery <50degC on fan with battery voltage limited to 3.85V for several months playing various high end games at maximum performance without notable ill effect. Well except that constant heat on the battery even at the safe low voltage will cause degradation, unavoidable cost for higher performance on a phone.
That location sounds like how it was when I tried AEX-O. Don't know if anything's changed there but no files could affect ROM thermal throttling on it then. The files there are different too, maybe generic Sd820 config or something, whereas RR-O uses the same sensors, values and config as stock N. I did also try the stock config modded to AEX but still no go. The only file with effect where it works is the -normal.conf.
Click to expand...
Click to collapse
Maybe I'm just too cautious But still, too much heat makes my hands really not comfortable.
I know we can customize which temperature to show, but no emmc_therm unfortunately. Reading your comment make me thinking, if the real concern is the battery temp, then why not using it as the trigger for the thermal config? It is listed as 'battery' in cpu-z list of thermal sensors. It means that we can use it right?
nfsmw_gr said:
Okay, so after reading through the comments I made a magisk module for myself to test, using the template from the Mi 5 thread.
I modified all 3 files to be sure it works (my device boots so yeah, try it and let me know).
Also made a copy of the modded files at /system/etc to cover all scenarios because in the ROM I run the files are located in /system/vendor/etc, not in /system/etc as in the OP .
It shouldn't affect anything I think.
Anyway without stalling you'll find the file attached at the bottom, as always you flash at your own risk, have a nice day!
(P.S. If this is ok I'll put it on my thread with my Jojoc mod.)
Click to expand...
Click to collapse
Thanks, that's so cool. I'll put it on the first post