Continuous activity tests - Steady State Performance
The steady state performance of an SSD, or the performance level at which an SSD stabilizes after a long period of intensive use, is especially important to individuals who are going to use an SSD for professional applications, such as workstation or server applications.
Let's start off with some background information. We have mentioned numerous times that data on SSDs can be written and read per so-called page, which are usually quantities of 4, 8, or 16 kB. However, in order to write data, data cells have to be erased first, and that can only be done per block. Each block consists of 128, 256, or 512 pages. As a result, SSDs have to resort to clever tricks. When a number of pages worth of data has to be erased, the SSD first has to copy the rest of the data in the block to another block, after which the entire block can be erased. In practice, this means that SSD controllers collect as many write actions as possible, and then simultaneously perform them on new, freshly emptied blocks. At the same time, delete actions are only performed at specific moments. At these moments, when the SSD is idle, the controller enables the built-in garbage collector, which actually performs the delete actions on a chip level and whenever possible combines the leftover data in full blocks, in order to maximize the amount of blocks that can be fully emptied.
However, when the SSD is being used continuously for a long period of time, that is to say, without even a second of idle time, the garbage collector is simply unable to do its thing. As a result, the SSD will run out of empty blocks at a certain point in time, which means that it has to resort to performing garbage collection in between commands. Naturally, this results in lower performance. The performance level at which an SSD stabilizes in such a scenario is referred to as its steady state performance.
We run two different continuous activity tests to determine this steady state performance. Both tests are run using Iometer, where we continuously run each workload for a period of 30 minutes and report the average performance over each minute. The first continuous activity test is the 4k random write QD32 benchmark. The second continuous activity test is the Iometer database workload simulation, also ran using a queue depth of 32. Both tests are run on a test file that takes up 75% of the drive's capacity (LBA).
4kB random write QD32
In the continuous activity test with small files the NX500 starts off well and drops in speed only after nine minutes. At the 21st minute something unexpected happens: the full speed is picked up again for some time. This is probably because the SLC-cache is emptied at this point which allows for writing at full speed.
Database simulation QD32
The NX500 performs well in the database simulation and especially the consistency is worth mentioning. After 10 minutes this drops to about 400 MB/s and stays there. The NX500 clearly outperforms the Force MP500 in this test.