[Galaxy S II Original Android Development] cmd512:
Wow, who put you on a high horse and decided to call you Napoleon? Given you feel you're the master of all things ondemand related, I'll explain this plainly so someone... and in quoting you, so "plain stupid"... can understand. I'll try keep my response simple for you to follow:

1) 25ms is simply how often it polls to see what the governor's behavior should be. While that means it will ramp up quickly, it also means it will ramp down quickly. Unfortunately, the downside to that is oftentimes ramp down so quick that it will cause stuttering. IF you think that, in your everyday use of swipes between screens and launches that one 25ms step can't down throttle you, then you're even duller than I previously imagined.

And yes, I've experienced these micro-stutters, and I don't care for them.

So in other words (given I seem to need to translate this for you to understand), I want the high frequency polling so that my device will ramp up when it needs to, but I needed something to keep it from throttling down too quickly. Move onto #2 when your brain is ready to proceed.

2) Downsampling factor only applies when the device is at max frequency, which in my case would be 1400MHz. Basically, I wanted it to hang at max frequency given the high sampling_rate I set so that when my device is doing something intensive needing max power, and I don't want it to suddenly throttle down when it gets polled at 25ms. Yes, this is a bit over the top, but the 1 second hold at max is NOTHING as I've seen it in Voltage Control quickly throttle down to 200MHz when device is idle with screen on.

This is ONLY a multiplier of your sampling_rate. So while 40 seems high, 40 x 25ms is still only 1 second. I can live with my device holding at max frequency for a whole second before appropriately throttling down on me if it means no sudden decreases in frequency. Again, my arch nemesis is micro-stutters, and this completely eliminates them.

In fact, sampling_down_factors of 100+ are often discussed... and I quote:

"In fact, one main goal of the ondemand governor is to switch to max frequency as soon as there is a cpu activity is detected to ensure the responsiveness of the system.

If your idle activity is made of burst of cpu activity and your sampling period is small, your system will switch between the highest and the lowest frequency.

At the contrary, the conservative governor modifies the frequency in a step by step manner."

Discussing an Intel system, but related to what I'm (unfortunately) trying to explain to you: https://bugs.launchpad.net/ubuntu/+source/linux-ports-meta/+bug/862785

My settings completely eliminate this constant switching from highest to lowest when frankly, I don't want it to as it doesn't translate to what I'm doing with the system in real life.

3) 95% threshold? HAH, if you can claim you get 0 stutters, you're flat out lying. If I ever get bored enough to actually make a video just to prove you wrong, I'll do just that. But for now, the fact that I KNOW your settings will result in stutters in everyday use is enough for me.

4) I really could give a rat's behind on what you recommend or what you think is best. I can concur that what works for you works for you, but notice how I'm not assuming your settings are junk. Just don't go around assuming you know everything, because you clearly don't.

I use my device heavily all day long for work... I'm talking productivity, conference calls, etc. And, I do charge every night when I go to sleep. So yes, my settings are NOT for extreme battery life. However, with my settings, when I use my device, it performs at 110%. This is a smart phone, and I want it to perform at peak when I need it to, and when I'm not using it or using it lightly, I want it to conserve. These settings fit the bill for me as I've been using these settings all day and still have 33% battery life left... when I would have had less than 20% with lulzactive.

Enjoy your device, and maybe brush up on your knowledge before you go swinging your **** around.