4 KB Random Performance: Throughput
Trace-based benchmarks like our Storage Bench v1.0 give you a holistic view of performance by mixing random and sequential operations. However, we still want to isolate more specific access patterns. Testing 4 KB random performance is particularly important because it constitutes a majority of the transfers your drive sees.
Right after running Storage Bench v1.0, we subject the drives to Iometer for random 4 KB performance testing. But why 4 KB, specifically?
When you open Firefox, browse multiple Web pages, and write a few documents, you're mostly performing small random read and write operations. The chart above comes from analyzing Storage Bench v1.0. But it epitomizes what you see when you analyze any trace from a desktop computer. Notice that close to 70% of all of our accesses are eight sectors in size. At 512 bytes per sector, that's 4 KB).
We're restricting Iometer to test an LBA space of 16 GB because a fresh install of a 64-bit version of Windows 7 takes up nearly that amount of capacity. In a way, this examines the performance that you would see from accessing various scattered file dependencies, caches, and temporary files. Read the technical discussion of our Storage Bench v1.0 to understand why a queue depth of one is the most relevant. If you want your results in IOPS instead of MB/s, use the conversion method described in Second-Gen SandForce: Seven 120 GB SSDs Rounded Up.
At a queue depth of one, all of the m4 drives line up as they did in our IPEAK-based test, except that the 256 GB model is now at the back of the pack. It's actually slower than the 64 GB m4, and this trend continues when you look at performance at higher queue depths. However, the 512 GB m4 delivers impressive performance. It's 85% faster than the 128 and 64 GB m4s.
It might seem odd that the 256 GB m4 runs slower than the 128 GB version, but there's a good reason for this. The 128 GB model employs 16 memory packages, each with two 32 Gb (4 GB) dies that employ native 4 KB pages. The 256 GB drive similarly utilizes 16 packages from IMFT. However, each package hosts two 64 Gb (8 GB) dies with 8 KB native pages. Benchmarks that isolate 4 KB access patterns highlight the two different configurations by demonstrating that an SSD with native 4 KB pages has faster read access than one with 8 KB pages. This occurs because a request for a 4 KB page on a 256 GB m4 is in reality a larger (and consequently slower) 8 KB request. Writes aren't affected because you're still putting 4 KB of information into the page, regardless of its native size.
Our random write results are the first time we see Crucial's m4 drives finish in the expected order. There's a clear progression down from 512 GB to 256 GB to 128 GB to 64 GB. Finally, we see the 256 GB m4 edge in front of the 256 GB C300. The fact that there's a very obvious difference from one capacity to the next is perhaps most interesting.
Take a look at the performance gap between the largest and smallest m4. The 512 GB model has a random write rate of 233.6 MB/s. That's 10x faster than the 64 GB's 21.6 MB/s. The 256 GB m4 represents the beginning of diminishing returns, as the 128 GB m4 halves the larger SSD's throughput. When you double capacity to 512 GB, you're getting less than a 10% bump in performance.
Unlike reads, there's no particular overhead incurred by the 256 GB drive when writing to an 8 KB page size, because the SSD is still putting 4 KB of information into a page, regardless of its native size. This should result in the 128 GB m4 performing as fast as the 256 GB m4 because both have the same number of dies per channel. Unofficially, it appears that Crucial is artificially capping write performance on the 128 GB drive in order to provide better differentiation.
Hard drive performance here is still abysmal. Seagate's 5400.6 only achieves a random write rate of 0.8 MB/s.
