AkG
Well-known member
- Joined
- Oct 24, 2007
- Messages
- 5,270
NON-TRIM Environment Testing
In many ways, a SF2281 should be severely handicapped in an environment that doesn’t support TRIM. To recreate this, we first modified our testbed so that it would not pass on the necessary cleaning commands. Meanwhile, to artificially induce a degrade state we ran eight hours of IOMeter set to 100% random, 100% write, 4k chunks of data at a 64 queue depth across the entire array’s capacity. At the end of this test, the IOMeter file is deleted and the drive was then tested. This will replicate drive performance after extended heavy usage prior to any self maintenance routines kicking in and is indicated by the “Dirty” results below.
In order to allow each drive’s self-maintenance routines to kick in, we then wait 30 minutes (Dirty + 30 results) with the system at idle and rerun the tests.
For a real world application we have opted for our standard Vista load time test.
While the V4 does indeed take a noticeable dip in performance immediately after being hammered with large amounts of data, it does fight its way back awfully quick. In fact, we have a sneaking suspicion that - much like some Marvell based models we have looked at in the past - the NAND inside the V4 is actually in better shape than these results would lead you to believe. Rather than a true degraded state being the culprit the more likely answer is that processor cycles are being taken away from immediate IO demands to continue to clean the drive via extremely aggressive “background” garbage collection routines.
This would make sense as not all of the intended customer base will be running in TRIM environments. Unfortunately, unlike the Marvell controller the M series is based on, the Phison controller in this V series is not overly powerful and does not have excess cycles to spare on aggressive background garbage collection. With that being said, this drive is still a good solution for non-trim scenarios.
NON-TRIM Environment Testing
In many ways, a SF2281 should be severely handicapped in an environment that doesn’t support TRIM. To recreate this, we first modified our testbed so that it would not pass on the necessary cleaning commands. Meanwhile, to artificially induce a degrade state we ran eight hours of IOMeter set to 100% random, 100% write, 4k chunks of data at a 64 queue depth across the entire array’s capacity. At the end of this test, the IOMeter file is deleted and the drive was then tested. This will replicate drive performance after extended heavy usage prior to any self maintenance routines kicking in and is indicated by the “Dirty” results below.
In order to allow each drive’s self-maintenance routines to kick in, we then wait 30 minutes (Dirty + 30 results) with the system at idle and rerun the tests.
Real World Results
For a real world application we have opted for our standard Vista load time test.
While the V4 does indeed take a noticeable dip in performance immediately after being hammered with large amounts of data, it does fight its way back awfully quick. In fact, we have a sneaking suspicion that - much like some Marvell based models we have looked at in the past - the NAND inside the V4 is actually in better shape than these results would lead you to believe. Rather than a true degraded state being the culprit the more likely answer is that processor cycles are being taken away from immediate IO demands to continue to clean the drive via extremely aggressive “background” garbage collection routines.
This would make sense as not all of the intended customer base will be running in TRIM environments. Unfortunately, unlike the Marvell controller the M series is based on, the Phison controller in this V series is not overly powerful and does not have excess cycles to spare on aggressive background garbage collection. With that being said, this drive is still a good solution for non-trim scenarios.
Last edited by a moderator: