Continued from 'Solid-State Drives Challenge Hard Disks: Benchmark Observations And Background Statistics'...

As I mentioned in the print article's 'Head to the web for more hard-drive data' sidebar, I asked SiSoftware's lead programmer, C. Adrian Silasi, to provide additional information on various aspects of the particular Sandra tests I ran in this study. His feedback follows.

File Systems:

All tests use rounding functions (thus 10.5 becomes 11) and also low-limit, thus "1" would be lowest value if a value was measured, "0" meaning beyond the measurement limit. We can increase the [editor note: random access time] accuracy and report "µs" instead of "ms" if you wish. Most computers have hardware timers these days with better accuracy.

Access depends on test, buffered for buffered, sequential for sequential, random for random.

This test uses a file thus access depends on file system as well as OS. It shows the performance of a drive of a disk rather than just the disk itself.

Physical Disks:

The dataset depends on disk size, there are 30 reads/writes at 30 points, thus depending on drive size 64KB to 64MB is read at each point. Random test reads sector size only.

Access is sequential for sustained tests, with random access for the random test.

Basically this test reads/writes raw sectors and does not depend on drive partitions, file systems, etc. Such a test shows the hardware interface speed (computer <-> controller <-> drive) with no effect of file system/caches, etc.

Removable Storage:

Dataset depends on the tested point, 512 bytes to 2MB data size. The weight of the index was computed based on the file sizes we have on our backup drives, e.g. what percentage are ~512 bytes, 4 KB, 64 KB, etc.

Access is sequential always, denoting copying of files to/from a removable storage device.

This test simulates the operations performed on a removable drive, writing (backup), reading (restore), deleting with various number of files.

Obviously, probably, the degree of applicability of my project's results to your particular application will depend on how closely your usage scenario mimics my testing suite's file sizes, read-versus-write and random-versus-sequential access profiles, and access frequency. In addition to revisiting SiSoftware's Sandra for yourself, therefore, I encourage you to also evaluate other storage benchmarking tools. I listed a number of suggestions a year and a half ago in an online addendum to an external storage hands-on project; others include:

• AJA's KONA System Test (OS X)
• Intech SpeedTools
• Xbench (OS X)

Please let me know of any other storage benchmark utility suggestions you might have!

Perhaps less obvious, though, but of equal concern to me when self-assessing the degree of meaningfulness of my study, is the potential impact of flash memory media management on perceived SSD performance. Since the data sets I wrote to the drives were fairly small in comparison to the SSDs' total available capacities, and since the drives were freshly formatted at the beginning of the tests, I suspect that the file patterns I wrote to the SSDs didn't trigger much if any media management. But sooner or later under normal usage conditions, the drive controller will need to begin tackling wear leveling, free space recovery, and other flash memory read-, program (changing 1s to 0s)- and erase (0s to 1s)-intensive operations.

If these maintenance tasks occur in the background while the system is otherwise occupied with other duties, or if the SSD controller is clever enough to only do the tasks on portions of the memory array not being simultaneously accessed by the system, the only impact you'll see will be higher-than-usual average SSD power consumption. But statistically speaking, you'll eventually encounter scenarios where a system access request 'collides' with in-progress media management duties...with performance-sapping consequences. The SSD manufacturers are understandably loath to reveal the 'secret sauce' of their media management algorithms, so unfortunately you'll need to do a lot of experimentation on your own in order to expose (or not) such foreground access conflict situations. And realize that what works (or not) for one SSD manufacturer cannot be automatically extrapolated to all others.

Continue reading with Part 3 of this post, 'Solid-State Drives Challenge Hard Disks: Behold The Source Data Bits'...