[Galaxy S II Original Android Development] AndreiLux:
That's irrelevant to any measurements without having standardised power drawing benchmarks which will be constant in their load, but also varying, and having a measuring device being able to measure power draw in time, which I can't do with just simple multi-meters which only measure the current point in time. Nevertheless you can measure maximum load for each frequency, which I did and the results are not surprising as they conform with the usual f x V² formula and scale pretty much similarly to it.

Lower frequency will consume less power and that's about it. Anyone can check the residency times with SetCPU and see if it bring a benefit or not. Personally my residency times were spread out among the steps with the 18-step table which in theory would mean less power draw as you have a more fine-grained resource serving up the load and you reduce the power overhead of clocking the device higher than needed. Ondemand based governors do not care about the amount of steps as it scales dynamically to a target frequency and takes the nearest step to that frequency. I talked to Gökhan about it and I guess he'll make it to the default setting as I don't see any disadvantage of having it. The 4412 by default also has a fine-grained frequency table.

As for undervolting I wasn't able to properly measure any significant decrease in power under load, but that might be because of the rough measuring methods and fluctuating power draw under computation. If I set it up to finer-grained resolutions under lighter power draws as for example playing music, then I can measure a roughly 6% decrease in power draw for a 100mV undervolt.

Lastly, 100MHz does not use up more power than 200MHz and I've found that to be an incorrect statement from the part of the German author who did those measurements. It is true that if you solely compute something at 100MHz versrus 200MHz then it will take twice as long, and additional hardware being on during that time-period will grow as a percentage over the CPU, that is not a real-world situation because that's specifically why we have governors which scale up the frequency. In the case of where we are I/O bound or time-bound (playing music) all of that logic goes to the trash as we're not fully loading the CPU either way. The difference due to AFTR is very small and only in the 3% range when playing music with the screen off, nevertheless it is something and it does consume less. This is also valid for when the screen is on and idling away with no task to be done, clocking it less will consume less power no matter what. There's also no point in having any screen-off limiting frequency as deep idle will turn off clocking to the CPU when it is doing nothing so it is better to race to idle using an optimal W/GHz frequency, I've found that spot to be between at around 800MHz.

Another thing is that with increasing frequency the W/GHz goes up especially dramatically after 1000MHz so you want to keep yourself at lower frequencies whenever possible and where you are in a multi-threaded situation you will prefer to have two cores at 500MHz rather than one core at 1000MHz, the problem is that he governor needs to be aware of this, which at the moment it is not, and secondly that the hotplugging mechanism must also be aware of it, which currently it is, but it's not working in cooperation with the governor. We can only help this much and the best we can do is to properly port the Pegasus governor which does both these things, but a lot of work needs to be done on it. The 4412 here shines as it's reportedly using asymetrical frequency scaling for the CPUs which means that hitting the sweet spot is much easier.

tl;dr: use 100MHz as minimum, use 18 step, undervolt, use aggressive hot-plugging thresholds.