Related
Hey guys!
I was wondering if anyone can give me some info on the differences between the governors with doomkernel and the schedulers.
Thanks!
Cheers,
This was posted by DooMLoRD, i just copied the post not all governors are there:
2. Governors In the Linux Kernel ================================
2.1 Performance ------------------------------
The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq.
2.2 Powersave ----------------------------
The CPUfreq governor "powersave" sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq.
2.3 Userspace ----------------------------
The CPUfreq governor "userspace" allows the user, or any userspace program running with UID "root", to set the CPU to a specific frequency by making a sysfs file "scaling_setspeed" available in the CPU-device directory.
2.4 Ondemand ---------------------------
The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to switch the frequency very quickly. There are a number of sysfs file accessible parameters:
sampling_rate: measured in uS (10^-6 seconds), this is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more.
show_sampling_rate_(min|max): the minimum and maximum sampling rates available that you may set 'sampling_rate' to.
up_threshold: defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased.
ignore_nice_load: this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.
2.5 Conservative -------------------------------
The CPUfreq governor "conservative", much like the "ondemand" governor, sets the CPU depending on the current usage. It differs in behaviour in that it gracefully increases and decreases the CPU speed rather than jumping to max speed the moment there is any load on the CPU. This behaviour more suitable in a battery powered environment. The governor is tweaked in the same manner as the "ondemand" governor through sysfs with the addition of:
freq_step: this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor.
down_threshold: same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
2.6 Interactive ------------------------------
The CPUfreq governor "interactive" is designed for low latency, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However there is no polling, or 'sample_rate' required to scale the CPU up.
Sampling CPU load every X ms can lead to under powering the CPU for X ms, leading to dropped framerate, stuttering UI etc..
Scaling the CPU up is done when coming out of idle, and like "ondemand" scaling up will always go to MAX, then step down based off of cpu load.
There is only one tuneable value for this governor:
min_sample_time: The ammount of time the CPU must spend (in uS) at the current frequency before scaling DOWN. This is done to more accurately determine the cpu workload and the best speed for that workload. The default is 50ms.
2.7 MinMax ------------------------------
The CPUfreq governor "maxmin" tries to minimize the frequency jumps by limiting the selected frequencies to only two frequencies: either the min or the max frequency of the current policy. The frequency is raised or lowered according to the current load and the 'up_threshold' and 'down_threshold'.
Its parameters and implementation are similar to that of conservative.
It does not have the freq_step parameter as it jumps right from min to max and vice-versa.
The sampling_down_factor, unlike conservative, will count the minimal number of samplings since the last time we saw the 'up_threshold' load on the CPU. Hence it is set to higher default and acts as a limiter not to do too many frequency jumps without hurting the performance.
Thanks sorry, didnt see it for some reason. Ignore my questions.
Cheers,
oppiee said:
Thanks sorry, didnt see it for some reason. Ignore my questions.
Cheers,
Click to expand...
Click to collapse
One thing to note pal. All chipsets have different tolerances so whereas interactive works best for me, it may not be good for u. Just test em and use CPU spy/ ur own judgement to c which suits ur phone best.
Sent from my X10i using XDA App
Yup I am currently fiddling around with the different settings. The main thing I want to accomplish is not to have lag when im scrolling and opening up basic apps such as dialer and browser. I dont really play games. I hate the fact that the phone lags up sometimes. So far Its ok, but getting some WLOD on super high freq.
Any suggestions?
oppiee said:
Yup I am currently fiddling around with the different settings. The main thing I want to accomplish is not to have lag when im scrolling and opening up basic apps such as dialer and browser. I dont really play games. I hate the fact that the phone lags up sometimes. So far Its ok, but getting some WLOD on super high freq.
Any suggestions?
Click to expand...
Click to collapse
Can u post a screenshot of CPU tuner or whatever u use of freqs u use? Also are u using doomkernel fs version as I think some handsets can't even boot up oc kernel.
Sent from my X10i using XDA App
Any good programs to take screen shots? I am using the highest OC kernel by DL, and using doomkernel wolfbreak V7b6.
Not mean to sound patronising pal but just type screen shot into android market theres plenty
Edit: ur phone prob can't handle the overclock. Read the kernel thread it says this pal.
Sent from my X10i using XDA App
Oh i think there might has been some misunderstanding. My phone is running fine, just doing some testing. at 1.229 Mhz I tend to get WLODs, using minmax with SIO.
At 1.114 and 245, using min max with SIO. everything is fine so far. I just thought you wanted to know for your own purposes.
Cheers
Sorry buddy I misunderstood
Sent from my X10i using XDA App
thers some missing from the top
lagfree
scary
brazilianwax
savaged zen
what do theese do
also whats the best settings from all of them from your opinion
I have:
Brazilianwax
Smoothass
Lagfree
Smartassv2
SavagedZen
Scary
Smartass
Minmax
Interactivex
Interactive
Conservative
Userspace
Powersave
OnDemand
Performance.
Not used them all but lagfree is (as suggested free from lag & smooth. Brazilianwax didnt work for me very laggy. Scary was quite good also, along with interactive. Not really tested the others enough to pass comment to be honest
Disclaimer; This does not damage your phone at all or fry/mess up your cpu. On the contrary, it helps it by not running at full capacity all the time resulting in less stress and increased battery.
This method works universally for any Android phone you're using. But you'll need ROOT for Set CPU.
IMPORTANT: The newer versions of SetCPU might prevent your phone from entering deep sleep. Download version 2.24 from the following link which is the one with no problems and completely works 100%.
http://forum.xda-developers.com/showthread.php?t=505419
The Ace sucks in battery life. We all know that. And on 3G? Don't even mention it. But here's a fix, ever tried Under clocking instead of Over clocking?
Someone brought it up on a thread a couple of days ago and I have to spread the word, that works wonders. Got my Ace running on 245 min and 806 max and a different Screen Off profile. And now from the morning till 6PM in the afternoon, its just 61% AND recorded a 7 minute video/took pictures.
Battery was the only issue I had with my Ace. But now that its fixed, I love it
When screen is on:
MAX 806
MIN 245
Ondemand governor (This governor bumps up to max when needed but spends most time on the min freq. Best battery saver.)
When screen is off:
MAX 320
MIN 122
This way, you have a beast quick phone when you're using it, and the best battery saver when you're not!
This is what CPU spy should look like when you're done:
{
"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"
}
NOTE: Turn off Autosync from the settings. It's only used to sync your gmail and contacts and such. You can manually sync when you add a new contact and since I don't use gmail, I refresh manually whenever I do. 3G is the worst battery killer so this will help a lot.
SetCPU: http://forum.xda-developers.com/showthread.php?t=505419
Specific instructions for those that can't get it to work!:
On SetCPU:
Click Add profile
Where it says Profile, select it and tap "Screen Off"
Set the frequencies you want in use while screen is off (If you want just one frecuency, put both sliders on the same number)
Set priority (in case you have other profiles, otherwise don't bother)
Select governor (Won't really matter since cpu is gonna be running at 1 frecuency)
Tap save
Go back to Profiles tab at the top, then tap Enable at the top left to make the profiles work.
For a list of most governors detailed; check out this thread! http://forum.xda-developers.com/showthread.php?t=1242323
To check if its all working, install CPU spy from the market:
https://play.google.com/store/apps/...251bGwsMSwxLDEsImNvbS5idmFsb3Nlay5jcHVzcHkiXQ..
Battery Calibration
1. Turn your phone off
2. Leave charging over night
3. Turn it on
4. Leave it charging for half an hour
5. Download this app https://play.google.com/store/apps/details?id=com.nema.batterycalibration&feature=search_result
6. Open it and press calibrate battery
7. Discharge your phone down to 0% during the day
8. Charge back up to 100% NON-STOP.
This is to make sure you're using your battery at 100%. Only do this after you flash a new rom.
The worst battery killer is 3G itself. No matter how much you try to optimize battery and underclock, if you have 3G on, you're gonna have a bad time. MAKE SURE Autosync is disabled.
Thanks to QNBT for the AutoSync off and new profile settings hint!
gotta try this one. hope this works!
Hey dude I may try that tip, but I wanted to know about the governor that you are using, is that one a battery saver?, and what about chainfire 3d? you said that you dont use heavy apps and as far as I know that one is for heavy gaming isnt it?
ps. I recommend you install Vturbo 8.5 by gadgetcheck since I didnt see it on your signature, it really works
tyraelasd said:
Hey dude I may try that tip, but I wanted to know about the governor that you are using, is that one a battery saver?, and what about chainfire 3d? you said that you dont use heavy apps and as far as I know that one is for heavy gaming isnt it?
ps. I recommend you install Vturbo 8.5 by gadgetcheck since I didnt see it on your signature, it really works
Click to expand...
Click to collapse
Yeah, I'm not using heavy apps now but I do like some gaming now and then. When I do game, I crank up the processor back to normal but I rarely do. And I use Smartass governor, not really sure if its a battery saver but its working great.
And yeah, I think I had turbo 8.5. But for now, my ace runs perfectly fine so I don't really need other scripts or optimizers
CPU governors control exactly how the CPU scales between your “max” and “min” set frequencies. Most kernels have “ondemand” and “performance.” The availability
ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels. The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
Thanks for the tip, works for me
Im trying smartass governor but I noticed that the battery got really hot for some unknown reason :/, and I I got back to ondemand it becomes normal. Any idea?
I would rather use SetCPu becouse a need automatic changes since I play a lot ;P
I have no idea. My phone's working fine. I keep switching between interactive and smartass. Can't really tell which one works better xD
Sent from my GT-S5830 using XDA App
Ooohhh I see. Thanks for the governor definitions. Keeping Smartass then
Sent from my GT-S5830 using XDA App
i had battery issues (only lasts for a day), after applying this, another day was introduced for my SGA. LOL clicked the thanks button! cheers!
tomy2590 said:
i had battery issues (only lasts for a day), after applying this, another day was introduced for my SGA. LOL clicked the thanks button! cheers!
Click to expand...
Click to collapse
Haha good to know it doesn't only work for me. I clocked it down lower to 320 since I'm barely using it now. Love my ace
SuperAce609 said:
Haha good to know it doesn't only work for me. I clocked it down lower to 320 since I'm barely using it now. Love my ace
Click to expand...
Click to collapse
Hahaa... I know why...
Because you using What ROM? What Tweaks/script? like me too.. Hehehe..
Thank for sharing that setting... I'm really love my SGA now..
arip30 said:
Hahaa... I know why...
Because you using What ROM? What Tweaks/script? like me too.. Hehehe..
Thank for sharing that setting... I'm really love my SGA now..
Click to expand...
Click to collapse
This rom actually has a pretty bad battery life. But makes up for it with speed and stability. I'm only using the LagFree V2 script and thinking about adding TurboBoost but I'm not sure if they can work together.
SuperAce609 said:
This rom actually has a pretty bad battery life. But makes up for it with speed and stability. I'm only using the LagFree V2 script and thinking about adding TurboBoost but I'm not sure if they can work together.
Click to expand...
Click to collapse
I already using both.. I'thing its can work together.. But i'm not to sure cause am only using lest then 1 week..
For me, i want to using a smoth n fast.. i don't care about the battery live cause i can charge or use my secondary/spare battery..
________________________________
Please push thank button for me.. TQ..
arip30 said:
I already using both.. I'thing its can work together.. But i'm not to sure cause am only using lest then 1 week..
For me, i want to using a smoth n fast.. i don't care about the battery live cause i can charge or use my secondary/spare battery..
________________________________
Please push thank button for me.. TQ..
Click to expand...
Click to collapse
Well, just in case you miss your spare battery at home or something, check out the edit I just made on the thread.
Will make your spare battery look like wasted money xD
Using CPUtuner now. Free and works perfectly. I dont think i need smartass governor, since it offers separate screenoff profile, where i can set everything i want, including services on/off.
knall said:
Using CPUtuner now. Free and works perfectly. I dont think i need smartass governor, since it offers separate screenoff profile, where i can set everything i want, including services on/off.
Click to expand...
Click to collapse
Lol, okay. SetCPU is also free (on XDA). But whatever works for you is fine. My fix is just running CPU at minimum as soon as the screen is off and switch profiles when the screen is on. That way you'll always have battery to use when you want to and not use up battery when you're not using the phone.
rjyama said:
CPU governors control exactly how the CPU scales between your “max” and “min” set frequencies. Most kernels have “ondemand” and “performance.” The availability
ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels. The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
Thanks for the tip, works for me
Click to expand...
Click to collapse
Thanks for the explanation, man...it was very useful
My setting
Profile: screen off
Min 122
Max 122
Governor: powersave
Profile: battery
101%
Min 122
Max 806
Governor: conservative
pyronia said:
My setting
Profile: screen off
Min 122
Max 122
Governor: powersave
Profile: battery
101%
Min 122
Max 806
Governor: conservative
Click to expand...
Click to collapse
I REALLY don't recommend leaving it at 122 minimum. I tried it today and had a lot of lag attacks. Though the battery saving is incredible, but at the cost of a lot of performance. Like taking a call, it'll lag like hell. Had a lot of missed calls today just because of that issue.
But if it works for you, then have fun!
SuperAce609 said:
I REALLY don't recommend leaving it at 122 minimum. I tried it today and had a lot of lag attacks. Though the battery saving is incredible, but at the cost of a lot of performance. Like taking a call, it'll lag like hell. Had a lot of missed calls today just because of that issue.
But if it works for you, then have fun!
Click to expand...
Click to collapse
Yeah, I noticed that a few weeks back, couldn't even answer so much it was laggy. You can set in phone call 245mhz and priority higher than screen off and it resolves that issue.
I use cyanogenmod performance for setting the clock with 245mhz min now, I don't have any wakelocks so the processor is always off (deep sleep) when the screen is off, at the same time I don't have the wake lag issue since its not running at 122mhz when it wakes.
Hi Guys!
Just made this thread to let people share their favorite governor and overclock settings for our beloved Xperia S in a way we can have both performance and good battery life.
Feel free to share!
Right now I'm using the Interactive governor and don't have my XPS overclocked.
Got the CPU set to Min: 192 and Max: 540 when screen off.
I can easily get 30 hours with one full charge.
Sent with my Sony Xperia S using a little bit of KA magic.
I use Conservative Governor with tweaks inspired in the Lionheart governor
Kernel SSpeed 5.1 Stock Frequency
Min Clock: 192
Max Clock: 1566
Governor: Conservative
Scheduler: Noop
[setCPU Governor Settings]
Sampling Rate: 200000
Sampling Down Factor: 1
Up Threshold: 55
Down Threshold: 15
Ignore Nice Load: 0
Freq Step: 5
The governor becomes a really agressive one, ramping fast, and downing only when CPU isn't needed anymore. Frequency seek is the most frequent possible for Conservative (every 0.2 seconds). This tweaks turn the Phone in a more agressive OnDemand with tendencies to stay in the lowest clock possible, thanks to Conservative nature.
In addiction with CPU Sleep (Google Play App) i can have a hotplug feature when the screen is off. (It only works nice with stock based kernels).
I'm Testing Freq Step 10 at the moment.
How long does your battery last with these exact settings?
Sent with my Sony Xperia S using a little bit of KA magic.
ROM=cm9 fxp 133
Kernel=Pure ICS
Clock speeds
max=1.4Ghz
min=0.2Ghz
Govenor=Hotplug
JoelChrist_ said:
How long does your battery last with these exact settings?
Sent with my Sony Xperia S using a little bit of KA magic.
Click to expand...
Click to collapse
Never meassured it. But i will do, but i think it will not last a lot, since im a heavy user
darksherko said:
ROM=cm9 fxp 133
Kernel=Pure ICS
Clock speeds
max=1.4Ghz
min=0.2Ghz
Govenor=Hotplug
Click to expand...
Click to collapse
Do you have a long battery life on the hotplug governor?
Sent with my Sony Xperia S using a little bit of KA magic.
JoelChrist_ said:
Right now I'm using the Interactive governor and don't have my XPS overclocked.
Got the CPU set to Min: 192 and Max: 540 when screen off.
I can easily get 30 hours with one full charge.
Sent with my Sony Xperia S using a little bit of KA magic.
Click to expand...
Click to collapse
Cool, how do I do that?
JoelChrist_ said:
Right now I'm using the Interactive governor and don't have my XPS overclocked.
Got the CPU set to Min: 192 and Max: 540 when screen off.
I can easily get 30 hours with one full charge.
Sent with my Sony Xperia S using a little bit of KA magic.
Click to expand...
Click to collapse
how are people getting such great battery life? must have everything turned off all the time and never use the phone?
mine is on stock kernel rooted and using setcpu to keep cpu down some.
it using on demmand/deadline max 1026max 192min, except when srceen is off or battery below 25%, when it goes down to 486max 192min.
does using a custom kernel really make that much difference.
if i turn everything oaff (data/sync etc) o still only get a max of around 18-20 hours, even if it's sat idle. if i leave data on sync on but sat idle it will last upto 16 hours, and if i actually use the phone it will last anything from 8 to 12 hours.
battery life is really a major issue i'm finding, even with cpu values lowered, and with unused system apps, like battery saver etc frozen with titanium backup.
i don't want to remove apps that i actually use, like the timescape syncing, weather widgets, etc.....because at the end of the day, there is no point in having a phone with "smart" features, then disabling them to get 3 days "use" out of it....but honestly, having to charge it evry single night, and if i use the phone at all during the day, having to charge it mid-way is far from ideal....
brunodmjr said:
I use Conservative Governor with tweaks inspired in the Lionheart governor
Kernel SSpeed 5.1 Stock Frequency
Min Clock: 192
Max Clock: 1566
Governor: Conservative
Scheduler: Noop
[setCPU Governor Settings]
Sampling Rate: 200000
Sampling Down Factor: 1
Up Threshold: 55
Down Threshold: 15
Ignore Nice Load: 0
Freq Step: 5
The governor becomes a really agressive one, ramping fast, and downing only when CPU isn't needed anymore. Frequency seek is the most frequent possible for Conservative (every 0.2 seconds). This tweaks turn the Phone in a more agressive OnDemand with tendencies to stay in the lowest clock possible, thanks to Conservative nature.
In addiction with CPU Sleep (Google Play App) i can have a hotplug feature when the screen is off. (It only works nice with stock based kernels).
I'm Testing Freq Step 10 at the moment.
Click to expand...
Click to collapse
This setup is turned to performance or battery (while actually using the phone).?
Sent from my LT26i with Tapatalk 2
I use the conservative governor with a min frequency of 384mhz and depending on what I'm using the phone for, either 1.24ghz or upto 1.67ghz. Have noticed an obvious increase in battery life, probably around 20%. Using stock ICS with KA SSpeed kernel 5.1.
Sent from my LT26i using xda app-developers app
brunodmjr said:
I use Conservative Governor with tweaks inspired in the Lionheart governor
Kernel SSpeed 5.1 Stock Frequency
Min Clock: 192
Max Clock: 1566
Governor: Conservative
Scheduler: Noop
[setCPU Governor Settings]
Sampling Rate: 200000
Sampling Down Factor: 1
Up Threshold: 55
Down Threshold: 15
Ignore Nice Load: 0
Freq Step: 5
The governor becomes a really agressive one, ramping fast, and downing only when CPU isn't needed anymore. Frequency seek is the most frequent possible for Conservative (every 0.2 seconds). This tweaks turn the Phone in a more agressive OnDemand with tendencies to stay in the lowest clock possible, thanks to Conservative nature.
In addiction with CPU Sleep (Google Play App) i can have a hotplug feature when the screen is off. (It only works nice with stock based kernels).
I'm Testing Freq Step 10 at the moment.
Click to expand...
Click to collapse
I don't know what you did bro, but with this setup (except for the governor, which I'm using pegasusq) made my phone fly. The lights animation on the AnTuTu Benchmark (I just do a synthetic to see what I get) had a peak of 75 fps, and then stabilized in 65 fps.
{
"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"
}
Kernel : Advanced Stock Kernel
Min Clock: 384
Max Clock: 1026
Governor: Ondemand
Scheduler: Noop
Screen Off
Min Clock : 192
Max Clock : 384
Governer : Powersave
Getting up to 46 hours with this setup + CPU Sleeper
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.
{
"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