SSD, TRIM and IOMeter - BeHardware
Written by Marc Prieur
Published on April 29, 2010
Over the last two years, SSDs have become increasingly accessible. Although full roll out into our machines has been slowed somewhat by the price of MLC, SSDs have brought staggering improvements to the speed of PC storage systems.
At a time when new controllers are coming onto the market, we wanted to take a look at where things are in terms of SSD fragmentation, TRIM and how it has been implemented in Windows 7, as well as in IOMeter, the powerful synthetic testing software which can however be misused when it comes to testing SSDs.
Back to the futureSince September 2008 we have published seven articles on SSDs:
- SSD Product Review: Intel, OCZ, Samsung, Silicon Power, SuperTalent - October 6, 2008
- Mtron MOBI 3500 - December 18, 2008
- Samsung 64 GB MLC SSD - December 29, 2008
- SSD 2009, act 1: OCZ Apex and Samsung PB22-J - April 27, 2009
- SSD 2009, act 2: OCZ Vertex and Indilinx Barefoot - June 23, 2009
- Intel X25-M, round 2: 10 SSDs compared - August 27, 2009
- Intel X25-M V2 (Postville) - August 27, 2009
From the start, we drew attention to a phenomenon that is more or less significant depending on the model, which translates to a deterioration in performance over the course of use of the SSD. The TRIM command, implemented in Windows 7 since its release, was very much anticipated as a solution to this issue. What happened when we put it to the test? True, weíve been a little bit slow off the mark, but we have taken the opportunity to revisit our SSD protocol as well as look at the impact of TRIM on test software such as IOMeter.
Performance deterioration & TRIM, the theory
Performance deteriorationWe talked about this in our first article on SSDs, a used SSD doesnít give the same level of performance as a ďnewĒ SSD; performance deteriorates with usage. Two phenomenons explain this. Letís begin first of all with the usure that affects all SSDs when you write small blocks of data.
NAND flash memory cells are grouped on pages and these pages make up blocks. Generally one page is 4 KB and a block 512 KB. It is possible to read or write Flash NAND by page, but you can only delete a block at a time.
Another parameter to take into account is that when a file is deleted by the system, the SSD is not aware of this as the operation is typically only flagged at the level of system files. The SSD is therefore only able to compute the invalidity of a piece of data on a page when you rewrite over it!
The resulting phenomenon is quite simple: when you write a new 4 KB file onto a page that has already been used, the SSD has to read the whole block, then delete it and then rewrite all the pages in the block. To write just 4 KB then, you might have to read as much as 512 KB, delete and write 512 KB, which obviously has a negative impact on performance, particularly in random writes of small files.
Another problem is how pages are addressed on Flash memory as the controller has to translate between the logical addresses used by the file system and the physical addresses of the corresponding flash pages. There is no fixed correspondance as with hard drives and the flash controller allocates pages as best as it can so as to optimise performance (write combining) and increase the lifetime of the cells (wear levelling).
Above all itís aggressive write combining that can cause a problem. Write combining is a fairly simple technique that allows several writes to be combined and written in a single sequential burst: writing 32 pages at once onto the same block is much faster than writing 1 page onto 32 different blocks and also causes much less wear on the SSD. The allocation table then has to be updated so that LBA 0 = Page 0, LBA 133 = Page 1, LBA 289 = Page 2 and so on.
The only problem is that if you then have to rewrite such an allocation table sequentially onto the SSD, performance is severely reduced as it is not possible to use as many Flash memory chips at the same time as is necessary. Of course the SSD controller tries to reorganise the allocation table as best it can for this type of write but without any great success if all the pages have already been used once. Write combining is also undermined if there are no free pages as it can then no longer function due to a lack of raw space.
Long live TRIMThis is where the TRIM function comes in. First mooted in 2007 by T13, the technical committee in charge of defining ATA standard specs, it is a command that lets the system tell the storage device that an LBA contains data that is now invalid.
This may seem stupid but it will considerably simplify things for SSD controllers in terms of keeping performance levels up. In terms of the controller, there is no fixed implementation but logically speaking the reference in the LBA / Flash page allocation table is deleted.
Deleting each page physically at this time, in other words deleting the whole block to which it belongs and rewriting it again, would be completely counter productive from the point of view of the usure of memory chips, but sometimes a whole block that only contains pages no longer in the allocation table may be deleted.
In any case knowing in advance which pages are available allows the controller to optimise writes, both sequential or random, and therefore avoid the problem faced when all cells have been used at least once.
In order to be able to use this feature, you need an SSD that supports it but also an operating system that can key into it. This is what Windows 7 does, as well as Linux and soon Mac OS X. In Windows XP and Vista, Intel and Indilinx are offering tools which read the file system allocation tables and tell the SSD via the TRIM command which LBA addresses arenít being used.
Performance deterioration in practice
Performance deterioration in practiceWhat does usure result in practice? We have already looked at this but to give us a precise reading we measured usure of a Crucial M225 64 GB SSD based on an Indilinx SSD with the latest firmware.
First of all, here are the sequential reads obtained on the unused SSD and then on an SSD fragmented by just 12 minutes of random 4 KB writes in IOMeter, namely around 10 GB of data written in this way:
The average base read speed is 215.5 MB/s but this drops to 162.7 MB/s on the fragmented SSD. Now here are the figures for writes:
From 159.9 MB/s on the unused SSD, it drops to 106.6 MB/s. On 1/3 of the SSD, write speeds are maintained at 160 MB/s, before falling to between 80 and 100 MB/s on up to 90% of the SSD and then to between 25 and 30 MB/s at the end.
Now here are the performances for random writes of 4 KB obtained over 12 minutes on the unused SSD then on an SSD that had previously been written sequentially by h2bench:
The impact on performance is also very significant here!
TRIM in Windows 7, in practice
TRIM in Windows 7, in practiceTo be able to use TRIM in Windows 7, you of course need an SSD that supports TRIM but also an IDE controller or AHCI drivers that are TRIM compatible and thus allow the TRIM command from Windows to reach the SSD.
This is the case for generic Windows 7 IDE/AHCI drivers as well as Intel RST drivers from version 9.6 onwards, which allows TRIM on an SSD even if you also have a RAID of hard drives beside it. Marvell and AMD drivers are not however TRIM compatible for the moment and youíre better off using the generic Microsoft drivers.(Update : latests AMD and Marvell drivers are now TRIM compliant !)
When is the TRIM command active? We measured performances obtained with random 4 KB writes in I/O Meter under various conditions. To recap, on the unused SSD we obtained 11.8 MB/s in this test, and 2.5 MB/s when fully written via a sequential write.
If the drive is fully written with a sequential write and the resulting file is kept and then the partition is deleted, performance levels remain at 2.5 MBs.
If the SSD is fully written via a sequential write and the resulting file is deleted, performance levels are re-established at 11.8 MB/s.
If the drive is fully written via a sequential write and the partition is deleted and then quick formatted to recreate it, performance levels are re-established at 11.8 MB/s.
Sequential write performance after random writes are also re-established after formatting or deletion of the file:
As you can see, Windows 7 sends the TRIM command to the SSD in two instances:
- When the partition is formatted, even if quick formatted
- When a file is deleted
Of course in the first instance, the whole SSD is formatted, whereas in the second only the NAND pages used by files are deleted. Note that quick formatting therefore takes a little longer because of communication of the TRIM command; it takes around 30 seconds.
IOMeter and SSDs, a warning!
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.
ConclusionBefore launching ourselves into a report on technology as recent as SSDs, we feel itís very important to get to know their ins and outs. We arenít in the habit of always going into the details of our decisions with respect to a test protocol but the advent of the TRIM command has made things more tricky and necessitates the adaptation of our test tools.
IOMeter is the typical example of a test tool updated at the time of hard drives and which requires a few adjustments so as to represent the true performance of an SSD in a modern operating system, especially if it supports TRIM, without which the results obtained can in certain cases be very far from what you get in reality.
From a more practical point of view we can only salute the arrival of the TRIM command and successful TRIM support on the Indilinx controller. We should say that our first tests on Intel SSDs have shown similar results and we will of course check that the TRIM command is well applied for each SSD tested as well as testing performance without TRIM.
As our test protocol is now almost in place, weíre moving on to some serious testing. Rendezvous here in a few weeks for a report comparing the latest in-fashion SSDs!
Copyright © 1997-2014 BeHardware. All rights reserved.