TRIM Testing
Finally, I want to introduce a new test I've been working on using JEDEC's 218A consumer workload trace to create a TRIM benchmark. It's not a neatly-packaged little utility you can run at home. Rather, this is a test scripted in ULINK's DriveMaster 2012 software and hardware suite.
DriveMaster is used by most SSD manufacturers to create and perform specific metrics. It's currently the only commercial product that can create the scenarios needed to validate TCG Opal 2 security, but it's almost unlimited in potential applications. There are various hardware components associated with the platform, such as a SATA/SAS power hub that allows the benchmarked drive to be power-cycled independently of the platform. Much of the benefit tied to a solution like DriveMaster is its ability to diagnose bugs, ensure compatibility, and issue low-level commands. In short, it's very handy for the companies actually building SSDs. And if off-the-shelf scripts don't do it for you, make your own. There's a steep learning curve, but the C-like environment and command documentation gives you a fighting chance.
This product also gives us some new ways to explore performance. Testing the TRIM command is just the first example of how we'll be using ULINK's contribution to the Tom's Hardware benchmark suite.
The suite ships with some built-in scripts, but also contains its own scripting language for extensibility and customization. This particular test uses JEDEC's published master trace of consumer I/O activity (similar to our Tom's Hardware Storage Bench trace). The read commands are removed from the trace, leaving write, flush, and TRIM commands. After secure erasure and writing preparatory data, the test commences. The trace is played against the drive four times using NCQ with and without TRIM, and DMA with and without TRIM. IOPS are measured and averaged every 100,000 commands.
On a 256 GB drive, each iteration writes close to 800 GB of data, so running the JEDEC TRIM test suite once on a 256 GB SSD generates almost 3.2 TB of mostly random writes (it's 75% random and 25% sequential). By the end of each run, over 37 million write commands are issued. If that sounds like a lot of storage traffic, it is.
The first two tests employ DMA to access the storage, while the last two use Native Command Queuing. Since most folks don't use DMA with SSDs (aside from some legacy or industrial applications) we don't concern ourselves with those. It can take up to 96 hours to run one drive through all four runs, though faster drives can cut the time in half, roughly. Because so much information is being written to an already-full SSD (the drive is filled before each test, and then close to 800 GB are written per iteration), SSDs that perform better under heavy load fare best. Without TRIM, on-the-fly garbage collection becomes a big contributor to high IOPS. With TRIM, 13% of space gets TRIM'ed, leaving more room for the controller to use for maintenance operations.
Here's the chart derived from our DriveMaster JEDEC TRIM test data. Looking at the rolling average of performance at each 100,000-command segment, the 480 GB SSD DC S3500 and SSD 730 are mostly even. The SSD DC S3700, with all its over-provisioning, fares even better.
Prior to running each iteration of the test, the drives are written to with random data twice. An SSD with known-good steady state performance is going to excel here.
This is the Intel SSD 730 Series and its instantaneous average, with TRIM enabled and without it. Underneath is a chart that also includes the SSD DC S3700 and S3500. The peaks are bursts of activity, and on a normal desktop-oriented drive, the TRIM-enabled test would register higher peaks, since the drive wouldn't be erasing and programming on the fly. That's not the case here, though.
The lower-end Intel drives to see some benefit from TRIM, but the SSD DC S3700 is unfazed, even without it.
We can boil the average performance of the final test with TRIM into a MB/s chart. Overall, the SSD 730 places well. SanDisk's X210 does the most with the least, though. It has just 7% of spare area and no over-provisioning.
