Single Drive performance

We decided to use Linux as our benchmarking platform for this review, as most of the benchmarking utilities we need either come installed or are easily available. In Windows, we sometimes find ourselves downloading several benchmarking suites to achieve the same purpose.

The simplest tests to perform are done with the command hdparm. hdparm stands for Hard Drive Parameters, and adjusts just that. Specifically, hdparm has a wide set of tools for ATA drives, such as adjusting the DMA. For other drives, the options become much more limited, as they rely more on hardware settings than software.

hdparm allows us to benchmark with the t and T flags, in a command such as

# hdparm -tT /dev/sda

Where -t gives us device read timings, and -T gives us cache read timings. Furthermore, -t deals with sequential disk performance. This causes a reading of the very start of a disk, which is usually faster than other parts on spinning harddrives. This is a little different for solid state storage, but it generally still gives you a good idea of the device's top speed. -T, on the other hand, gives you the speed of the hard drive's cache without any hard drive activity. This is somewhat less important in most cases, but still a helpful benchmark none the less. Let's see how a single drive performs.

/dev/sda

  Timing Cached Reads: 1777.98MB/sec

  Timing Buffered Reads: 23.38MB/sec

The buffered reads aren't too shabby at all, just a tad shy of the maximum 28MB/sec speed the drive is advertised with. For reference, my laptop's hard drive provides the following:

/dev/hda

  Timing Cached Reads: 1829.20MB/sec

  Timing Buffered Reads: 30.11MB/sec

You can run the benchmark a few times to get a good idea of what the average speeds are. Unfortunately, transfer speeds aren't all that matter in this day and age. We imagine that SSD's may end up in a lot of servers, as well. In a server environment, hard drive access times are very important. Companies have to get information to the guest as soon as possible, and part of that information transfer relies on how fast the hard drive can locate the requested data.

Spinning hard drives have a major disadvantage here, as they have to spin to find a location. Solid state drives, however, are a mere mix of circuits with no moving parts. Access times should be much improved. Using a utility called Seeker, we found the Rally2's access time to be a mere 6.63 milliseconds. That's nearly three times the speed of my laptop's hard drive: 18.43 milliseconds. It seems we've found another advantage the Rally2 and Solid State drives have over spinning drives.

On a side note, using the Rally2 no my desktop gave me the results of 3.79 millisecond access time. I'm not sure how to account for this, aside from an increase in processor speed and possibly a difference in the USB controllers.

As a final test, we chose to use the Linux command dd to test sustained write speeds. dd is a common UNIX program whose primary purpose is the low-level copying and conversion of files (Wikipedia definition). We simply used /dev/zero (which outputs zeroes) to write files to the drive. We wrote 1GB to the drive to achieve this purpose.

# time dd if=/dev/zero of=/mnt/disk/test bs=1024 count=1000000

This is where if is the input file, of is the output file, bs is the block size, and count is the number of times to do it. We're writing approximately 1GB of data to the drive, which left us with a 14 MB/sec write speed. Not too shabby at all. Compare this to the 11 MB/sec write speed of my laptop's hard drive. Impressive, right?

Warning: Make sure of is set to a new FILE. If you set this to a hard drive such as /dev/hda, it will overwrite data starting at the beginning of your disk. Say goodbye to your partition tables!

Now that we've seen what a single drive is capable of, what do you think the results would be if the drive was to be put into a software-based RAID0 configuration? Would we see performance gains that rival the speed of a traditional disk? Let's hope so.