Solid-state drives challenge hard disks

Judging from both direct feedback and EDN’s Web-site-traffic statistics, engineers have broad interest in the tug of war between currently dominant magnetic hard drives and rapidly rising flash-memory-based solid-state drives. As a result, this hands-on project focuses on that technological battle. The project will live on as a series of online addenda (see sidebar “More hard-drive data”). If cost per gigabyte is your dominant storage metric and especially if you measure your storage needs in triple-digit-gigabyte capacities, hard drives are currently your likely choice. Flash-memory costs are continually plummeting, however. The widespread production ramp-up of cost-effective MLC (multilevel-cell) technology has accelerated flash-memory prices’ downward trend.

Regularly revisiting the comparison of hard-disk drives with solid-state drives makes sense, therefore, particularly considering that the burgeoning per-platter capacities of hard-disk drives may eliminate them from contention if your design’s storage demands don’t need that much capacity. Solid-state storage also delivers additional potential benefits: It lacks a motor to drive one platter or multiple platters spinning at thousands of rotations per minute. It also lacks a vacillating read/write head—or several heads—hovering only a few millionths of an inch above the magnetic material. The lack of these attributes gives solid-state drives better shock tolerance; long-term reliability; and, depending on your usage scenario, power consumption than hard-disk drives.

Solid-state drives are also immune to magnetic-field-cultivated data-corruption effects, and they operate silently. Plus, the lack of rotating-media-incurred delays can deliver tangibly shorter seek times for solid-state drives than for hard-disk drives. This performance is especially noticeable with systems requiring a lot of random-access tasks, and it is particularly so when most of those accesses are reads rather than writes. Access performance is the focus of this article.

I had originally planned to use the same Apple MacBook I employed for an earlier article (Reference 1). Doing so was conceptually appealing due to the fact that the device lets you boot OS X not only from an optical disc or internal hard drive but also from a FireWire-tethered or, with newer Intel CPU-based systems, USB-tethered external hard-disk drive. I therefore obtained a generic SATA (serial-advanced-technology-attachment)-extender cable that mates with the system’s internal-drive connector and enables hot-swap of drives under test. I also got a 2.5-in. IEEE 1394 SATA enclosure from Addonics Technologies for my system’s main drive. Although I own plenty of USB 2 enclosures, a FireWire alternative was appealing both because the data-interface cable would also supply sufficient current to power the hard-disk drive and because of the interface’s likely faster performance than USB 2 (Reference 2).

Upon further analysis, however, my first-pass strategy began to dissolve. To use the SATA-extender cable, I would have had to remove the system battery and therefore run the system solely off ac power. Unfortunately, MacBooks automatically throttle the system clock down to 1 GHz when no battery is present (Reference 3). This quirk wasn’t a deal breaker; between drive tests, I’d alternatively just need to power down the system, remove the battery, swap drives, replace the battery, and boot up again. I then discovered, however, that the core-logic chip set in my MacBook supports only SATA’s first-generation 1.5-Gbps speeds. Almost all of the drives I would be testing were SATA/300—that is, 3 Gbps, and I didn’t want the chip set to act as an artificial constraint on their full performance potential.

Instead, I went with my Windows Vista-based Dell XPS M1330 laptop, whose Santa Rosa ICH8M chip set complies with SATA/300 (Figure 1 and Table 1). I then faced another quandary, however: You can’t boot Windows Vista from an external hard drive. Instead, I could have cloned a common NTFS (New Technology File System) image to each hard-disk and solid-state drive I was testing, sequentially installing each in the system’s internal drive bay. Whenever I booted the XPS M1330, however, I’d need to revalidate the operating system with a new registration key because the detected hardware change would prompt a Windows-product-activation alert.

Instead, I dodged the hassle by using Addonics’ ExpressCard eSATA (external-SATA) adapter to test the hard-disk and solid-state drives (Figure 2). Because ExpressCard’s 2.5-Gbps speed places a limitation on SATA’s 3-Gbps performance, I couldn’t run the drives at their highest possible transfer rates. My mass-storage-benchmark program of choice, as has been the case in many past projects, is SiSoftware’s Sandra. This time around, I used the company’s free latest version, the 2000 Lite edition.

In addition to the hardware that Addonics provided, Bill Kwong, the company’s president, also donated an eSATA-to-SATA adapter cable; a stand-alone SATA power supply; and, because I had the good fortune to get my hands on two Intel solid-state drives, a dual-slot eSATA enclosure capable of RAID (redundant-array-of-inexpensive-disks) 0, JBOD (just-a-bunch-of-disks), RAID 1, and other multidrive-mode operation. As you’ll soon see, the dual-slot enclosure yielded unexpected results.

Figure 3 and Table 2 depict the hard-disk drives I evaluated for this project. Note that all the hard drives are recent-generation units. This selection was intentional because it ensured that all of the drives employed high-capacity PMR (perpendicular-magnetic-recording) technology. An earlier longitudinal-recording-based drive would have had a lower bits-per-square-inch areal density and would consequently incur a substantially lower transfer rate than PMR at given rotations-per-minute figures. Successive PMR-technology iterations have been delivering incremental storage capacities, however, so the rotations-per-minute-normalized bit-packing metrics of the drives I tested aren’t necessarily equivalent. For example, Seagate sent me a Momentus 7200.2 drive instead of a newer and denser 7200.3 unit.

Unfortunately, I couldn’t obtain a 4200-rpm hard-disk drive; such drives find use in ultralow-cost and ultralow-power—albeit ultralow-performance—applications as well as in systems that strive to squeeze the maximum storage from a platter. Such drives are largely falling out of favor, however, as 5400-rpm variants become more power-efficient, dense, and cost-effective over time. My single-platter, 5400- and 7200-rpm drives came from Western Digital and Seagate, respectively, and Western Digital also supplied me with high-end, 10,000-rpm units. On a hunch, I tested both the company’s 2.5- and 3.5-in. VelociRaptor drives; the 3.5-in. device comprises an IcePack heat sink surrounding a 2.5-in. drive. According to the company, the two drives should deliver identical results, but they didn’t, perhaps because of differences in their firmware.

To understand why I included three solid-state drives in this project, you need to first understand some high-level differences between SLC (single-level cell)- and MLC-flash technology (Figure 4 and Table 3). Intel’s drive employs MLC techniques. It stores 2 bits of information within each flash-memory-array transistor by equating a unique 2-bit data combination with each of four possible charge amounts on the transistor’s floating-gate structure. This arrangement translates to three threshold levels that act as the boundary conditions. Sensing the exact charge value during read operations takes more time than does the traditional SLC approach, which differentiates between only two charge-quantity states—that is, a single threshold level. However, MLC extracts 2 bits’ worth of information at a time—versus 1 bit per transistor access for SLC—counterbalancing the extended MLC-read-access delay.

MLC performance suffers even more during write operations, however. Depositing a precise number of charge electrons on the floating gate is critical to ensuring accurate subsequent read-back results, particularly when you consider that the ensuing data alteration of adjoining transistors can result in minor charge disturbances of the transistor in question. SLC-write operations, conversely, can be more brute force in nature and consequently faster. Therefore, I tested one SLC-based solid-state drive from Samsung, another from Sandisk, and an MLC-based drive from Intel. Sandisk’s drive is nearly two years older than Samsung’s; embryonic solid-state-drive technology is on a rapid improvement ramp, according to the suppliers. I wanted to see whether that claim translated to noticeable benchmark differences between the two SLC-solid-state-drive contenders.

Sandra’s File Systems test encompasses the Windows Vista SP1 intermediary, meaning that it operates at the INT 21 level, not the INT 13 BIOS level (Figure 5). The results show that Sandra rounds up all access-time measurements to the nearest millisecond, thereby explaining why all of the solid-state drives reported 1-msec random-access times. Future Sandra versions will deliver microsecond-level precision, however, according to Adrian Silasi, lead programmer for the Sandra team at SiSoftware. Nonetheless, solid-state-storage subsystems’ random-access ability gives them a clear advantage over rotating-media alternatives. Solid-state drives’ read-performance advantages over hard-disk drives predictably become more apparent with more random-access patterns. A close parity also exists between Western Digital’s 5400-rpm drive and Seagate’s 7200-rpm alternative, perhaps reflecting the fact that the newer Western Digital drive employs a more aggressive PMR-areal-density specification.

The older Sandisk SLC-flash-memory-based solid-state drive also lags behind both the Intel MLC- and Samsung SLC-flash-memory-based solid-state drives in both read and write tasks. I suspect that the Sandisk unit’s lack of an onboard RAM buffer is partly to blame. In contrast, Samsung’s solid-state drive reportedly embeds a massive 64-Mbyte buffer. Intel declined to reveal a cache-buffer size for the company’s solid-state drives. Other reasons for the Sandisk drive’s inferior showing may be the fact that it uses an earlier-generation, lower-performance NAND-flash-memory foundation, and the fact that it simultaneously accesses fewer flash-memory components.

Another surprise occurred when I compared the single-drive-read performance of Intel’s solid-state drive with the dual-drive-RAID 0-striped performance in Addonics’ enclosure: Addonics’ dual-drive configuration operates at a lower speed than a single Intel device. The Addonics portable dual-drive-RAID enclosure embeds a Silicon Image SteelVine SATA RAID processor. Based on the numbers, I suspect that this processor was acting as a performance bottleneck to the solid-state drives behind it. I therefore added two other hardware configurations to my test suite. The first continued to employ only the Addonics enclosure; instead of configuring the drives in hardware-RAID 0 mode, however, it used a JBOD configuration. Windows Vista’s built-in software running on an Intel CPU alternatively performed RAID 0 striping, increasing performance. For my final test, I left one Intel solid-state drive in the Addonics enclosure but tethered the other one directly to the second eSATA port in the ExpressCard adapter. Again, moving the performance bottleneck closer to the Dell laptop resulted in a performance boost.

Solid-state-drive results differed somewhat in the write tests, although the overall hardware-versus-software RAID trends held steady. Dual-drive writes completed faster than single-drive counterparts, even when I controlled them with hardware within the Addonics enclosure. This result reflects the fact that dual-drive RAID 0 parallel-write striping inherently counterbalances slow MLC-flash-memory writes. Don’t conclude from these statistics that hardware RAID is inherently bad. I ran my tests with a lightly used system CPU; the software-RAID results may have been substantially worse in a more heavily loaded situation, whereas the hardware-RAID outcomes would have been largely independent of CPU loading. As I expected, too, Samsung’s SLC-flash-memory solid-state drive outperformed Intel’s MLC-based alternative on single-drive-write tests.

After removing the operating-system intermediary, I tested to see how these drives would respond to Sandra’s Physical Disks direct-access analyses, which provide not only average access times for the entire drive but also statistics for various capacity thresholds across the drive (Figure 6). In examining the data, remember that the drives I tested for this project had various capacities. One of the first things you’ll probably notice is that the hard-disk drives all exhibit classic access-performance degradation as the read/write heads move across the platters, whereas solid-state-drive-access speeds are consistent across the capacity range.

Again, you’ll see worse performance for a hardware-RAID 0 read for the two-drive-striped Intel solid-state configuration using Addonics’ enclosure than that of the single-drive alternative. Unfortunately, in this case, I couldn’t test the software-RAID-substitute approach because it would have required that I partition the setup with an NTFS format, which is incompatible with Sandra’s Physical Disks test requirements. Note, too, the degraded write performance for several of the hard-disk drives at both extremes of their capacity ranges. Also, although the 2.5- and 3.5-in., 10,000-rpm Western Digital drives are supposedly identical at their cores and consequently had comparable read-access attributes, the 3.5-in. drive, which comes with a heat sink, delivered considerably higher write performance than its 2.5-in. sibling.

To gain an even greater understanding of the drives’ capabilities, I turned to Sandra’s Removable Storage tests, which subjected the storage subsystems to read and write sequences comprising six file sizes (Figure 7). As you peruse the results, you’ll likely notice that the drives’ designers optimized firmware and other factors for certain file sizes—to the detriment of others. Again, look at the write performance of the two supposedly identical, 10,000-rpm Western Digital drives: Whereas the 2.5-in. drive held the lead with small payloads, its 3.5-in. counterpart surpassed it once file sizes exceeded the 1-Mbyte threshold. And, because I was working with NTFS-formatted drives, I was able to test all three RAID 0 configurations with the two Intel solid-state drives.

I’m grateful for the support of Addonics Technologies, which was an enthusiastic partner in this project.