[HTC One X] Shan89:
Guys who follow this guide and use it , Please leave us the feedback about your battery life and rom you used. It's gonna be easier for us to locate the best battery life RoM, Thx in advance ! Also rating the thread would be nice :)

And those who USE this guide but apparently *doesn't help them* please post a replay with what you did and what happened, your battery/undervolting , whatever that came out from this guide, theres a chance you didn't do something RIGHT so we can try and help out. THX !

ADDITIONAL INFO - UPDATE:

I tought it would be nice to add some info about schedulers , and governors so ppl better understand what they are and what they do

Update: added governor info

.

Update: added info about MpDecision and Cpu Quiet per request.

.

---------------------------------------------------------------------------------------------------

Governors:

- OnDemand Governor:

This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.

OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.

This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.

- Performance Governor:

This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).

- Interactive Governor:

Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.

Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.

However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.

Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.

- Suggestion : Use this governor (Interactive) for

GAMING

, it's the best when using Xm kernel for this purposes +deadline or Row scheduler.

- Smartmax

Long story short if you want crazy battery life USE this governor with either noop/sio/row governor, depending on what you want , read about schedulers under and chose what fits your needs.

- PMC ( Performance may cry )

ok so i made this governor based on Smartmax except it's heavily tweeked for better and maximum battery life you can get out of HOX.

- TouchDemand:

This governor pretty much do what the name says, boosts cpu freqs by touches, this one actually can be pretty great for battery life if you underclock the CPU imho and use max 2 cores, you can do that by doing this:

edit touch_min_cores under governor tuneables and set 2

Anyway i still prefer *SmartMax* for battery life. But up to you to test and find out.

As for other governors like : Conservative and powersave , i wont be adding info about them since i doubt anyone ever uses them , all they do is take more space in the list :P

-----------------------------------------------------------------------------------------------------------------------------------------------------

Schedulers:

- Noop:

This scheduler assumes I/O performance optimization will be handled at some other layer of the I/O hierarchy , on the more simple way this scheduler is MOSTLY used for battery life since it's slow - it raises freqs slower then other schedulers.

- Deadline::

This scheduler attempt to guarantee a start service time for a request It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

To make it more simple

this scheduler raises freqs much faster then noop and keeps them longer active then noop which means more battery drain ( not by much anyway ) and faster I/O as well the gaming should be the best with this scheduler.

- SIO::

- ( my favorite )

This scheduler in simple words is basically this

: It's a mix of noop and deadline schedulers , noop is more for battery while deadline is more for performance , and sio is perfect balance between them ^.^ to be more specific it's more like almost having noop+deadline activated at the same time.

- ROW::

ROW: stands for "READ Over WRITE* The ROW scheduler is in favor for user experience upon everything else (means it should make things stupidly smooth ),so that why ROW scheduler gives READ IO requests as much priority as possible. Usually it¡¯s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. == Even more speed.

The main idea of the ROW scheduler is // == If there are READ requests in pipe - it WILL dispatch them but don't starve the WRITE requests too much.

Also this scheduler is much better optimised for our phones since in the smart phones we use flash memory and not hard drives.

Finally : Think of this scheduler as a mix OF deadline+ Performance governor put in scheduler while you can use another governor e.g. Smartmax. It's quiet fast scheduler and even good for daily usage without much of impact on the battery life.

Hope this prevents the question about schedulers / governors and which one to use :)

And a tip: Sio scheduler should be

PERFECT

with smartmax governor for battery life + speed , in fact it's the best scheduler if you guys want speedy performance while saving the battery life.

-------------------------------------------------------------------------------------------------------------------

MPdecision:

MORE INFO >

For us mpdecision is a cpu hotplug system, which replaced the default nvidia hotplug system. It was written by showp1984(Dennis Rassmann).

It's more configurable, better for battery life, and much much better for gaming.

Cpu quiet:

- Cpu quiet driver regulates the cores by them acting more syncronized. they scale up n down in a more uniform fashion. therefore it gets better battery life without losing performance. You can't manage each core like with morrifics. so the cpu quiet driver is doing all the regulating. So the cpu quiet driver basically replaced hotplugging as far as cpu core management goes.

- In simple words it should give better battery life.