Tag Archives: ssd

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.

apt-get install debian

Early last year I wrote how I was concerned about the progress and future of the CentOS project and was considering other options.

As of today, I’ve now shifted my primary workstation (Lenovo X201i laptop) from the somewhat out of date Fedora 13 over to Debian Stable/Squeeze.

The main drives for this change were:

  • Fedora 13 was out-of-date and lacking security fixes, hence requirement to upgrade.
  • The logical replacement, Fedora 16, now ships with GNOME 3 which I found to be buggy and a regression to my work flow and requirements (not going into details here, but essentially issues with dual screens, workspaces and customization of toolbars).
  • Desire to seriously try Debian as a primary system with the purpose of evaluating it’s suitability as a replacement for my CentOS servers.
  • Requirement for a distribution that made major release upgrades feasible (Fedora can do version jumps, but not recommended, making it a tricky process to find time to do a laptop upgrade/rebuild).
  • Distribution standardisation across my server & workstation environments.
  • I needed a full reinstall in order to downsize from a 320GB HDD to a 120GB SSD.
  • Reliability – my laptop is my primary business machine, if it doesn’t work, I’m going to be living on instant noodles until it starts working. Or even worse, work will buy me a Macbook to use like everyone else. :-/

I chose Debian particularly, since it would be a fine option for replacing my CentOS servers in the future with long life support & stability, it’s large package selection and the fact that it’s committed to freedom and openness (as is Fedora also); all of which made it more attractive than Ubuntu for me, which feels much more desktop and fast release focused.

So far, I’m loving it – the distribution is solid, well built and developer friendly, and the package selection is pretty decent, not to mention apt being nice and snappy (although the SSD sure helps there ;-)

I’ve had a couple minor issues relating to my Lenovo hardware that I’ve been able to resolve and have gotten into building a few Debian packages in order to backport newer versions of programs like Firefox/Iceweasel.

From what I’ve observed with playing with Debian today is that’s a pretty awesome distribution, but not entirely as perfect as some of it’s users like to make out:

  • The installer is a bit dated – not due to the text installer (I fucking love text installers! \m/), but rather due to it’s lack of support for WPA/2 wifi access points and also the ability to allow the user to make broken systems without warning (eg no /boot partition when you don’t have enough coffee like me).
  • Debian is often credited for having all the packages under the sun in it – whilst almost true, I did note that a number of my more obscure package choices didn’t exist, sending me  running for my compiler a few times.
  • It would be nice if stable backports tracked some of the common packages that users like updated on older systems – programs like web browsers, instant messengers and maybe even kernels for uncooperative hardware. A user could avoid this by using Debian testing, but there are valid reasons to use stable + some backports over using testing or unstable.
  • I think rpm has nicer command line options for directly working with installed or to-be-installed packages than dpkg. Having said that, some of this could be user familiarity/likes, so time will tell as I use it more.

Over all though, these are minor issues – I think it’s a fantastic distribution with so much working out of the box, applications appearing well tested and good online documentation and resources.

I’m currently running trials and comparisons of Debian with my CentOS hosts with a view for replacing my current CentOS 5 instances with Debian Stable instances over a phased migration period, as well as testing features like LDAP authentication and KVM, but it’s looking pretty damn good so far.

At this stage I’ve only used CentOS 6 as a KVM host platform and it seems unlikely I’ll end up deploying any CentOS 6 VMs with all the security update release slowness. With only a couple servers on CentOS 6 altogether, I’m pondering switching them over to Debian sooner rather than later to reduce maintenance efforts.

[FYI, this post isn’t intended as an attack/demands at the CentOS developers, rather it’s recognizing they’re a volunteer team and probably lacking resource – and I thank them for their efforts, but it appears long term it’s not a good option for my requirements.]

It does also raise questions about Red Hat’s RHEL future with engineers like myself – with Red Hat no longer offering a free-as-in-beer-with-no-support option and CentOS being too slow, more geeks like myself might move to Debian. And if we do so, when the next enterprise project comes along, will we be recommending RHEL or Debian?

Red Hat offers the advantage of commercial support, but for a company with their own engineers, Debian may be more appropriate and budget friendly.