Battery Life

Battery life remains one of the most important aspects of any mobile device. After all, you can’t really call something mobile if it has to spend most of its time connected to an AC adapter. As a result, battery life testing is one of the most critical aspects of our testing, and it’s something that we spend quite a lot of time discussing internally.

Before diving into our results, I want to start things off talking about testing methodologies. This year we're implementing an overhaul of our web browsing test for battery life, with the Galaxy S7 review being our first chance to deploy it. As far as our long-standing 2013 test goes, at a high level our 2013 test was relatively simple in the sense that it simply loaded a web page, then started a timer to wait a certain period of time before loading the next page. And after nearly 3 years it was time for it to evolve.

Internally, we’ve been discussing reasonable measures to push our web browsing test in new directions to both better represent real-world workloads in addition to ensuring that we’re testing more than just display power. For at least a few devices, it had already become quite evident that our old test was almost purely display-bound to such an extent that even video playback was more power intensive. Other issues that were raised both internally and externally included the fact that the test would not test aspects like CPU governor boosts upon touching the display, and that our test almost entirely ignored things like 2D drawing and display pipeline efficiency.

In recognition of these issues, we’ve spent the past few months working on a new test. In addition to new webpages that are exact copies of many popular websites today to better represent modern, real-world workloads, we’ve added a major scrolling component to this battery life test. The use of scrolling should add an extra element of GPU compositing, in addition to providing a CPU workload that is not purely race to sleep from a UI perspective. Unfortunately, while it would be quite interesting to also test the power impact of touch-based CPU boost, due to issues with reproducing such a test reliably we’ve elected to avoid doing such things.

However, we don’t take these changes lightly. While we’ve validated the workload for several devices, it’s important to emphasize that these results could change in the future as much of this data is preliminary. For the second part of the review I’ll be sure to revisit these results with an expanded dataset. Of course, other than the workload the device setup has been held constant across these tests by equalizing brightness to 200 nits and disabling all background sync to the best of my ability.

Web Browsing Battery Battery Life 2016 (WiFi)

As we can see in the results, the Galaxy S7 and S7 edge both do impressively well. One of the more interesting comparison points here would be against the latest devices like the Huawei Mate 8, which has the Kirin 950.

Our previous test was relatively display-bound so differences in SoC efficiency were often difficult to discern and often masked entirely, but here we can see an enormous spread that is almost entirely due to SoC efficiency. The Huawei Mate 8, which under our previous test seemed to be only slightly above the iPhone 6s Plus, has gained a noticeable lead in this test as the Kirin 950’s CPU efficiency is ahead the competition at this time, although it’s important to keep in mind that CPU efficiency is not the only relevant metric for an SoC.

Interestingly enough, the Galaxy S7’s battery life is almost directly scaling with battery size relative to the Galaxy S6. As we’ll see in the display section, the Galaxy S7’s display is pretty much identical to the Galaxy Note5 and S6, so it looks like the efficiency gains from the Galaxy S6 to the S7 are small if you look at the Snapdragon 820 variant.

Of course, the big question that I’m sure a lot of people are thinking is how the Galaxy S7 and the Snapdragon 820 compare to the iPhone 6s and 6s Plus. Unfortunately, due to timing constraints we weren’t able to get data for the smaller iPhone 6s, but looking at the iPhone 6s Plus relative to the Galaxy S7 edge it’s pretty obvious that there is a power efficiency gap between the two in this test. Despite the enormous difference in battery size - the Galaxy S7 edge has a battery that is 33% larger than the iPhone 6s Plus - the difference in battery life between the iPhone and Galaxy in this test is small, on the order of half an hour or 5-6%. This is balanced against a higher resolution (but AMOLED) display, which means we're looking at SoC efficiency compounded with a difference in display power.

Web Browsing Battery Life (WiFi)

In the interest of providing another data point and some validation of our testing results, I ran both devices through our old web browsing test to see what the results would be for something that should be display-bound. Here, it’s obvious that the Galaxy S7 edge holds a significant lead over the iPhone 6s Plus, although the use of a higher resolution display and an AMOLED display in a high-APL test means that the GS7e is using more power in this test as well. However, when you take these results with our new web browsing test, it becomes evident that a difference in power efficiency is growing as the load on the SoC grows. Similarly, despite the Galaxy S7 being neck and neck with the Huawei Mate 8 in our older test, it loses the lead in our new web browsing test.

Of course, I have caution that all of the data that we’re gathering for the web browsing test is still subject to change, but given the interesting data that it provides it’s important for us to include these results, as we’re reasonably confident that these results are accurate.

Overall though, it’s clear that the Galaxy S7 and S7 edge will have solid battery life, even if device efficiency isn’t quite on par with the very best that we’ve seen so far. An improvement of 15% is going to be noticeable if you upgrade from the Galaxy S6, and anyone upgrading from a phone with an SoC older than the Snapdragon 800/801 generation will see huge improvements here.

Introduction and Design SoC and NAND Performance
Comments Locked


View All Comments

  • jjj - Tuesday, March 8, 2016 - link

    As for battery tests, as long as you don't simulate a bunch of social, IM, news apps in the backgroud, you can't get close to good results when you got so many diff core configs.
  • retrospooty - Tuesday, March 8, 2016 - link

    "s long as you don't simulate a bunch of social, IM, news apps in the backgroud, you can't get close to good results when you got so many diff core configs"
    You have to have consistent methodology to test against other phones. The point is not to show what you might get with your particular social/newsfeed apps running, the point is to test against other phones to see how it compares under the same set of circumstances so you know which one gets better life.
  • jjj - Tuesday, March 8, 2016 - link

    Sorry but you failed to understand my points.
    It would be consistent ,if it is simulated.
    The point is to have relatively relevant data and only by including at least that you can get such data. These apps have major impact on battery life- and it's not just FB even if they were the only ones that got a lot of bad press recently.
    The different core configs - 2 big cores, 4 big cores in 2+2, then 4+4, 2+4+4, or just 8 will result in very different power usage for these background apps, as a % of total battery life, sometimes changing the rankings. Here for example, chances are the Exynos would get a significant boost vs the SD820 if such tasks were factored in.

    How many such simulated tasks should be included in the test is debatable and also depends on the audience, chances are that the AT reader has a few on average.
  • retrospooty - Tuesday, March 8, 2016 - link

    And you are missing mine as well... If you have a million users, you will have 10,000 different sets of apps. You cant just randomly pick and call it a benchmark. The methodology and the point it to measure a simple test against other phones without adding too many variables. I get what you want, but its a bit like saying "i wish your test suite tested my exact configuration" and that just isnt logical from a test perspective.
  • jjj - Tuesday, March 8, 2016 - link

    What i want is results with some relevance.
    The results have no relevance as they are, as actual usage is significantly different. In actual usage the rankings change because the core configs are so different. The difference is like what VW had in testing vs road conditions, huge difference.
    To obtain relevant results you need somewhat realistic scenarios with a methodology that doesn't ignore big things that can turn the rankings upside down. Remember that the entire point of bigLITTLE is power and these background tasks are just the right thing for the little cores.
  • retrospooty - Tuesday, March 8, 2016 - link

    relevant to who? I use zero social media apps and have no news feeds running at all until I launch feedly. Relevant to you is not relevant to everyone or even to most people. This site is a fairly high traffic site (for tech anyhow) and they have to test for the many, not the few. The methodology is sound. I see what you want and why you want it, but it doesn't work for "the many"
  • jjj - Tuesday, March 8, 2016 - link

    Relevant to the average user. I don't use social at all but that has no relevance as the tests should be relevant to the bulk of the users. And the bulk of the users do use those (that's a verifiable fact) and more. This methodology just favors fewer cores and penalizes bigLITTLE.
  • retrospooty - Tuesday, March 8, 2016 - link

    Its still too unpredictable. One persons Facebook feed may go nuts all day while anothers is relatively calm. This is also why specific battery ratings are never given by manufacturers... Because usage varies too much. This is why sites test a (mostly) controllable methodology against other phones to see which fares the best. I find it highly useful and when you get into the nuts and bolts, it's necessary. If you had a bunch of phones and actually started trying to test as you mentioned you would find a can of worms and inconsistent results at the end of your work...
  • jjj - Wednesday, March 9, 2016 - link

    "Its still too unpredictable" - that's the case with browsing usage too, even more so there but you can try to select a load that is representative. You might have forgotten that i said simulate such apps, there wouldn't be any difference between runs.
    Yes testing battery life is complex and there are a bunch of other things that could be done for better results but these apps are pretty universal and a rather big drain on resources.They could be ignored if we didn't had so many core configs but we do and that matters. Complexity for the sake of it is not a good idea but complexity that results in much better results is not something we should be afraid of.
    10 years later smartphone benchmarking is just terrible. All synthetic and many of those apps are not even half decent. Even worse, after last year's mess 99% of reviews made no attempt to look at throttling. That wouldn't have happened in PC even 10 years ago.
  • retrospooty - Wednesday, March 9, 2016 - link

    I think you are a little too hung up on benchmarks. It is just a sampling, an attempt at measuring with the goal to compare to others to help people decide, but what really matters is what it does and how well it does it. I find it highly useful even if not exact to my own usage. If unit A lasts 20 hours and unit B lasts 16 hours in the standard tests, but I know my own usage gets 80% of what standard is I can estimate my usage will be 16 hours on unit A and 12.8 hours on unit B (give or take). It really doesn't need to be more complicated than that since testing batteries is not an exact science, not even on PC/laptops as usage varies there just hte same. That is why there are no exact guarantees. "Up to X hours" is a standard explanation. It is what it is.

Log in

Don't have an account? Sign up now