[Galaxy S II Original Android Development] droidphile:
Thanks for the time, patience and instruments you took to find these things out and getting into a conclusion. After reading them all, I have these 'doubts' or counter points or opinions or whatever we call them.

Your findings summarized with my points indented inline.

Power draw at max load for each frequency = F * V*V equation is almost accurate while measuring.

Sure​

For 18 steps freq table, residency time per frequency are almost evenly spread out which means unlike a smaller freq table , highest frequencies need not be used much. This reduce unwanted power overhead of clocking the CPU higher than needed.

When there are more frequency steps, there are more transitions. So lesser time to do the actual work because of clocking up/down through multiple frequencies? I mean, the delay as a function of sum-of-sampling-intervals increases if we have more transitions. (ondemand based governors may not visit every step before clocking to the highest freq, nevertheless)​

No of steps doesn't affect Ondemand based governors since they tend to jump to highest frequencies too much.

But we have smooth scaling to control that behavior. And some of the Interactive based governors (except original interactive) may benefit from a shorter freq_table. They're not meant to jump to highest freq while coming out of idle loop but visit intermediate frequencies depending on the params. Since most them stay at a frequency for a minimum amount of time, with a bigger freq_table, sum of min_time_at_a_freq increases and this could result in dropped performance. Because it takes longer now to reach higher frequencies. GS3 defaults are something like 200, 500, 600, 700, 800, 900, 1000, 1100, 1200, 1300, 1400. But this freq steps are handled by 4 core aware default governor pegasusq​

Under light power draw conditions such as music play, there's 6% power savings for 100mv undervolt.

Not many frequency steps can afford 100mV undervolt each. Only highest frequencies and not 100,200, 500 etc. Tasks such as music play does not require that high frequencies. So UV may be worth a little, but not something to do risking stability. It would be better to underclock GPU to reduce screen-on consumption than UV CPU.​

As to 100 vs 200 mhz. Considering full load on each frequency, 100 is less energy efficient than 200. But when CPU is idling, 100 is better at power saving. Difference between their energy efficiencies due to time to hit didle states is very small.

In the Joules/Cycles equation, if voltages were to be kept constant (100&200 has comparable voltages), W /Ghz increases inversely with frequency that is why the German guy's results in androidlife forum. If CPU is idling (not performing downloads/BT transfers/music play, etc during screen-off) then it won't idle for so much time but just hit aftr and other didle states and eventually deep sleep. There's no CPU clocking in this scenario.​

No point in having screen-off cap frequency since didle will prevent CPU clocking. So race to idle has to be considered here and 800 mhz is sweet on W/Ghz efficiency.

500 is normally the next freq after 200 in the table and there should be a reason for this. 500 is energy efficient enough to perform screen-off tasks. Do we need the cap to be 800 to better suit race to idle. From 800 mhz onwards, the voltage increase is kinda steep. Static power consumption is more for 800 than 500. Anyway capping at 100-100 or 200-200 is non-sense. Some users still doesn't understand that. Atleast, let CPU breathe enough when screen wakes and be at 800mhz for a few ms immediately after waking from suspend. It has to be. Bootloader resumes at 800​

Since W / Ghz increase significantly after about 500 mhz, for multi thread task, it's better to have a task running at 500 mhz on two cores than 1000 mhz on once core. But problem is that governor should be aware of this - but it's not. Hotplugging should also be aware. It is. But doesn't work in co-operation with governor. Exynos 4412 would be better of with this condition since it uses asymmetrical frequency scaling.

I too agree with this. But we need a pegagusq modified for dual-core awareness to achieve this. ATM, we're better off with single core handling tasks until 800 and dual core handling tasks for higher frequencies. Static power consumption doubles when two cores are used - applicable only at high loads and not low loads. We assume, tasks requiring more than 800mhz loads the CPU good. Then advantage of using single core untill 800 and both cores for higher clocks are obvious.​

Conclusion - use 100 as minimum, 18 steps, undervolt, use aggressive threshold.

I still like 500 mhz as screen-on minimum because of snappiness and negligible excess power consumption than 200. Lesser no of frequency steps may be better, atleast with all our Non-MultiCore aware governors. I agree with aggressive hoptlug thresholds. That's what i have been using.​