Intel 320 SSD stats & encryption

I recently obtained a 120GB Intel 320 SSD for upgrading my Lenovo Thinkpad X201i from it’s sluggish hard disk to something with a bit sharper performance.

Whilst not the latest and highest performance SSD from Intel, it’s certainly still very quick compared to the hard disk, and it made more sense than buying a more expensive newer model that would be restricted by the SATA 2 bus on my laptop.

The performance increase is impressive, my sequential reads went from 40,300 KB/s to 132,673 KB/s, showing dramatically faster boot performance and snappy application load times. And the seek times jumped massively from 151.4/per second to at least 10,524/per second.

Infact, the SSD is so fast, it can be difficult to get stats of it’s true seek performance. With the seeks completing in only a few microseconds, the bonnie++ tests often finished a bit early and the results would vary, it’s possible the seeks might be even larger than 10k+ per second.

The next major question for me, was what would the performance be if running disk encryption ontop of the SSD. Due to the private nature of my data, I fully encrypt my laptop using dm-crypt/Linux disk encryption with AES 256bit, so that if the machine is ever stolen, the data is unreadable.

Of course, this security imposes an overhead – data needs to be decrypted before it can be read, adding additional overheads, particularly with CPU performance. It’s also worth noting, that the Linux disk encryption implementation is single threaded, meaning that the maximum encryption/decryption performance is limited by the maximum performance of a single core of your processor.

After installing the OS using an encrypted disk, there was a noticeable performance drop. In particular, the sequential reads dropped from 132,673 KB/s to a much less exciting 69,805 KB/s. Whilst still significantly faster than the conventional hard drive’s 40,300 KB/s, it’s a big drop from the true capability of the SSD.

Fortunately the write performance was impacted far less, I suspect because the OS and the CPU core doing the encryption was able to keep up with the slower performance of writing to the SSD, in comparison to the reads. Based on the stats I obtained, it looks like my laptop tops out around 70,000 KB/s, so any additional performance of the SSD above that is wasted.

I’ve uploaded the actual performance statistics generated to a separate page, which you can view if interested.

From a usability point-of-view, even with encryption, the boot time performance is impressive, the laptop starts in about half the time of what it did previously, along with massive improvements in the start time of applications.

The improvements are particularly noticeable when loading a number of applications concurrently – with a conventional hard drive, the need to load data across different physical parts of the disk platters causes a lot of delays when multitasking application loads. On the SSD, I can click a number of applications and have them *all* load within a second or two.

Overall I’m pleased with the upgrade, even with the reduced performance from encryption, the SSD still offers some major performance upgrades and was well worth doing.

The only outstanding downside now is the issue of fitting all my data that I actually want to regularly access on my laptop onto the small size of the SSD…. I’m currently looking into filesystems that provide offline access or caching of networked filesystems from my servers, so that I can have regularly accessed files stored locally, but the full selection just a network transfer away.

This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink.

8 Responses to Intel 320 SSD stats & encryption

  1. Roger says:

    Hi – how is the SSD disk working out?

    • Jethro Carr says:

      Working nicely :-) great performance improvement, only downside is the reduction in disk space forcing me to push more to the server. If I could, would ideally have both a HDD and SSD in my laptop

  2. Josh says:

    Hi, Jethro. Why did you use dm-crypt instead of the Intel 320’s hardware-based FDE?

    • Jethro Carr says:

      Mostly since I trust Linux’s implementation of things more than hardware vendors, from a recovery and consistency POV – I know I can take that SSD and connect it to any standard SATA controller and be able to decrypt and read the data from it, without issue – I wouldn’t be so sure about FDE. For the same reason, I tend to avoid hardware RAID in favor of software RAID unless the performance gain is critical.

      • Josh says:

        Thanks for your insight, Jethro.

        • Jethro Carr says:

          No worries – it would be interesting to compare Intel FDE performance with Linux dm-crypt to see the performance difference. Using a system with a hardware AES chip would make for some interesting stats as well.

  3. Josh says:

    Yeah, a comparison between the performance of Intel’s FDE and dm-crypt would definitely be interesting. There sure is a lack of good information available regarding Intel’s FDE. The revelation that Intel’s FDE uses AES-128 instead of AES-256[1] is an indication that not even the folks at Intel have a full understanding of their FDE.

    The best discussion about Intel’s FDE that I found contains more questions than answers.[2] I recall at least one person in the discussion making your point about the uncertainty surrounding the ability to successfully move a drive encrypted with Intel’s FDE to a different system. My favorite comment in the discussion was the suggestion that maybe the person that implemented Intel’s FDE finished their internship and isn’t available to explain how it works.


    • Jethro Carr says:

      Yeah, it does sound a like they’ve only half finished the work needed for FDE to be acceptable to end users.

      TBH, I’d rather they focus on putting really good AES hardware into the CPU to make it useful for any type of application that wants it, rather than specific I/O encryption.

      They already have AES extensions in a number of AMD and Intel CPUs from 2010+, but sadly my Intel Core i5 430M isn’t one of them. :-(

Leave a Reply