Originally Posted by The Gingerbread Man
Just woken up and feel like my head is going to explode already this last 5 pages is crazy
haha. It's been a crazy two days.
But it's been a blast.
Now, sleep is over, time to get back to work!
Yes and no. Here's what we're thinkin' so far.
THIS POST WILL BE A RECAP OF THE LAST FEW PAGES OF RESEARCH!
Originally Posted by garuhhh
I got these from that thread:
so it makes much sense, to make the min_sample_time as low as possible (?), but how low? what's the most appropriate sample time for battery and performance?
for the timer_rate, franco suggested 30k to consider the CPUs latency. What has it to do with the cpu's latency?
he also said min_sample_time doesn't have to be in multiple of timer_rate.
in my case, all my timers are in 20k, which works fine as of now. But i must be missing some things, because I just saw somebody post these values, and no detailed explanation for having them.
This was my original settings that I've been using for weeks:
So to make the short hand easier, we kept it in that order and just said: 20000/50/40000/20000 became 20k/50/40k/20k became 2/5/4/2.
Here is a breakdown of what they each mean:
-above_hispeed_delay: Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load.
-go_hispeed_load: The CPU load at which to ramp to the intermediate "hi speed".
-min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down.
-timer_rate: Sample rate for reevaluating cpu load when the system is not idle.
This is a good explanation that I wrote back on page 3038
-above_hispeed_delay: higher = better battery, lower = better performance. (100k is default)
-go_hispeed_load:.......higher = better battery, lower = better performance. (50 is default)
-min_sample_time:......lower = better battery, higher = better performance. (60k is default)
-timer_rate:.................higher = better battery, lower = better performance. (20k is default)
So Google's default is 10/5/6/2
. Lower numbers are all better for performance except min_sample_time (there higher is faster). So our goal is to find a sweet spot.
The default 10
is for "Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load."
So we think 10 is too high, but if you go too low, then you'll be using the higher freqs a lot more than you need and it will hurt the battery. So we are leaning towards 6
(60000) for above_hispeed_delay.
The default 5
is for "when the CPU hits X% amount of load, then jump to the hispeed_freq."
Again if this one is too low then it will cause the higher freqs to be used more often then they need, so we actually turn go_hispeed_load up a little bit to 7
The default 6
is for "how long do I wait before lowering the clock speed from what it's currently at."
So the lower we put this, the better battery will be. We're still trying to decide between 3
(30000) and 5
(50000). Osm0sis is getting more lag at lower levels, and finds the best performance mark at 5. So we turn min_sample_time down a little from stock to help with the battery.
The default 2
is for "wait this long before changing the clockspeeds from what it's at now."
While technically 2 sounds better because it's changing more often, Franco believes that by setting the timer_rate to be the same thing as the CPU sample_rate (which is preset at 30000), then that will make the CPU more efficient at switching. So we increased it from 2
(20000) to 3
So TO RECAP
: Using the stuff from above, Google's defaults for these settings are 10/5/6/2
and we are changing them to 6/7/3/3
(again, still testing that third number for the min_sample_time).
Does that make sense for everyone interested in following along? Any questions? Feel free to try out these settings yourself (the easiest way is with Franco's app or something like Trickster). We want as much feedback as possible on this.
The next kernel release will have the totally tweaked settings for everyone to test without having to change their own stuff.