[Nexus S General] bedalus:
Spreadsheet of the Battery Drain Data

BATTERY DRAIN BENCHMARKS

VIDEO of how it's done! (Do NOT try it yourself!)

NEW: Lab study done by nathanson666 see here and featured on the XDA's portal and twitter here.

Summary of Results

#1 - With screen on, if the processor is Idle, 100MHz saves the most power.

#2 - Regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%. (Click here for explanation.)

For the instability introduced by UV, it seems a 2% increase in battery life isn't really worth it! REMEMBER rebooting uses so much power, a single one would more than undo any savings made by UV.

#3 - The most power saving governor is Ondemand. If you need a high performance governor, use smartassV2, which offers some battery savings.

#4 - This is one point that everyone ought to know, but I'm including because many people seem to believe in myths: if the screen is off, and the CPU is not active, neither deep idle nor UV will have any impact on battery life.

#5 - The matr1x kernel by mathkid95 mainly saves power through UV of the INT voltages. You may need to raise these if you have freezes/reboots with your phone (in addition to raising the ARM voltages). I found that a maximum of 1 mA can be saved through INT UV, regardless of whether the CPU becomes idle (or with screen off in deep idle), so this is a constant saving. However, it is a very small saving, and doesn't apply if the phone is asleep. Remember, reboots cost more juice than UV can ever save.

#6 - If you have an amoled display, black saves a great deal of power. After that, red. If you have a black and red theme, this is saving you power!

#7 - If you are determined to UV, I found that my phone would become unstable with UV settings that were fine when the battery was fully charged. So check what UV your phone can handle when your battery is nearly empty. Again I say: Because of the high likelyhood and massive battery drain that comes with a reboot, I highly recommend you DO NOT USE EXCESSIVE UV. Also remember, even with extreme UV, you will not increase battery life more than 2%

#8 - I found that with bluetooth or GPS preventing the TOP=OFF state, there was no additional power saving from Deep Idle, i.e. the TOP=ON state does not save power.

#9 - Kernels with the 65 fps hack will cause the screen to drain about 10% more power compared to the usual 56 fps.

#10 - Conservative does not save power! For further details and exceptions, refer to my new thread: here.

#11 - This is just general advice: if you are having very poor battery life, have you tried turning auto brightness off? And if you've got no reception, you might as well be in airplane mode, because searching for reception also eats battery.

#12 - If your phone can't handle OC (or UV for that matter) it's because components in general are built to cost, which means factoring in tolerances, and every chip is made as cheaply as possible within the specified tolerances. Outside of those tolerances, whether your chip can cope or not is unfortunately down to the whether you got lucky with the individual device that dropped off the manufacturing line.

ARM document on A8 fault tolerance: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babhjhag.html

In fact I measured how UV in particular can cause errors, and saw in action the A8 using MORE power to correct the errors. From my spreadsheet:

At 100Mhz

mV 1500	4.92mA

mV 950	2.83mA (default mV)

mV 800	2.58mA (UV saves some power)

mV 750	2.96mA (Extreme UV uses MORE power)

Same test but with Deep Idle enabled:

mV 1500	1.91mA

mV 950	1.49mA

mV 800	1.29mA

mV 750	1.49mA (Same result again but with DI enabled)

Referenced from my spreadsheet starting row 41.

Recommended reading: http://everything2.com/title/wafer+yield

Stock voltages for reference:

ARM

1000MHz @1250mV

800 MHz @1200

400 MHz @1050

200 MHz @950

100 MHz @950

INT

1000MHz @1100

800 MHz @1100

400 MHz @1100

200 MHz @1100

100 MHz @1000

Summary of Power States by tchaari (thanks!)

After research, and some explanation from Steve Garon, it is clear that Deep Idle & CPU Idle are two completely different things:

1) Three main CPU states are implemented in the standard android kernel: NORMAL, IDLE and SLEEP

2) Ezekeel added an intermediate 4th state: Deep IDLE. This saves more power but only when the processor has a background task to run

while screen is off

. Bedalus proved here that it really saves a considerable amount of power in particular cases (e.g. music playing when screen is off). A minority of users are reporting some slight instabilities with it, but they may in fact be caused by things other than deep idle.

3) The CPU IDLE backport is a replacement of the standard android kernel drivers used to put the CPU in idle/sleep states by the new ARM methods integrated in the linux 3.2 kernel. This backport is theoretically supposed to improve battery life (with just the basic 3 CPU states). It is 100% stable but no power saving has been shown either in bedalus' amp meter measurements, or Harbb's overnight drain tests.

Where did the other benchmarks go?

All ICS ROM Benchmarks: this thread

Kernel Features and Benchmarks: this thread

CPU Governors and I/O Schedulers: this thread

Power Saving Governors: this thread

Thanks to all the developers, and a big shout out to: Harbb for his dedicated testing; tchaari for his motivation, great ideas and inspiration; jcolinzheng for the idea to test Deep Idle at fixed frequencies (genius); aLNG for links to interesting and useful articles; Steve Garon for demystifying esoteric kernel technicalities and his excellent kernel itself; everybody else who helped; and of course Ezekeel for making Deep Idle work, and for a stimulating debate!