As alluded to in our Nexus 6 review, our normal storage performance benchmark was no longer giving valid results as of Android 5.0. While Androbench was not a perfect benchmark by any stretch of the imagination, it was a reasonably accurate test of basic storage performance. However, with the Nexus 5 on Android’s developer preview, we saw anywhere between 2-10x improvement to Androbench’s storage performance results with no real basis in reality. It seems that this is because the way that the benchmark was written relied upon another function for timing, which has changed with Android 5.0.

While we haven’t talked too much about AndEBench, it has a fully functional storage test that we can compare to our Androbench results. While we’re unsure of the 256K sequential and random read results, it seems that the results are equivalent to Androbench on Android 4.4 when a 1.7x scaling factor is applied. However, AndEBench results should be trustworthy as we saw no difference in results when updating devices from 4.4 to 5.0. In addition, the benchmark itself uses low level operations that shouldn’t be affected by updates to Android.

Androbench Results - Valid vs. Faulty
  Nexus 5 Androbench Results on 4.4 KitKat Nexus 5 Androbench Results on 5.0 Lollipop
Random Read 10.06 MB/s 27.70 MB/s
Random Write 0.75 MB/s 13.09 MB/s
Sequential Read 76.29 MB/s 182.78 MB/s
Sequential Write 15.00 MB/s 47.10 MB/s

As you can see, the results show a degree of improvement that is well beyond what could realistically be accomplished with any sort of software optimizations. The results for the random write test are the most notable, with a result that suggests the performance is over 17x faster on Android Lollipop, which could not be the case. This required further investigation, and  it's one of the reasons why we were hesitant to post any storage benchmarks in the Nexus 6 review.

The other factor affecting the results of the benchmarks on the Nexus 6 specifically is Android Lollipop's Full Disk Encryption (FDE). Android has actually had this ability since Android 3.0 Honeycomb, but Lollipop is the first time it's being enabled by default on new devices. When FDE is enabled, all writes to disk have the information encrypted before it's committed, and all reads have the information decrypted before they're returned to the process. The key to decrypt is protected by the lockscreen password, which means that the data should be safe from anyone who takes possession of your device. However, unlike SSDs, which often have native encryption, eMMC has no such standard. In addition, most SoCs don't have the type of fixed-function blocks necessary to enable FDE with little to no performance penalty.

As a result, we've observed significant performance penalties caused by the use of FDE on the Nexus 6. Motorola was kind enough to reach out and provide a build with FDE disabled so we could compare performance, and we've put the results in the graphs below. For reference, the Nexus 5 (Lollipop) numbers are run using Andebench, while the original values are read out from Androbench on Android 4.4. The Nexus 5 is also running without FDE enabled, as it will not enable itself by default when updating to Lollipop via an OTA update.

Internal NAND - Random Read

Internal NAND - Random Write

Internal NAND - Sequential Read

As you can see, there's a very significant performance penalty that comes with enabling FDE, with a 62.9% drop in random read performance, a 50.5% drop in random write performance, and a staggering 80.7% drop in sequential read performance. This has serious negative implications for device performance in any situation where applications are reading or writing to disk. Google's move to enable FDE by default also may not be very helpful with real world security without a change in user behaviour, as much of the security comes from the use of a passcode. This poses a problem, because the users that don't use a passcode doesn't really benefit from FDE, but they're still subject to the penalties.

When the Nexus 6 review was published, I commented that there were performance issues that weren't present on the Nexus 5 running Android Lollipop. Many users commented that the FDE may have been to blame. Like I mentioned earlier, Motorola provided us with a build of Android with FDE disabled. Unfortunately, I haven't noticed any improvements to many of the areas where there are significant frame rate issues such as Messenger and Calendar. I speculated in the Nexus 6 review that the performance issues may simply be the result of insufficient GPU performance or memory bandwidth to drive the QHD display. 

To me, the move to enable FDE by default in Lollipop seems like a reactionary move to combat the perception that Android is insecure or more prone to attack than iOS, even if that perception may not actually be accurate. While it's always good to improve the security of your platform, the current solution results in an unacceptable hit to performance. I hope Google will either reconsider their decision to enable FDE by default, or implement it in a way that doesn't have as significant of an impact on performance.



View All Comments

  • jruhe - Thursday, November 20, 2014 - link

    I wonder what the "Qualcomm hardware cryptographic engine" (qce & qce40 & qce50) in Snapdragon SoCs is good for. Reply
  • Krysto - Thursday, November 20, 2014 - link

    No idea, but I heard Google didn't want to use Qualcomm's drivers for it. Maybe because they couldn't have made them open source - or who knows. Reply
  • przemo_li - Friday, November 21, 2014 - link

    That would be first!

    Reality may be smplier.

    Embeded industry make poor drivers. Google is trying to fix that mess... by using as many apis as possible (so poor state of drivers is clearly visible and manufacturers NEED to take action).

    So maybe this time they just said. "*Facepalm* That's WHAT?", and started their own.

    Alternatively, Google wants unified capabilities for their crypto chips, and rolled sleeves them-selfs.
  • aden32 - Thursday, November 20, 2014 - link

    Too bad doing the encryption/decryption on the CPU will cause higher power consumption during disk I/O. Of course, there are people who don't trust black box encryption accelerators so that could be a reason. Then again, the ARM world is full of closed proprietary hardware and software. Another one won't make much difference. Reply
  • Entropy512 - Monday, November 24, 2014 - link

    It is either not being used, or is being used improperly by Google on the Nexus devices:

    <link to codeaurora removed as anandtech thinks it's spam, even though it's a link to CodeAurora's gitweb, specifically to the dm-req-crypt implementation within the vold repo>

    AOSP (and the Nexus devices) don't have dm-req-crypt support in vold. That's inefficient since it leads to (my guess) a DMA setup and teardown for every 512 bytes of data.

    This isn't the first time Google has left out Qualcomm performance features. Qualcomm's open-source bionic Krait optimizations have been in Qualcomm's CAF reference repos with an Apache license since 4.1 or 4.2 or so - Google still hadn't integrated all of them as of 4.4

    Qualcomm also has a bunch of other optimizations that are closed-source so it's understandable that Google wouldn't use them, but the Krait bionic optimizations and lack of dm-req-crypt both appear to be Google ignoring opensource components that have a very high performance payoff.
  • tipoo - Thursday, November 20, 2014 - link

    Wow, that performance loss on the 6 should definitely have been considered unacceptable for the Nexus 6. Storage speed is such a large part of the feel of smartphone performance. To be honest, I'd leave it off, there's not much of import on my phones anyways, theifs can have my music.

    So, is the Nexus 5 using FDE on Lollipop? Why does it do so much better, both than the 6 and itself on 4.4? Just a bug? Or is it using a different type of encryption, or none at all?
  • Brandon Chester - Thursday, November 20, 2014 - link

    Only new devices will have it enabled, new as in shipping with Lollipop. The Nexus 5 gets an OTA to Lollipop so it won't just enable itself, but I can't speak for users who flash an image from Google. I have the Nexus 5 rolled back to KitKat for the time being for doing version comparisons in the Android Lollipop review. Reply
  • tfouto - Thursday, November 20, 2014 - link

    Can you check this Thread? There are lot's of people complaining of battery draining, on Nexus 5 Lollilop. Reply
  • tfouto - Thursday, November 20, 2014 - link

    Forgot to say which thread was:
  • tfouto - Thursday, November 20, 2014 - link Reply

Log in

Don't have an account? Sign up now