Battery Life

Section by Anand Shimpi

At the start of our iPhone 4S battery life analysis I mentioned that I wasn't happy with the current state of our battery life benchmarks. The first incarnation of our smartphone battery life suite was actually a port of what I created to test battery life on Mac notebooks years ago. The Mac suite has evolved over time, and we've made similar evolutions to the smartphone suite - just on a less aggressive pace. The data on the previous page showed just how good Apple is at driving down idle power consumption, and through some software optimization it got very good at winning in our battery life tests. The data was accurate, but stopped being representative of reality.

Going into the iPhone 5 review I knew we needed to change the suite. After testing a number of options (and using about 16.5GB of cellular data in the process) we ended up on an evolution of the battery life test we deployed last year for our new tablet suite. The premise is the same: we regularly load web pages at a fixed interval until the battery dies (all displays are calibrated to 200 nits as always). The differences between this test and our previous one boil down to the amount of network activity and CPU load.

On the network side, we've done a lot more to prevent aggressive browser caching of our web pages. Some caching is important otherwise you end up with a baseband test, but it's clear what we had previously wasn't working. Brian made sure that despite the increased network load, the baseband still had the opportunity to enter its idle state during the course of the benchmark.

We also increased CPU workload along two vectors: we decreased pause time between web page loads and we shifted to full desktop web pages, some of which are very js heavy. The end result is a CPU usage profile that mimics constant, heavy usage beyond just web browsing. Everything you do on your smartphone ends up causing CPU usage peaks - opening applications, navigating around the OS and of course using apps themselves. Our 5th generation web browsing battery life test should map well to more types of smartphone usage, not just idle content consumption of data from web pages.

As always we test across multiple air interfaces (3G, 4G LTE, WiFi), but due to the increased network load we actually find that on a given process technology we see an increase in battery life on faster network connections. The why is quite simple to understand: the faster a page is able to fully render, the quicker all components can drive down to their idle power states.

The downside to starting with a new battery life test is that we don't have a wealth of older data to compare to. I did my best to run whatever we had access to at the time, but there simply aren't that many devices in these charts compared to our older ones. The data below may not look like a lot, but it's the result of running over 300 hours of battery life tests to not only understand how these devices do under load but also to find out the best test to use as the cornerstone of our new suite.

We'll start the investigation on WiFi. Where supported we used 5GHz 802.11n, otherwise 2.4GHz:

Web Browsing Battery Life (WiFi)

The iPhone 5 manages to match Apple's estimates, just breaking the 10 hour barrier. HTC's One X based on the Snapdragon S4 comes very close however. Although the One X is equipped with a larger battery, it also has a bigger screen and slightly more power hungry SoC to feed as well.

The iPhone 4S is measurably worse here. Keep in mind that the workload between all of the devices here is constant, if you use the faster performance on the iPhone 5 to browse more web pages or use your apps quicker then you may not see an improvement here. Worst case, you may even see a regression in battery life. That's the downside to this increased dynamic range in power consumption that we've been getting for two generations now.

Although this isn't the place for an Intel/Qualcomm comparison, it is important to note that the Atom Z2460 based RAZR i manages to last 17% longer on a single charge than the nearly identical, but Qualcomm S4 based RAZR M.

Next let's look at battery life when we switch to the cellular networks:

Web Browsing Battery Life (3G/4G LTE)

The non-LTE phones see a sharp drop in battery life. At least at 28nm the slower air interfaces simply have to remain active (and drawing power) for longer, which results in measurably worse battery life. Again, the thing to be careful of here is there's usually a correlation between network speed and how aggressive you use the device. With a workload that scaled with network speed you might see closer numbers between 3G and 4G LTE.

HTC's One X continues to do very well on LTE, coming the closest to the iPhone 5. I believe what we're seeing here is really Apple's idle power management building up a small but tangible advantage.

On 3G the iPhone 5 actually dies slightly quicker than the iPhone 4S, although run to run variance can cause the two to flip around in standings. Our iPhone 4 datapoint featured an older battery (both the 4S and 5 batteries were < 30 days old) so it's unclear how a brand new 4 would compare.

The RAZR i does quite well here on 3G. Despite being on a slower network, Intel's platform appears to do a good job of aggressively pushing down to idle. Once again Intel maintains about a 19% battery life advantage over the S4 based RAZR M. The RAZR i and the HTC One X do better than the iPhone 5 on 3G, which supports our theory of idle power consumption being a big reason the iPhone 5 does so well on faster networks.

While our new web browsing battery life tests do a good job of showing the impact of network, display and CPU on battery life, they do little to stress the GPU. Thankfully our friends at Kishonti gave us a shiny new tool to use: GLBenchmark 2.5.1 features a GPU rundown battery life test. The standard tests run Egypt and Egypt HD indefinitely until the battery life dies. We standardized on using Egypt HD at the device's native resolution with a 30 fps cap. All of the displays were calibrated to 200 nits as usual.

AT Smartphone Bench 2012: GLBenchmark 2.5.1 Battery Life

Here the iPhone 4S has a tangible advantage in battery life over the 5. The move to 32nm can only do so much, with many more transistors switching at a higher frequency the A6 SoC ends up drawing tangibly more power than the A5 in the iPhone 4S and delivers a shorter run on battery. The gap isn't huge (the 5 delivers 92% of the battery life of the 4S), but it's still a regression. The iPhone 5 does comparatively quite well here, despite being faster it's able to outlast the S4 and Tegra 3 based devices. The explanation is rather simple: capped to only 30 fps the iPhone 5's GPU likely has the ability to drop down to an idle state for a brief period in between rendering frames. The other devices can't hit 30 fps in this test and as a result have to run at full tilt throughout the entire benchmark. The RAZR i is the only exception to the rule, but it is considerably slower than everything else here (averaging below 8 fps) which could explain the very high result.

Moving on we have our WiFi hotspot test, which measures how long the device can last acting as a hotspot for a wirelessly tethered notebook. Our wireless hotspot test is entirely network bound by its definition. Here I'm including two sets of results, our most up to date LTE hotspot battery life tests as well as the chart we included in our latest iPad review. In both cases the iPhone 5 does relatively well, lasting just over 5 hours as an LTE hotspot on a single charge. In these tests, devices with significantly larger batteries come in very handy.

WiFi Hotspot Battery Life (4G LTE)

WiFi Hotspot Battery Life Time

Our final battery life test is our standard call time test. In this test we're playing audio through two phones (one of which is the phone being tested) and measure the call time until the battery is completely drained. The display is turned off, simulating an actual call.

Cellular Talk Time

The iPhone 5 falls just short of the 4S in our call time test. There's really no major improvement here as far as we can tell, although it's not clear how much additional work the iPhone 5 is doing with its additional noise cancelling features. If talk time is of the utmost importance to you, you'll want to look at some of the phones with much larger batteries. The Droid RAZR MAXX remains the king of the hill as far as talk time is concerned.

Battery Life Conclusions

If we take a step back and look at the collection of results from our battery life tests, the iPhone 5 can last anywhere between 3.15 and 10.27 hours on a single charge. Do a lot of continuous data transfers and you'll see closer to 5 hours, but if you've got reasonably periodic idle time you can expect something in the 8 - 10 hour range. In short, if you use your device a lot, don't be too surprised to see it lose about 10 - 15% of its battery life for every hour of use.

Now the question is how does the iPhone 5 compare to other devices? Compared to previous iPhones, the 5 has the ability to use a lot more power. If you're doing the exact same, finite length CPU/network intensive task on the iPhone 5 and any previous iPhone, chances are that the iPhone 5 will be able to complete the task and get to sleep quicker - thus giving you a better overall energy usage profile. Where things get complicated is if you use the faster CPU, GPU and network connectivity to increase your usage of the device. In that case you could see no improvement or even a regression in battery life.

Compared to other modern platforms the iPhone 5 should be competitive in day to day power usage, even compared to devices with somewhat larger batteries (~7Wh). The trick to all of this of course is whatever performance advantage that the iPhone 5 has coupled with lower idle power. Being able to complete tasks quicker and/or drop to aggressively low idle power states are really the only secret to the iPhone's battery life.

I feel like the days of ever increasing smartphone battery life are behind us. Instead what we'll likely see going forward is continued increase in dynamic range. Battery life could be better or worse and it'll likely depend heavily on your workload. Much like how we saw notebooks cluster around the same 2 - 5 hour battery life for years, I suspect we'll see something similar here with smartphones. The major difference this time around is the burden of a really large battery isn't as big as it is in a notebook. The RAZR MAXX is the perfect example of a still very portable smartphone that comes equipped with a huge (by today's standards) battery.

 

Increased Dynamic Range: Understanding the Power Profile of Modern SoCs Lightning 9-Pin Connector: Out with the 30-pin Dock Connector
Comments Locked

276 Comments

View All Comments

  • themossie - Tuesday, October 16, 2012 - link

    The manufacturer's charger uses a set of pull-up resistors connected between the various USB lines, to indicate that the phone can pull maximum current. Unfortunately, every manufacturer (and sometimes different phones) use different resistances.

    See http://electronics.stackexchange.com/questions/144... for a brief writeup.

    For what it's worth, I've only had this problem with iDevices and the HP Touchpad. I own circa-2011+ HTC, Motorola and Samsung phones, and they all work fine with every charger. My Droid 2 Global was my primary work phone until a few months ago, and works great with every charger. Not sure why your wife is having problems there.
  • crankerchick - Tuesday, October 16, 2012 - link

    "The non-LTE phones see a sharp drop in battery life. At least at 28nm the slower air interfaces simply have to remain active (and drawing power) for longer, which results in measurably worse battery life. Again, the thing to be careful of here is there's usually a correlation between network speed and how aggressive you use the device. With a workload that scaled with network speed you might see closer numbers between 3G and 4G LTE."

    Perhaps you all could devise a test for this? Something like, change your LTE and 3G tests, where you decrease the time between page loads for the LTE test, to simulate doing more browsing since the pages load faster? One data point on this, with a reasonably selected change in page load duration, would be very helpful now that we have this very interesting dynamic clearly visible.

    That said, as always, I appreciate the reviews presented here. Always thorough with lots of information to chew on beyond specs and "user opinion on user experience."

    Just wish the reviews didn't take so long, but they are always worth it in the end.
  • TofDriver - Tuesday, October 16, 2012 - link

    Thanks for this awesome article. Gigantic work, we'll worth the wait.
    I've learnt so much.
    Would still appreciate it as an ebook, even after the web reading!
    Seems like you're perfectionists who love to push limits... To me it does resonate with the team who designed the reviewed product.
  • name99 - Tuesday, October 16, 2012 - link

    "Another potential explanation is that the 3-wide front end allowed for better utilization of the existing two ALUs, although it's also unlikely that we see better than perfect scaling simply due to the addition of an extra decoder."

    Remember the standard numbers. On this type of integer code:
    1/6 instructions are branch
    1/6 instructions are store
    1/3 instructions are load
    1/3 instructions are ALU
    This means the usual first throttling point i cache access, if you can only do one load/store cycle.
    If you limit your cache to one op/cycle, it's generally not worth going beyond 2-wide --- too often you're waiting on the cache.
    Once you widen your cache (usually, at this stage, by allowing simultaneous read and write per cycle) three-wide makes sense.
    Each cycle now (on ideal and some sort of "average" idealized code) you can now do some sort of combination of half a branch, 1.5 load/stores, and 1 ALU. Meaning that 2 ALUs (as long as they are not overloaded and also handling some aspect of the load/store) is enough for now.
    [Of course things never work out quite this ideal --- you have burstiness in operation types, not to mention delays. But the compiler should try to schedule instructions to get this sort of average, and likewise the re-order queues will do what they can to shuffle things to this sort of average. 2ALUs helps with the bursts, 3ALUs is overkill.]

    So I would say the primary important change made to go to three-wide in a way that is not a waste of time was to convert the L1 cache to dual-ported, supporting simultaneous load & store per cycle.
  • jiffylube1024 - Tuesday, October 16, 2012 - link

    I have to commend the Anandtech team for the great review! It was a long wait, but well worth it. The info on anodizing, the "Swift" CPU @ 1.3 GHz, camera performance, etc. was worth waiting for. This article, in my eyes, is a culmination of the Anandtech team's knowledge in the tech industry - deconstructing A6 to figure out what it's made of, discussing Apple's manufacturing capabilities, etc. Very informative and well written!

    I am always amazed at how many complaints (and petty platform wars) get exposed on the comment board. I certainly appreciate them when an article is poorly written, contains false information or outright lies, but with an article like this, the comments section seems shy of the effusive praise it deserves!
    ------

    On a slight tangent, I've enjoyed the first 8 Anandtech podcasts as well, and I have to say that I look forward to more non-iPhone related disucssion on future podcasts. The information was much appreciated, but for a tech site as broad as Anandtech, the first 8 podcasts have been VERY iPhone heavy in their content! Keep up the good work.
  • jamyryals - Thursday, October 18, 2012 - link

    I think you're right, it has been iPhone heavy, but the start of the podcast kind of lined up with the launch/review process. Let's be honest, it is a huge selling high quality device and it's treated as such. I have a feeling Brian and Anand will have a lot to say about all of the impending Nexii/WP8 when they come out this quarter.
  • krumme - Tuesday, October 16, 2012 - link

    Good to see reviewers apreciation of low light capabilities for the BSI sensor, reflecting real world usage. Oposite to a lot of uninformed stupid reviews on the net.

    Its exactly the same practical difference between s2 and s3 cameras. Big difference for real usage.

    All the mpix race must stop now. 8M is way to much for the quality anyway.
  • Zanegray - Tuesday, October 16, 2012 - link

    I love the level of analysis and attention to detail. Keep it up!
  • mrdude - Tuesday, October 16, 2012 - link

    Wow, what an article. Really fantastic read. The lengths you guys have gone to in this review is stunning, frankly. Well done. Although I'm no Apple fanatic, I must say that this is one of the better articles I've read on AT :)
  • Dennis Travis - Tuesday, October 16, 2012 - link

    Totally outstanding review. You guys covered everything. Thanks so much!

Log in

Don't have an account? Sign up now