Hello guys , i recently rooted my phone successfully! I really didnt like how lg operated this phone , simple games was micro lagging , not as smooth as adreno 530 was marketed. When i set the cpu on ondemand governor and disabling thermal core control all games became smooth as butter , really love it this way. I am playing my games with base optimisation so it downscales the resolution but my device didn't warm up at all, so i decided to mess with thermal throttling settings....
Here is what i found after searching with Solid Explorer , go to ROOT>SYSTEM>ETC>thermal-engine-8996.conf
Thats the log for the thermal control:
sampling 5000
c_mode_ap 0
c_mode_pmic 11
[KRYO_SS]
algo_type ss
sensor vts
sampling 5000
device cpu_voltage
set_point 42000
set_point_clr 40500
[SS-CPUS-ALL]
algo_type ss
sensor VIRTUAL-CPUS
sampling 10
device cpu_voltage
set_point 85000
set_point_clr 65000
[SS-GPU]
algo_type ss
sensor gpu
sampling 250
device gpu
set_point 85000
set_point_clr 65000
[SS-POPMEM]
algo_type ss
sensor pop_mem
sampling 10
device cluster1
set_point 85000
set_point_clr 65000
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 40000 41500 43000 44500
thresholds_clr 39000 40500 42000 43500
actions gpu gpu gpu gpu
action_info 510000000 315000000 214000000 133000000
[CHG_MONITOR]
algo_type monitor
sensor skin_pmic
sampling 5000
thresholds 42000 45000 48000 50000
thresholds_clr 38500 42500 45500 48500
actions chg_ibat chg_ibat chg_ibat chg_ibat
action_info 3100 1000 600 300
[PA_MONITOR]
algo_type monitor
sensor pa_therm0
sampling 5000
thresholds 45000
thresholds_clr 42500
actions chg_ibat
action_info 1000
[LCD_ON_MONITOR]
algo_type monitor
sensor lcd-brightness
sampling 5000
thresholds 1
thresholds_clr 0
actions chg_ibat
action_info 1000
[DAYLIGHT_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 42500
thresholds_clr 38000
actions daylight
action_info 1
And did change GPU_MONITOR like that:
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 41000 44500 50000 54500
thresholds_clr 39000 41500 45000 50500
actions gpu gpu gpu gpu
action_info 624000000 560000000 510000000 401000000
After studding a bit and making way too much testings on my phone , i could make it , mod will be soon available i am still testing it to make sure its stable as rock!
Take a look at the thumbnails below
I just Deleted the whole file and scored 144170!!! Everything was increased a bit , i am going to test it more and update the thread! 2nd 3D scrore also was improved a bit (1000 points, throttled less) , it just might work with default settings now ,at least i hope...
*** Dont delete the file , device won't throttle , i was playing real racing 3 cpu hit 80C (thats not good) and gpy 67c (not bad at all) so i am going back to edit the log!!!
Thanks for the information and that you shared this. I will perhaps include in my Custom Kernel.
Gesendet von meinem LG-H850 mit Tapatalk
thehacker911 said:
Thanks for the information and that you shared this. I will perhaps include in my Custom Kernel.
Gesendet von meinem LG-H850 mit Tapatalk
Click to expand...
Click to collapse
Thats why i shared it , i have been testing it all the day , by increasing the values on threshold (temps) and the last ones (mhz) i got a little more perf but you can't get more than that , even if you delete both gpu tables still throttling occurs during benchmarks. In order to delay more the GPU throttling temp you need to increase throttling values of the CPU and that makes also the phone hotter but things like performance doesnt go with low temps....
leonman44 said:
I just Deleted the whole file and scored 144170!!! Everything was increased a bit , i am going to test it more and update the thread! 2nd 3D scrore also was improved a bit (1000 points, throttled less) , it just might work with default settings now ,at least i hope...
*** Dont delete the file , device won't throttle , i was playing real racing 3 cpu hit 80C (thats not good) and gpy 67c (not bad at all) so i am going back to edit the log!!!
Click to expand...
Click to collapse
I've noticed I get the screen brightness all the way up and it starts dimming when it gets kinda hot. If I erase the file will my screen brightness stay bright?
Still_living714 said:
I've noticed I get the screen brightness all the way up and it starts dimming when it gets kinda hot. If I erase the file will my screen brightness stay bright?
Click to expand...
Click to collapse
Sorry for the late answer , if your phone warms up just stock dont delete the whole file , just delete the "lcd on" and "daylight" columns. That should do the trick! :good:
leonman44 said:
Sorry for the late answer , if your phone warms up just stock dont delete the whole file , just delete the "lcd on" and "daylight" columns. That should do the trick! :good:
Click to expand...
Click to collapse
Haha thanks but I'm on the s7 edge now
leonman44 said:
Hello guys , i recently rooted my phone successfully! I really didnt like how lg operated this phone , simple games was micro lagging , not as smooth as adreno 530 was marketed. When i set the cpu on ondemand governor and disabling thermal core control all games became smooth as butter , really love it this way. I am playing my games with base optimisation so it downscales the resolution but my device didn't warm up at all, so i decided to mess with thermal throttling settings....
Here is what i found after searching with Solid Explorer , go to ROOT>SYSTEM>ETC>thermal-engine-8996.conf
Thats the log for the thermal control:
sampling 5000
c_mode_ap 0
c_mode_pmic 11
[KRYO_SS]
algo_type ss
sensor vts
sampling 5000
device cpu_voltage
set_point 42000
set_point_clr 40500
[SS-CPUS-ALL]
algo_type ss
sensor VIRTUAL-CPUS
sampling 10
device cpu_voltage
set_point 85000
set_point_clr 65000
[SS-GPU]
algo_type ss
sensor gpu
sampling 250
device gpu
set_point 85000
set_point_clr 65000
[SS-POPMEM]
algo_type ss
sensor pop_mem
sampling 10
device cluster1
set_point 85000
set_point_clr 65000
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 40000 41500 43000 44500
thresholds_clr 39000 40500 42000 43500
actions gpu gpu gpu gpu
action_info 510000000 315000000 214000000 133000000
[CHG_MONITOR]
algo_type monitor
sensor skin_pmic
sampling 5000
thresholds 42000 45000 48000 50000
thresholds_clr 38500 42500 45500 48500
actions chg_ibat chg_ibat chg_ibat chg_ibat
action_info 3100 1000 600 300
[PA_MONITOR]
algo_type monitor
sensor pa_therm0
sampling 5000
thresholds 45000
thresholds_clr 42500
actions chg_ibat
action_info 1000
[LCD_ON_MONITOR]
algo_type monitor
sensor lcd-brightness
sampling 5000
thresholds 1
thresholds_clr 0
actions chg_ibat
action_info 1000
[DAYLIGHT_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 42500
thresholds_clr 38000
actions daylight
action_info 1
And did change GPU_MONITOR like that:
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 41000 44500 50000 54500
thresholds_clr 39000 41500 45000 50500
actions gpu gpu gpu gpu
action_info 624000000 560000000 510000000 401000000
After studding a bit and making way too much testings on my phone , i could make it , mod will be soon available i am still testing it to make sure its stable as rock!
Take a look at the thumbnails below
Click to expand...
Click to collapse
{
"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
For those of you using the modified thermal-engine-8996.conf files in this forum, I would recommend using these three specifications under the [KYRO_SS] area: (keep everything else the same)
set_point 49500
set_point_clr 45500
device_perf_floor 1324800
set_point determines a threshold for thermal throttling
set_point_clr determines when to stop thermal throttling
They don't equate exactly to the degrees in celsius for the CPU or battery, so I'm not sure exactly what the translation is. However, I found that this was a pretty good threshold to use to reduce the thermal throttling on the CPU.
By setting the device_perf_floor metric to a lower number, I could also make sure that thermal throttling DID happen when it was needed. This helped a lot to reduce the chances of my phone from overheating and shutting down during a hot summer day.
Hope this helps somebody! This really saved my phone.
this is the two i modified
p.s. do not go higher than 1824000... it went so hot my first Lgv20 screen got unglued from the case lol. now is working fine with my second lg v20 with below config
KRYO_SS]
algo_type ss
sensor skin_ap
sampling 5000
device cpu_voltage
set_point 40000
set_point_clr 38500
device_perf_floor 1824000
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 38000 39500 41000 42500
thresholds_clr 37000 38500 40000 41500
actions gpu gpu gpu gpu
action_info 642000000 560000000 510000000 401000000
paul999 said:
this is the two i modified
p.s. do not go higher than 1824000... it went so hot my first Lgv20 screen got unglued from the case lol. now is working fine with my second lg v20 with below config
KRYO_SS]
algo_type ss
sensor skin_ap
sampling 5000
device cpu_voltage
set_point 40000
set_point_clr 38500
device_perf_floor 1824000
[GPU_MONITOR]
algo_type monitor
sensor vts
sampling 5000
thresholds 38000 39500 41000 42500
thresholds_clr 37000 38500 40000 41500
actions gpu gpu gpu gpu
action_info 642000000 560000000 510000000 401000000
Click to expand...
Click to collapse
The difference betwen the two methods is that 1824000 is actually kind of a high frequency to be thermal throttling at. (especially during the hot summer days we've been having lately in my state, my phone would just continue heating up and shutting down) I find that modifying set_point and set_point_clr are actually better since it increases the temperature setting BEFORE it starts throttling, but still throttles when it really needs to. This is especially helpful when using extended life batteries like the 6700 mAh batteries or 8500 mAh batteries which tend to run hotter than the average 3200 mAh batteries.
What I've observed is that if the extended batteries go above 51 degrees celsius, it starts kind of a chain reaction of heat between the CPU and battery that eventually causes the phone to overheat. I targeted the set_point and set_point_clr settings to cause it to throttle around this time to still make the phone usable, just slower for a short time.
I found that 1324800 was a good frequency to actually bring the temperature back down. When I set it at higher frequencies, the temperature for the battery would still stay around 51 degrees celsius or higher which was too hot for my taste.
i think my phone can handle it since i replaced the cheap paste with a premium paste......anyway i will test your method out to see if theres improvement