# Disk speed

My previous post contained some vague statements about the low latency of the SSD with which my current system is equipped. Haui suggested a more quantitative measure and referred me to a little utility called seeker capable of actually measuring the random access time of storage devices. Thus started, I continued and measured both the transfer rate TR (using hdparm -t) and the random access time AT (using seeker) of some other storage devices which I had lying around.

Name                Interface       Capacity (GB)       TR (MB/s)       AT (ms)

Plextor PX-256M5P   SATA 6G         256                 435             0.1
RunCore Pro IV      Mini PCIe       32                  75              0.35
USB sticks          USB 2.0         2--8                20--30          1
SD card (Class 10)  SD              16                  10              2
2.5" USB disk       USB 2.0         500                 35              15
WD WD10EFRX         SATA 6G         1000                150             20


When looking at these data, several facts strike me as remarkable. First of all, when comparing the first and the last position, it becomes clear that SSDs are now the only viable drives for desktop computing, offering a capacity more than sufficient for all modern OS and their applications, a transfer rate clearly superior to all available magnetic HDs, and, finally, a decrease in access time by two orders of magnitude. The latter is of particular importance, since it not only creates this 'snappy' feeling we all love, but is also responsible for the absence of the system stall during extended disk operations, such as a backup or a file search (see also the technical remark on IOPS at the end of this entry).

Second, I cannot help but marvel at the abundance of affordable and high-performing mobile storage solutions available today. Readers below age 30 will perhaps not understand, so let me remind you of one historical fact:

3.5" floppy disk            0.0015      0.015       300


THIS THING was the only available portable storage solution for a decade prior to the advent of affordable CD ROM drives in the late 90s. Consequently, the OS of your choice as well as games came on 20 or 30 of these disks. Look at the numbers above to get at least a SLIGHT idea what installations were alike. They indeed often took HOURS and required the repeated manual insertion and ejection of EACH OF THESE DISKS.

Eh ... sorry.

'Portable' also meant, of course, that we used these disks for transporting data back and forth. At least 20% of my data were destroyed in in transit due to the magnetic field in the U-Bahn. GNAAAAA!

I'm so glad these times are over. :)

On a technical note: SSDs are typically not assessed in terms of random access times, but of I/O operations per second (IOPS). These quantities are not simply inversely related since IOPS are usually measured in a way relevant for servers, namely, with 32 threads. Ideally, the number of IOPS would scale linearly with the number of threads, but experience shows that 32 threads are sufficient to reveal the maximum, saturated IOPS of the drive.

To illustrate the different response of SSds and HDDs to multithreaded access patterns, I've tested both the Plextor SSD and the WD HDD with seekmark (available on the AUR), a multithreaded I/O benchmark based on seeker.

Name                IOPS (1 thread)     IOPS (32 threads)       Gain

Plextor PX-256M5P   10000               100000                  10
WD WD10EFRX         50                  100                     2


As you can see, the SSD handles multithreaded access patterns much more gracefully than the HDD. Data base servers with very high demands may saturate even this I/O rate, but otherwise we may state that 100000 IOPS ought to be enough for everybody. ;)

Update:

Here's a graphical overview of the drives' performance when subjected to different numbers of threads:

The plot visualizes the enormous difference between SSD and HDD as well as the saturation of the drives for larger numbers of threads. My Plextor SSD, for example, scales linearly up to 8 threads, but saturates thereafter.