In Depth Nexus S Battery Study Brings About Surprising Conclusions


It is a rare feat when someone goes out of their way to truly study their device. It is rarer still when that study warrants relevant information that’s beneficial to other users.

XDA Senior Member bedalus has performed what amounts to a case study to test battery usage with a variety of kernels and battery features such as under-volting and various levels of idling for the Samsung Nexus S. The study is rather extensive and tests the phone under a variety of conditions such as screen on/off, while music is playing, with different governors and even CPU Clock frequency. Of course, bedalus wanted to make a special note. Do NOT try this at home, it could be very damaging to your Nexus S.

The results were rather startling. As it turns out, many of those techniques and features that many people use don’t actually work. Says bedalus:

The main shock was that Deep Idle did not work as intended. There are three forms of Deep Idle: the CPU Idle backport from kernel 3.2, Eugene’s Deep Idle, and Ezekeel’s. All three were tested, and no battery saving was measured. I also tested Deep Idle in Carbon (Jonathon Grigg’s ICS themed Oxygen 2.3.1, android version 2.3.7, gingerbread) using Ezekeel’s last kernel for gingerbread, and that showed no battery saving either. With the option for ‘Screen Off Maximum Frequency’ set to ON, the battery drain was higher (both in ICS and GB).

What that basically says is, with all respect to the developers who worked hard on these features, that none of these features actually help the battery. For all intensive purposes, a user might as well not have them. This has a number implications, but none more important than giving said developers statistics with which to base their next release. Why continue working on something that has been proven not work? Or, perhaps the better question, is that is there a way to make these features work better against the stock settings?

Please note that just because one feature on a kernel/ROM/mod doesn’t work doesn’t make that piece of work bad, it just means there’s a feature that doesn’t work. At least they don’t cause higher battery drain. In the poll posted in the thread, voters have shown that they do save power with the Deep Idle. However, there are variables that cannot be measured, such as what each user has otherwise installed and how they use their phone, so it’s worth taking note but does not disprove the research.

Continuing on his observations, bedalus also noted:

If you use NStools to undervolt, don’t bother. No gain to be had from undervolting either ARM or INT voltages. I tested this to the extreme. Check the spreadsheet, near the bottom. (Tested in both ICS and GB).

So that puts that to rest. Much like Deep Idle, there are users who claim undervolting saves them battery. However, the numbers are pretty clear that it doesn’t, so it can be assumed that, once again, there are other variables at work such as apps running and how the user actually uses their device.

This leads us to observation number three, as bedalus says:

The other main result was that mathkid95′s matr1x kernel offered the greatest battery saving. However, it should be noted that I have suffered reboots while performing other benchmarks on this kernel, and the solution was to raise voltages. (It’s not as if doing that is going to drain your battery faster.)

If you were looking for a kernel that saves battery, then this one is it. XDA Recognized Developer mathkid95‘s kernel has shown, by way of statistics, that is does, in fact, have the highest battery saving. Of course, battery saving isn’t the only reason users choose a kernel. Some may want performance, others stability, but for those who need that extra battery capacity then mathkid95′s is the one that survived all the testing.

And the final observation made by bedalus:

If you have an AMOLED display, black saves the most power, then red.

This is something that many users could have already guessed, as black has been the go to color for battery saving for a long time. However, it’s nice to finally have some numbers to put to the belief. And to those running black and red themes, bet you never thought that theme was saving your battery did you?

All of these observations are backed up with a very impressive and easy to read spreadsheet. It’s a Google Documents spreadsheet, so be sure you’re logged in to Google before attempting to view it, as it will probably alleviate any problems, but if you have five minutes then it’s highly recommended you check out the original spreadsheet. There is a boat load of useful information in there and shows all the results that bedalus has come up with and all the mentioned, and unmentioned, parameters he tested. This also includes Quadrant Standard and AnTuTu benchmark tests.

Along with the spreadsheet and detailed explanation, bedalus was also kind enough to post two videos showing users exactly how he tested these processes and how he read the results. This not only proves he actually did the research, as opposed to blowing smoke, but also gives the experts and average users alike a chance to see how it was done. In an internet community, if you don’t post a screen shot, it didn’t happen. For bedalus, he posted videos, that’s a step up.

For anyone who wants to read the full coverage of the Nexus S battery consumption research, they can do so in the original thread. The first couple of posts explain the parameters of the testing and the conclusions. Post three covers how he tested the battery, including hardware specifications and how/why he did what he did. Post four includes further explanation for test methods and plans for future testing.

The best part about bedalus’ work is that there is a plan to continue testing using better equipment and more parameters. So it is definitely worth it to keep tabs on the thread as there will eventually be more, not to mention more accurate, information to be had.

And, as bedalus will have you note:

REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.

Samsung confirmed this morning in an email to PCMag that the smartphone maker will not be hosting a press conference at Mobile World Congress, the wireless industry trade show at the end of February.

As you can see, it does pretty much work (the choppy FPS is caused by our recording app). The best part, though, is the quality of the graphics in this unofficial port clone (it was developed using Unity, and since Portal is not open source, "clone" is a more correct term). Everything looks pretty great (except the portals, they haven't quite figured that part out yet), and the controls work decently, too. Will this game ever get off the ground? It's hard to say - this is a Russian piece of software, so it's unlikely VALVe will be able to do anything to stop it, if development continues.