[Samsung Galaxy Nexus] szucsgf:
I’d like to share a technique which has greatly improved my Galaxy Nexus’ battery life without undervolting. The technique was inspired by Blackcrx in a conversation that began here:

http://xdaforums.com/showthread.php?p=38610656&highlight=voltage+1350#post38610656

Since following that conversation I did additional research and testing to arrive at my results.

The settings I adjusted are:

Governor = Interactive

Min CPU = 180000

Max CPU = 1060000

hispeed_freq = 525000

My results were 1d 6h 50m uptime with 3h 35m on-screen time. Prior to adopting the settings above I averaged 18h uptime with 3h on-screen time. With my new settings in 18h uptime I could have achieved well over 4h on-screen time from a battery cycle.

By underclocking only one step below stock (which is 120000) and lowering hispeed_freq three steps below stock (which is 920000) I’ve managed to nearly double my battery life without any noticeable change in performance. My phone is as smooth and fast as ever. I’m using Vanir ROM and AK Kernel.

If you’re just interested in improving battery life without knowing why I found these particular settings to be the best you can stop reading here.

To understand why I selected the settings above, it is necessary to understand the power equation. The Power (P) used by your device is the product of Capacitance (C), Voltage (V), and Frequency (f):

P = (C)(V^2)(f)

Note that Power is a function of Voltage squared, so changes is voltage will have the greatest effect on battery life of these three factors. Capacitance is a constant which is determined by the hardware and is therefore out of our control, so we’ll ignore it by using a new equation:

P* = P/C = (V^2)(f)

This equation is the key to my results, and gives a simple way to quantify the effect that a change in frequency has on your battery life.

I’ve included a table which shows all the frequencies available, the voltages at which they operate, and the resulting P* value at that frequency.

These voltages were determined by setting Min CPU to the various frequencies found in the table and checking voltage in TrickerMOD at the bottom of the Info tab. These are the voltages used by your device when Smartreflex is on.

Note that there is always more than one frequency operating at a particular voltage. 180000-230000-350000-525000 all operate at 820mV, 700000-810000 operate at 1000mV, 920000-1060000 operate at 1090mV, and 1200000-1350000 operate at 1230mV.

Max CPU

Since underclocking by one step to 1060000 results in operating at a much lower voltage the difference in battery life is significant. At 1200000, P* = 1,786,080. At 1060000, P* = 1,259,386. This theoretically leads to almost 30% less power used at Max CPU:

(1,259,386 - 1,786,080)/1,786,080 = -29.49% (See "ADDITION" below of a necessary adjustment to this figure.)

with less than 12% lowering of Max CPU frequency:

(1060000 - 1200000)/1200000 = -11.67%

In other words, a relatively small decrease in Max CPU compared to the large decrease in power used at Max CPU. Your experience in terms of performance will be essentially unchanged while your battery life should be significantly improved, as mine was.

Hispeed_freq

I used the same reasoning to lower hispeed_freq two steps, from 810000 to 525000, to take advantage of the significantly lower voltage used (1090mV to 820mV). Doing the same math as with Max CPU above:

Change in P* = -67.7%

Change in f = -42.93%

Once again, a very large drop in P* compared to the drop in CPU frequency. In my first experiments I just lowered hispeed_freq one step to 810. However I noticed the CPU was spending a lot of time at 525. Since the CPU seemed to be performing many tasks at 525, I thought "why would I make it to immediately scale to 810 when half the time it will just scale down from there?". So I chose to take advantage of the next drop in voltage at 525 and have not noticed a decrease in performance.

Min CPU

I simply keep Min CPU at 180000, the lowest possible.

I used this reasoning to significantly improve battery life while maintaining performance. Of course one could use this reasoning for other goals. For example to overclock in the most efficient manner (i.e. without jumping to a higher Voltage), as Blackcrx does.

I would greatly appreciate if anyone would 1) comment on my reasoning, whether confirming it or giving reasons why it is incorrect, and 2) experiment according to your own goals and share your experience. I am very interested in maximizing processor efficiency and I welcome more knowledgeable people correcting me if I’m wrong!

Here are my other TricksterMOD settings just for the record:

TCP: Cubic

Scheduler: fiops

Read Ahead Buffer: 2048

Max Screen Off: 525000

Wifi High Performance: ON

Multicore Power saving: 2

High Performance Sound: ON

Headphone Volume Boost: 1

Vibrator Strength: 100

GPU: 384

ZRAM: OFF

Colour Profile: anarkia

All else stock.

I will test another battery cycle with heavier usage. Then I will use the same settings with Lean kernel to compare. I will post all my results on this awesome thread created by Charmacas:

http://xdaforums.com/showthread.php?t=2160723

My thread on how SmartReflex works: http://xdaforums.com/showpost.php?p=39686713

ADDITION (March 10, 2013):

As pointed out in this thread by nodens76 and androo45 (http://xdaforums.com/showpost.php?p=38782438&postcount=32 and http://xdaforums.com/showpost.php?p=38822876&postcount=45), my original calculations don't take into account the effect of longer rush-to-idle. That is, the CPU can finish tasks faster at 1200 than at 1060. So it will spend more time at Max CPU and take longer to get back to Min CPU when Max CPU is set at 1060 compared to 1200. Therefore the power savings aren't the approximately 30% I calculated above.

Since frequency (how many tasks the CPU can complete in one second) is the inverse of period (how long it takes the CPU to complete one task), the effect of a longer race-to-idle should be easy to calculate. Here's my attempt, which I hope is appropriate:

Period at 1200 = 1/1200 = 0.000833333

Period at 1060 = 1/1060 = 0.000943396

Increase in period = (0.000943396 - 0.0008333333)/0.000833333 = 13.21%

So the actual power savings at Max CPU might be more like:

[1,259,386(1.1321) - 1,786,080]/1,786,080 = -20.17%

with less than 12% lowering of Max CPU frequency:

(1060000 - 1200000)/1200000 = -11.67%

This is very close to the approximately 21% that nodens76 suggested is the true power savings.

I assume this adjustment for the longer race-to-idle is only required for Max CPU and not for hispeed_freq. This is because if from hispeed_freq the CPU decides it needs more speed it can just scale up in frequency, until it reaches Max CPU.