IOMeter, a powerful but complex tool
We want to take the opportunity of using this article on TRIM and the introduction of our new test protocol to issue a warning against the use of IOMeter for SSD tests. Developed by Intel and then given new life in the framework of Open Source, IOMeter is a snythetic testing tool that is both powerful and complex to use. Initially designed for hard drives, it can also be used to test SSDs but this necessitates regulation of the settings without which the results obtained may be inexact to a greater or lesser extent.
The first problem comes in terms of the type of default accesses in IOMeter. These accesses are in fact configured by default so as to be aligned to a sector, or 512 bytes, an incorrect alignment used by default in Windows XP. The impact can be quite significant as, for example, a 4 KB write will be astride two 4 KB pages of the SSD and have to be written over both pages.
Some SSDs resolve this at the controller by re-addressing the system accesses so that they are aligned with the NAND pages but this isn’t so for all SSDs and isn’t in any case any longer representative of what happens in a modern OS that uses optimal alignment for SSDs (as Microsoft has done since Vista). It is therefore imperative to configure the access specifications used for testing in IOMeter to align them on a page, namely 4 KB.
On some SSDs, the impact of the default settings can be disastrous, with, for example, the Crucial C300 in random 4 KB writes and with 3 competing comamands where we obtained 16 MB/s with the default setting and… 129.2 MB/s by aligning the accesses correctly!
The second problem with IOMeter comes in terms of its integration into a test protocol that is supposed to take TRIM into account. IOMeter does allow you test an SSD (or HDD) whether or not there’s a partition on it.
If the SSD isn’t partitioned, tests can be launched directly but accesses aren’t routed through the Windows 7 file manager, and as as result no TRIM command is sent from it to the SSD. This means you have to do it manually between each test, via the creation and formatting of a partition for example, to get figures that are representative of usage in an OS using TRIM. This is a problem common to all software going outwith the file system for these tests, such as HD Tach or H2benchw for example.
If the SSD is partitioned, things aren’t really much better. Before launching the desired tests, IOMeter sequentially creates a file that fills the available drive space on the SSD. It then executes the tests without ever deleting this file, even when you exit IOMeter (you have to delete it manually).
In fact, even if you want to test random write performance, the reading will be taken on a drive that has previously been sequentially written, which can have quite an impact on performance without going into the fact that this isn’t representative of real performance levels in a “TRIM” environment. Thus on a Crucial M225 you get writes of 2.5 MB/s as of the first use of the bench, instead of the 11.8 MB/s that can usually be obtained.
What’s more, if you carry out consecutive tests within the same session, they will be on an SSD that is fragmented in various ways, with what may be a significant impact on the results obtained. As the file is never deleted by IOMeter, you can write an infinite volume of data onto an SSD without the TRIM command ever being used, which in no way corresponds to real usage.
