[Galaxy S 5 General] Rahbar11:
(If you are too lazy to read the whole article, head down to The Final Results section and use those values for your kernel but i don't recommend that.)

The Introduction

First of all i am not a pro or something i am just a noob, so if i did any mistake in this post then please let me know. This thread can highly improve your SOT without compromising with the performance. I will try to make this thread as shorter as i can. I was getting 1 hour of SOT on my S5 a few days back, then i discovered this thread. I recommend everyone to leave this thread and read that one because everything is way better explained there but i am writing this for our S5 separately. Other device users can also read this if they want a shorter and simpler version of that original one.

The Setup

I am using smartpack kernel manager to tweak kernel values and i will also use cool tool for some reason (will explain it later.). Open smartpack kernel manager and go to cpu and open CPU Governor Tunables. We are going to tweak these values one by one.

above_hispeed_delay

To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.

Efficient Clock Rates

Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. To check this i jumped to cpu voltage section in smartpack kernel manager. My values are:

300MHz=775mV

422MHz=775mV

652MHz=775mV

729MHz=775mV

883MHz=780mV

960MHz=790mV

1036MHz=800mV

1190MHz=820mV

As you can see my voltage was same till 729MHz then it increased by 5mV, So 729MHz is an efficient clock rate for me. Now the volage was increasing by the same rate of 10mV till 1036MHz, So 1036MHz is also an efficient clock rate. Because i am too lazy to do this for every frequency i did that till 1728MHz and these are the efficient clock rates for me:

729MHz, 1036MHz, 1267MHz, 1728MHz

Nominal Clock Rates

Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups.

I really didn't understood the above method, i think because it was for a device with 2 cores but i knew that we don't need perfect values for this because we have to round up these values to our next near efficient clock rate.

So i figured out my own way: I turned off every hotplug and then turned off every core and changed the maximum frequency to the same as minimum (300MHz) and did every task by increasing the maximum frequency till i get the lag free experience. Figure out your nominal clock rates for atleast these tasks:

Idle

Web Page Scrolling

Video

Clock Rate Biases

Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. Now round up your nominal clock rates to the next near efficient clock rates, For example 652MHz was lag free for me for web page scrolling and the next near efficient clock rate is 729MHz. I got these values:

Idle=300MHz

Page Scrolling=729MHz

Video=1036MHz

App Loading=1267MHz

High Load Processing=1728MHz

The Setup

I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do.)

The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.

For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)

But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting

above_highspeed_delay - 20000

we will instead use the format "frequency:delay" to set

above_highspeed_delay - 20000 729000:60000

"Waaaait... What does that do?!"

This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 729Mhz. Once it has exceeded 729Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute.)

These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.

My Values: 20000 729000:60000 1036000:150000 1267000:300000

Optimize Idle Frequency (timer_rate)

Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (300Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:

timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.

above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.

The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!

Enhance Task Responsiveness

Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.

target_loads

Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)

We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)

We have to calculate maximal efficient load for our efficient clock rates only and minimal efficient load for the other frequencies.

For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:

(clock rate * 90) / next highest clock rate​

For example, the maximal efficient load for 729Mhz would be caluclated as:

(729000 * 90) / 883000 = 74.30% (rounded and normalized: 74)​

For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:

(1 - clock rate / previous highest clock rate) * -1​

For example, the minimal efficient load for 422Mhz would be calculated as:

(1 - 422000 / 300000) * -100 = 40.67% (rounded and normalized: 41)​

For our Galaxy S5, the maximal efficient loads are:

729:74

1036:78

1267:76

1728:79

For our Galaxy S5, the minimal efficient loads are:

300:0

422:41

652:55

883:21

960:9

1190:15

1497:18

1574:5

Using Optimal Loads

Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"

See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.

We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.

All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.

My Values: 98 422:41 652:55 729:74 883:21 960:9 1036:78 1190:15 1267:76 1497:18 1574:5 1728:79

Fix Stuttering (min_sample_time)

Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.

If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.

However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!

The Final Results

I recommend you to read the whole article first and calculate everything on your own. It will be fun, trust me! Maybe you will find out better values than these.

above_highspeed_delay - 20000 729000:60000 1036000:150000 1267000:300000

boost - 0

boostpulse_duration - 80000

go_highspeed_load - 99

hispeed_freq - 1190400

min_sample_time - 80000

target_loads - 98 422:41 652:55 729:74 883:21 960:9 1036:78 1190:15 1267:76 1497:18 1574:5 1728:79

timer_rate - 50000

timer_slack - 80000

The Conclusion

I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!

If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.

You may have noticed that i copied and pasted so much things directly from original post, without any changes. That's because there is nothing to change. I only changed some things that i thought are required to better understand this guide for our device.