Read First: The HTC One M9 Review Part 1

A good amount of time ago, we posted part one of our HTC One M9 review, which gave a good idea of some critical aspects of the One M9’s performance and design. Unfortunately, due to HTC’s last minute software changes there was a need to redo some of our testing as the changes were quite significant for some key aspects of the user experience, which were effectively any situation where the SoC was in a thermally throttled situation and overall camera performance. I’ve finally finished redoing our testing of the One M9, so we can finish the review and get the full picture of the One M9’s performance. Normally, we’d start by discussing the design of the phone, but much of the review has already been finished with part one. Instead, we’ll start with sustained battery life tests.

Battery Life Continued

As previously detailed, our sustained battery life tests either strongly stress the CPU or GPU. For our GPU tests, we use GFXBench 3.0’s sustained GPU test, which runs the T-Rex benchmark on the display at its native resolution for an infinite rundown test. We didn’t have the modified test to present for a comparison between the two software builds, but we can get a pretty good sense for the changes that have occurred for final shipping software.

GFXBench 3.0 Battery Life

GFXBench 3.0 Performance Degradation

As one can see, the One M9 delivered somewhat impressive sustained performance with the pre-release build, but this resulted in almost dangerous skin temperatures and poor battery life on the order of 1.73 hours. The new update produced acceptable skin temperatures, but frame rate drops rather dramatically as skin temperature rises. The end performance actually ends up being quite similar to the One M8, but performance during the test is much higher than what we saw on the One M8.

BaseMark OS II Battery Life

BaseMark OS II Battery Score

In the Basemark OS II test, we can see that the One M9 seems to perform poorly. One might be able to argue that the A57s provide more performance, but simple logging shows that past the first 20 minutes the A57 cluster is either shut down or throttled to the minimum clock state, although the A53 cluster manages to stay at 1.56 GHz for the duration of the test. For reference, the One M8 manages to keep the active CPUs at around 1.5 GHz throughout the test.

PCMark - Work Battery Life

While Basemark OS II and GFXBench function as power virus tests, I wanted to get a good idea of performance somewhere between these rather extreme tests and the mostly display-bound web browsing test. To do this, I tested a few devices against PCMark’s work battery life benchmark, which shows that the One M9 seems to perform comparably when compared against the One M8. There is a noticeable difference in performance, but the gap isn’t all that big when compared to the M8. More interestingly is that the battery temperature sensor (which isn't necessarily on the battery) gets noticeably higher than the M8, on the order of 5-10C higher.

It’s a bit frightening to see that the gap in performance that we saw with the web browsing test remain. The effects of panel-self refresh would be greatly reduced in these short-running tests, so the differences here are mostly due to the SoC. The level of throttling I’ve seen here is pretty much unprecedented, which doesn’t help with the issue. Overall, the performance of Snapdragon 810 here is bad enough that I would genuinely consider Snapdragon 805 to be an improvement. I can’t help but wonder if this was inevitable though, as leaked roadmaps in the past suggested that Snapdragon 810 would’ve been a very different SoC.

Camera Architecture and UX
Comments Locked

127 Comments

View All Comments

  • blanarahul - Tuesday, April 7, 2015 - link

    This will be a big problem going forward. Look at Mali T760MP6 on Exynos 5433. Going from 600 MHz to 700 MHz requires a tremendous amount of power. The GHz race could only work till 28 NM it seems. The only solution to improve performance/watt is to go wider.
  • TylerGrunter - Tuesday, April 7, 2015 - link

    I can't completely agree with your statement. The issue is that to go to 20nm they should have used FinFet to reduce the current leakage at high frequencies. They didn't (neither GF, Samsung or TSMC) and that has been the consequence: 20nm doesn't scale well at high frequencies.
    Intel has managed to clock cores till 3.5 GHz already in 14nm FinFet, so with FinFet there shouldn't have the same issue.
    By the way: I suspect NVidia had the same issue with the Denver cores and therefore they decided to go with A57 at 20nm.
    But I agree that in most of the cases they should go wider (or increase IPC in some other way) in mobile. Even the A57 has only 3 paths.
  • Frenetic Pony - Tuesday, April 7, 2015 - link

    Sure, but apparently finfet is harder for everyone that's not Intel. But Samsung, GloFo, and TSMC all now have Finfet up and running. At 3 years behind Intel for a similar enough feature density, and considering how hard Intel found shrinking their feature size once again, one wonders how long it will take these other 3 to get to a new process node after this. > 2 years is my guess.

    Alternate materials with less voltage leak and higher electron mobility are really, really needed and I don't understand why more isn't invested into them, other than uninformed executives making the decisions for future investment rather than engineers. 10nm (as in 2 actual feature size shrinks from 22/20nm) is doable with optical tools. But beyond that there are multiple new tools and techniques that need to fight vastly increasing complications and quality needed. The end of Moore's law is indeed within sight.
  • frenchy_2001 - Tuesday, April 7, 2015 - link

    10nm is actually really hard.
    Either you do quad patterning (write 4 times slightly offset), which is less than trivial (you cannot make each step too wide and you will chip at it to prepare before the next) or you jump to extreme UV, and no one is there yet.
    Intel has been spending a lot of time and money in solving those problems for years and they are STILL not solved...
  • KiretoX - Monday, April 6, 2015 - link

    Page 2 table, M9 read camera... OV4688... not Toshiba?
  • Andrei Frumusanu - Monday, April 6, 2015 - link

    Fixed the table, thank you.
  • Darkito - Monday, April 6, 2015 - link

    RIP HTC
  • nathanddrews - Monday, April 6, 2015 - link

    Rip in peace, HTC.
  • blanarahul - Tuesday, April 7, 2015 - link

    Dafuq?!
  • Armourcore9brker - Monday, April 6, 2015 - link

    You should try setting the camera the way that was done in this XDA thread: http://forum.xda-developers.com/showpost.php?p=598...

    It seems like setting the ISO too high is causing a lot of the problems.

Log in

Don't have an account? Sign up now