You should download one of the attached files from the OP post as a .txt file and then place it at gov_profiles folder in the exkernel folder. Then rename the file and delete the .txt extension. Finally go to the app and load normally the gov_profile you want!
[OFFICIAL] GlassCannon - Interactive tweak port N5X l G4
- Thread starter phantom146
- Start date
I wasn't expecting the stats to be all over the place
lets check after a full cycle of yours on beta Mentioned above but you can even not rename it. It will still work
Thank you @shadowstep for clearing things out specially the freq. table. I would have jumped off the roof if it wasn't for you (All hail Magic). Also saw your signature
Hahahaha! :laugh: I try & keep my signature updated, and since I've been using your profile for a while now, I added it to my signature.
You're welcome! :silly:Also, like I said before, always happy to help! :highfive:
I forgot to reply about the 6p tweaks lol :silly:
Well first and foremost I thinl the 6p's GC is solid as it is. Still we can go experimental and do this. I personally think the original version is good enough but the beta you have lets adjust it to 672mjz for hispeed freq, loads and delay
Done! I'm attaching the updated profile in this post.
Already using itHahahaha! :laugh: I try & keep my signature updated, and since I've been using your profile for a while now, I added it to my signature.
Also, like I said before, always happy to help! :highfive:
Done! I'm attaching the updated profile in this post.
lets check if this profile works as I think it would so I can harness UNLIMITEEEEEEED POOOOWWWWEEEERRRR!!!
Lookey here @shadowstep
It seems the beta is performing much smoother and much more proficient than I expected it to be
Great frequency mashups here and lower frequency up times for 960mhz above
I'd check for a whole week to see what'll happen overtime.
Sorry for the double post tho, cant upload screenshots on edit.
It seems the beta is performing much smoother and much more proficient than I expected it to be
Great frequency mashups here and lower frequency up times for 960mhz above
I'd check for a whole week to see what'll happen overtime.
Sorry for the double post tho, cant upload screenshots on edit.
Attachments
Lookey here @shadowstep
It seems the beta is performing much smoother and much more proficient than I expected it to be
Great frequency mashups here and lower frequency up times for 960mhz above
I'd check for a whole week to see what'll happen overtime.
Sorry for the double post tho, cant upload screenshots on edit.
Looks great! I'm also gonna load up the beta version over the weekend, not in town at the moment. But I'm already pretty sure it'll be smooth.
jugoslavpetrovic
Senior Member
I think in first beta it was the boost milliseconds as 0 but with latest fixed its 40. Am I correct?
Sent from my Pixel using Tapatalk
Sent from my Pixel using Tapatalk
Well here's mine for the newest profile update. Sorry I haven't been here. School has been a *****. Last month of it so I have state testing and all that crap lol.Lookey here @shadowstep
It seems the beta is performing much smoother and much more proficient than I expected it to be
Great frequency mashups here and lower frequency up times for 960mhz above
I'd check for a whole week to see what'll happen overtime.
Sorry for the double post tho, cant upload screenshots on edit.
Attachments
No it's still 0. Did you forget tapping the save on reboot button for that value?
Don't fret about the boost_ms.. Its 40 before and I turnef it off at beta
Can you do me a quick favor and try turning everything that is 672mhz to 600mhz in your little cluster? (Hispeed_freq, targrt_loads and above_hispeed_delay) I think I've figured something out. Send another cycle so I can confirm this
It is set to 40 before though but it doesn't do anything really
Stock 7.1.2 with ElementalX 4.07 (and thermal mod Extreme v4). The stats include 36mins of playing Clash Royale and 20mins of Boom Beach.
Nvm, I had forgotten to reset the stats in EX Kernel Manager.
Attachments
Last edited:
Will do ?Don't fret about the boost_ms.. Its 40 before and I turnef it off at beta
Can you do me a quick favor and try turning everything that is 672mhz to 600mhz in your little cluster? (Hispeed_freq, targrt_loads and above_hispeed_delay) I think I've figured something out. Send another cycle so I can confirm this
It is set to 40 before though but it doesn't do anything really
No worries this are still viable info
I will wait for your next results and shall I add you to the official testers?. Another thing, I don't really recommend extreme thermal mod (no hate) because of the heat it generates and the voltage output it amplifies while charging. Not really good for the battery (theres a reason why thermal control on oems exists, disabling them is quite meh)
The 672mhz has been proven quite aggressive though within almost the same voltage as 600mhz.. the fact that the kernel has a "bias" towards 600mhz suggedts that the best target loads really aren't dependent on voltage jumps but due to certain kernel "bias" namely: 380mhz, 600mhz, 960mhz and 1200mhz
Also, the boost_ms albeit not noticeable plays a small significant role in migration threshold. I should put it back up but need more tests to check it.
This are upon reviewing other linux documentation as well as 2 threads from xda regarding the boost_ms. I might update the beta profiles after some more relative tests to check everything out.
But so far? Any lags?
None so far that are perceivable. It does indeed feel a bit more quicker but hard to gauge it out since it's all based on my perception. Battery life is still solid as you can see up top. My phone can last me a good two days if I'm fairly conservative.
Yah i'll be honest too, this feels quite quicker than before. I dont have that 0.2ms stutter window when switching tasks.
We will see how everything should go, and I wuld really probably push another update because of the bias and boosts I've mentioned above. We will wait for more testers to come up with.
Yeah I think the beta is too aggressive for its own sake. i'll make it much less aggressive but still smooth the next update. The boost_ms and 672mhz is the problem..
No worries this are still viable info
I will wait for your next results and shall I add you to the official testers?. Another thing, I don't really recommend extreme thermal mod (no hate) because of the heat it generates and the voltage output it amplifies while charging. Not really good for the battery (theres a reason why thermal control on oems exists, disabling them is quite meh)
I don't really care one way or the other but I use this as my daily driver so I can help out with the testing. The xtreme v4 thermal mod doesn't touch the voltage output while charging (that's a different mod), it only raises the throttling temperatures somewhat (still lower than on the LG G4). Though I've kept the "Thermal throttling" setting at the default 46 degrees so the phone doesn't really get noticeably warmer than on stock (with core_control, gets dangerously hot with just msm_thermal).
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
45Following the advice of @shadowstep and @Davey126 I have created a thread to separate this from the whole Interactive guide thread by @soniCron. This is due to (1) one, the thread is no longer updated for almost a year and (2) two; to explain the tweak, establish baselines/guides for testers and to gather more interested individuals to try it out.
-------------------------------------------
Introducing GlassCannon!
Description: A sound modification to the famous interactive parameters. Provides the smoothest interface, great performance while bestowing the lowest frequencies available. Ramping up quickly to maximize "inputs" from I/O overheads then immediately ramping down once tasks are done. The perfect balance between lowering down your frequency, and finishing up tasks quickly.
Why Glasscannon? Why not?
Who am I? I came from the hammerhead scene. I have been modding interactive parameters for more than 2 years and owns a community called: Android Battery Community whom has its own fair share of followers but has been quite stagnant for almost a year ever since my hammerhead broke. Though, I have been tweaking things with other devices; LG G4, Samsung Note 6, OPO and other smartphones that I got my hands on. Now I think it's time for me to get into the Nexus 6P scene. And after just literally 2 days after I posted the tweak, there are messages and posts tempting me to port it to N5X and LG G4, and with enough encouragement as well as a promise of testers; I edited the values matching my GlassCannon tweak with the former LG G4 .txt file I have in my desktop and here it is!
The difference? After years of being a paranoid about my battery (literally looking at dashboards, cpu cycles etc. you know, that guy who just tends to not be satisfied about everything) I finally settled down and read a lot of things and made it as my basis. Most tweaks in here uses target load as an optimal way to force cores to stick into lower frequencies but we won't be doing that with GlassCannon. We will be using two underrated tunables: above_hispeed_delay and input_boost. This two underrated tunables are being neglected for years, though some used it quite efficiently; I have yet to see a tweak that maximizes the two tunable's potential. We would be using above_hispeed_delay as a substitute to the unpredictable target_load. Instead of assigning too much within a tunable that we can't even lay our finger on how it works properly, why not let the SoC handle it and assign a delay along with timer_rate so it can run efficiently? And let input_boost jump up here and there to provide quick surge whenever there are tasks running under the hood.
Look under (Version: N5X l G4):
Code:[COLOR="Gray"]/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor interactive /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 384000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1440000 /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 93 /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0 600000:19000 787200:20000 960000:24000 1248000:38000 /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 50000 /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 600000 /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack 380000 /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 29 384000:88 600000:90 787200:92 960000:93 1248000:98 /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 60000 /sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0 /sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1 /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1 /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0 /sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0 /sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0 /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor interactive /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 384000 /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq 1824000 /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load 150 /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay 20000 960000:60000 1248000:30000 /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate 60000 /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq 960000 /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_slack 380000 /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads 98 /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time 60000 /sys/devices/system/cpu/cpu4/cpufreq/interactive/boost 0 /sys/devices/system/cpu/cpu4/cpufreq/interactive/align_windows 1 /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif 1 /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_sched_load 0 /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 0 /sys/devices/system/cpu/cpu4/cpufreq/interactive/boostpulse_duration 0 /sys/module/cpu_boost/parameters/input_boost_freq 0:600000 1:600000 2:600000 3:600000 4:960000 5:960000 /sys/module/cpu_boost/parameters/sync_threshold 1248000 /sys/module/cpu_boost/parameters/boost_ms 40 /sys/module/cpu_boost/parameters/migration_load_threshold 15 /sys/module/cpu_boost/parameters/load_based_syncs Y /sys/module/cpu_boost/parameters/shed_boost_on_input N /sys/module/cpu_boost/parameters/input_boost_ms 300 /sys/module/cpu_boost/parameters/input_boost_enabled 1 /sys/module/msm_performance/parameters/touchboost 0 /sys/module/msm_thermal/core_control/enabled 0 /sys/module/msm_thermal/parameters/enabled Y[/COLOR]
Explanation:
go_hispeed_load: Anything between 85-94 is average by my tests, it tends to stick to hispeed_load 40-60 which is what I think would be "optimal" for our cat.
above_hispeed_delay: The most important part of our tweak along with input_boost. This should set up the perfect "delay" so cpu cores could adjust and decide before ramping up to higher frequencies. Our frequency set as hispeed from little cluster is 600000.
target_loads: We won't be dwelling much in this. We put a small amount so that our frequency could ramp up if needed and take a pause on frequencies we deemed to be really significant; 600mhz, 672mhz, 960mhz and 12348mhz. Along with hispeed_delay, it should provide low consumption and tend to stick on 384mhz and 600mhz 89% of the time.
timer_slack: Put it to 380000, just trust me.
max_freq_hysteresis: Asking why theres jitters and a bit of stuttering on your screen? this is the culprit. Turn it to 0 and you will be fine as long as you correct the other tunables. This is because hysteresis actually uses "former" frequencies to calculate which frequency would be best to ramp up to next. If you tend to stick to lower frequencies more, with this on then you will be sticking at low frequencies almost forever, which obviously isn't something good.
input_boost: Now, to explain why this is important; there are two things I would like to emphasize. (1) One, this value was made so that under the hood tasks as well as simple bumps to your frequency if there is a notification, sync etc. would be possible. (2) this value is extremely useful to provide that quick boost to complete tasks with ease. The big clusters would have an input_boost of 633000 which was supposed to be the stock mhz. Why? I deemed that the big cluster isn't that necessary unless you are running an extremely graphic heavy game. So tone it down to 384mhz underclocking it and provide input boost to the mhz that was supposed to be the stock frequency, increasing battery life without sacrificing anything.
Will this be updated? NO, NEVER. I am asking myself why does this other "tweaks" update from time to time if there are no kernel parameters that are changing? Aren't all those tweaks supposed to be tested hundreds of times before releasing? Then why change the parameters again? Am I asking too much? Am I fat? NO. Just NO. EXCEPT if there will be changes within the interactive parameters then sure.
Maximal, Minimal and Nominal Frequencies? Not to hurt anyone's heart but I personally think that this is a retardified(if that is in fact a word) version of "I shall say something smart". I don't see the point of determining what the nominal, maximal and minimal frequencies are as we can't even put a finger what they literally mean. This is actually "subjective" and I really find this so called nominal frequencies irrelevant. Please don't hate.
Do note that most of the explanations above were not edited and is still pretty much the same as N6P description because I'm lazy af.Credits: @soniCron, @xSilas43, @shadowstep for pointing out the missing timer_slack and input_boost, google for many things to read, this website for music while typing, that website for providing me more things to read, a bucket of fries and two chickens to make me company.
Go ahead and feel free to download the .txt file below and happy tweaking!
======================A SINCERE THANKS TO EVERYONE WHO TESTED AND PARTICIPATED
Tips Hat
After many things happening and after more than a month, I am really glad that we have succesfully ported GlassCannon to N5X and LG G4 (or any other device with same cpu structure). I am proud to present to you the fruits of the small labors of both me and the team as well as others behind the scene testing GlassCannon for your devices.
What has been the verdict? Overall, via landslide; the GlassCannon's Beta2.0 has come out on top. I figured and of course realized after the alphatest that people in N5X community complained (though in small dose) about stutters and a small lag in some apps. Most were debunked especially if you are using an online app but I had to wrap around everything and investigate further. Even though I promised that the Beta would be more battery efficient, I adjusted it so that it should provide a much better performance and smoothness without compromising the battery life of our cats. And thus, the verdict is Beta 2.0 *autistic screeching*
Special thanks to: @Curlyfry2121 @shadowstep @crian @spartan268 @IcyGlacial @Lazerlord
Just a headsup, I will be leaving the Alpha below for other people to download if they still want some!
Grab a copy below! Enjoy!10*Silently drops betatest2.0*
===============================Changes:
target_loads: Reverted back to the old little cluster target load to increase the uptime on specific and designated frequencies. Marginally noticeable but decreases "erratic" frequency loadings on simple and hopefully heavy usage.
hispeed_frequency: Reverted back to 600mhz after many cycles and response from testers. This is also because of my thought that the voltage really does not matter on where the core would stay; instead, they have this certain "bias" on frequencies namely: 384mhz, 600mhz, 960mhz and 1200mhz. Voltage doesn't play a big part on where frequencies should stick, disproving other people's theories (not yet proven.. yet)
timer_slack: got it to 380000 on big cluster, 480000 doesn't make any difference really.
above_hispeed_delay: Reverted back to the old hispeed delay.
boost_ms: made it back to 40ms to help handling thread_migration on kernels. This is like I/O overheads under the hood. This won't cost you any battery life I promise.
This update should make everything less aggressive, lenient on battery but won't also lose that buttery smooth and performance side. This should be the final product of the beta test. Will wait for everyone's verdict!
Cheers!9Official Testers:
Credits to:
Everyone whom are secretly using the GlassCannon profile. To my Kentucky Fried Chicken for keeping me company. @Davey126 for encouragement and other stuffs, @The Flash because you are the fastest man alive, @shadowstep for being a MTG fan, @flar2 for being an awesome developer and supporting this kind of tweaks, @soniCron for starting this and many more. Huge thanks! and I hope this will go on for the better!7I have added a poll which will close at May 10, 2017.
This is the deciding factor which we will officially port..
Also (not yet sure) but a developer here in xda is creating a kernel profiler app which I am doing some UI improvements with. This is a simple app which if your device is supported you can apply kernel profiles. This poll is very much needed so we can decide which profile to add on the app. Thanks for the support!
