Huawei Honor 6 Review

Remark on Benchmark Cheating

Last year, I uncovered some of Samsung’s habits in manipulating benchmark applications by tweaking  SoC DVFS parameters and tipped off Brian who went on to publicize what ended up being a embarrassment for many vendors. We hoped this would discourage vendors from continuing the practice, and indeed, since then we’ve seen some improvement as Samsung, for example, has abandoned all tampering with benchmark applications. Josh recently pointed out at Huawei’s practices on the Ascend P7 and made it clear that Huawei wasn’t deterred from playing dirty. For the Honor 6, we see the same behavior.

You might ask yourself why I only mention this in the battery section as we already took a look at benchmark score of device. In the case of the Honor 6, Huawei doesn’t allow any higher DVFS states or enables additional cores for benchmark runs, but instead takes advantage of the kernel’s HMP parameters to try to improve scores. I already mentioned that setting the performance profile to “optimal performance” does little in actual gains and adversely affects battery life. While that profile uses threshold values of 75% up and 25% down, versus Smart’s (rightfully) conservative 90% up and 50% down, Huawei’s “optimization mechanism” automatically detects benchmarks and lowers these down to 30%/15%. The effect is that you might gain about half to a full frame per second in 3D benchmarks and a bit of a boost in CPU-spiky loads such as the 3DMark physics test. On the other hand, you completely and utterly destroy big.LITTLE’s power management scheme. This is especially visible in GFXBench's battery test where, if ran with the cheating mechanism in place, would drop the battery scores down by a staggering 20%.

I was a bit shocked at this because what Huawei has done here is detrimental and not worth the small boost in benchmark scores. I found that the mechanism detected all current popular benchmarking applications, but there's one extra addition I was baffled by: Chrome. Huawei forcefully sets the HMP parameters inside of Google's Chrome browser to equal the "Performance" profile in the battery settings, even if you have it set to the "Smart" profile. More intriguing is that the stock browser is not affected by this and retains the set parameters that the user chooses. We see this as a targeted attempt in trying to manipulate our (and other site's) benchmarking suites inside the browser as Chrome is chosen as an apples-to-apples environment for web tests.

In the end, it sadly seems that the only way to deter OEMs of including such mechanisms and avoid benchmark manipulation is to continue to having to report on it. Huawei's attempt is, bluntly said, just stupid, as they achieve nothing more than handicapping themselves in battery benchmarks.

As this article is also a SoC evaluation piece where we look into the technical aspect of the device, all benchmark tests were run without being affected by the cheating mechnaism. 

Battery life

While performing all battery tests we normalize the brightness of all devices at 200cd/m² to be able to compensate for display power discrepancies.

The Honor 6 lasted 10.7h on the Wi-Fi web-browsing test, which places itself quite competetively among other flagships such as the Galaxy S5 or HTC One M8. When you consider the device's 3000mAh battery which has a 200mAh advantage over the S5 and 400mAh advantage over the M8, then it ends up less efficient. The M8 is especially a good comparison device as it has the same size 5" 1080p screen, yet the Huawei Honor 6 only manages to trail it while having a 15% advantage in battery capacity.

BaseMark OS II's battery test is mainly CPU loading, and due to Huawei/HiSilicon's lack of a power budgeting driver for the Kirin 920 we see one of the lowest battery scores we've ever seen in recent smartphones. The Cortex A15's are simply running wild without any power limitations other than thermal limits. Of course you'd be hard to find any kind of real-world use-case where an application would load the device to such figures.

Anand had argued for 2+4 designs as "optimal" for big.LITTLE, where we would have only 2 big cores available in a SoC; I don't necessarily agree with that, as beyond the cost and increased die size of the chips there is no negative impact on the end-device. Cores can always be turned off, but can't be added. That theory does not work though when the software stack fails, and therein we see big.LITTLE's greatest weakness. The above graph is a perfect illustration of the impact that a misconfigured big.LITTLE SoC can have on a device. 

The GFXBench T-Rex battery test also the puts the Honor 6 among the bottom of current generation devices. Again, we go back to the platform power consumption figures to make sense of it: As theorized, the Mali T628 has roughtly half the perf/W of the Adreno 330 when normalizing for the same performance. The fact that the A15 cores are being fired up at all in GFXBench's very light CPU load doesn't do it any favor in terms of power. 

I'd like to mention that the "Battery Performance" chart we've used until now has been renamed to "Performance Degradation" to better describe what it represents as I've seen instances where people would confuse our chart with GFXBench's own "Long term performance" figure. The difference being that we measure the performance on the last run while GFXBench averages for the whole duration of the battery test.

The Honor 6 here behaves well in comparison to other devices. It's able to maintain its instantaneous 17fps performance figure until the end of the battery test. I think this is due the phone having quite good thermal dissipation charateristics. This also ties in with the bad battery life figure, the GPU doesn't throttle much if at all. I did extract the device's thermal policies, and we see that the GPU is only throttled in the second thermal throttling state, which is enacted when a sensor passes 47°C. I wasn't able to determine exactly which sensor this is, but it does not seem to be located on the SoC silicon as there we can see temperatures rise up to 75°C. Huawei running its thermal policy on an external sensor may also explain the lack of much thermal throttling on the device, as its dissipation is adequate enough that it never gets enacted very often.

Battery Charging

Integrated in its body, we find an embedded 3000mAh battery running a 3.85V chemistry. The actual capacity is a little bit higher as the typical figure is mentioned at 3100mAh. I also could see that the fuel-gauge has a capacity tracking mechanism, for this unit I saw it measure a value of 3050mAh. This is definitely a useful feature to have for tracking battery degradation. Many OEMs nowdays prefer to implement voltage tracking fuel-gauges as they are simpler and cheaper to implement, this is definitely a plus in favor of HiSilicon's own charger IC.

The device comes with a 5.0V 2.0A charger delivered. I didn't have any plug converter available to use the US style plug on the supplied charger so I used one of Samsung's 2.0A chargers. I could see no sign of any kind proprietary signalling and the device's drivers setup a charging rate of around 1750mA.

In the charging graph we can see where the device switches from its full charge rate to trickle-charging, which is around 80% of capacity or at the 75 minute charging mark. The power input from that point on steadily lowers itself in three stages until it reaches only about of 150mA of input current.

From zero to 100% the phone charges in a little over 2 hours, a pretty good figure for a phone with an embedded battery of its size.