IOMETER / Controller Stress Test
IOMeter is heavily weighted towards the server end of things, and since we here at HWC are more End User centric we will be setting and judging the results of IOMeter a little bit differently than most. To test each drive we ran 5 test runs per HDD (1,4,16,64,128 que depth) each test having 8 parts, each part lasting 10 min w/ an additional 20 second ramp up. The 8 subparts were set to run 100% random, 80% read 20% write; testing 512b, 1k, 2k,4k,8k,16k,32k,64k size chunks of data. When each test is finished IOMeter spits out a report, in that reports each of the 8 subtests are given a score in I/Os per second. We then take these 8 numbers add them together and divide by 8. This gives us an average score for that particular que depth that is heavily weighted for single user environments.
While the numbers the Force posts are very good, they don’t blow away the competition like you would think. IOMeter -even when tweaked and tuned to replicate home user usage patterns- is still a tough test. This by itself wouldn’t mean much except that the other controller manufactures have gone for a different approach and basically build ONE controller for the various markets and use different quality NAND to differentiate them.
At an even more basic level, the SF-1200 controller has a LOT of things to juggle at one time. Between real time compression / decompression, to hash writing this drive’s controller has a lot more overhead then a typical controller does. This obviously takes up a lot of cycles which are thus not available to handle the steady stream of read/write commands being sent its way.
In our usual IOMeter test we are trying to replicate real world use where reads severely outnumber writes. However, to get a good handle on how powerful the controller is we, we have also run an additional test. This test is made of 1 section at que depth of 1. In this test we ran 100% random. 100%writes of 4k size chunks of information. In the past we found this tests was a great way to check and see if stuttering would occur. Since the introduction of ITGC and / or TRIM the chances of real world stuttering happening in a modern generation SSD are next to nill; rather the main focus has shifted from predicting "stutter" to showing how powerful the controller used is. By running continuous small, random writes we can stress the controller to its maximum, while also removing its cache buffer from the equation (by overloading it) and showing exactly how powerful a given controller is. In the .csv file we then find the Maximum Write Response Time. This in ms is worst example of how long a given operation took to complete. We consider anything higher than 350ms to be a good indicator that the controller is either relying heavily on its cache buffer to hide any limitations it possess or the firmware of the controller is severely limiting it.
While the average speed is merely good, the maximum write response time is just bloody impressive. To be honest if we didn’t know better we would say (based on these results) that is was using more expensive SLC NAND and not MLC. They really are that good. Simply put, this all new controller really is a beast which can easily juggle all the tasks SandForce has given it and STILL handle the IOMeter crucible with aplomb.
IOMETER
IOMeter is heavily weighted towards the server end of things, and since we here at HWC are more End User centric we will be setting and judging the results of IOMeter a little bit differently than most. To test each drive we ran 5 test runs per HDD (1,4,16,64,128 que depth) each test having 8 parts, each part lasting 10 min w/ an additional 20 second ramp up. The 8 subparts were set to run 100% random, 80% read 20% write; testing 512b, 1k, 2k,4k,8k,16k,32k,64k size chunks of data. When each test is finished IOMeter spits out a report, in that reports each of the 8 subtests are given a score in I/Os per second. We then take these 8 numbers add them together and divide by 8. This gives us an average score for that particular que depth that is heavily weighted for single user environments.
<img src="http://images.hardwarecanucks.com/image/akg/Storage/F100/IOM.jpg" border="0" alt="" />
While the numbers the Force posts are very good, they don’t blow away the competition like you would think. IOMeter -even when tweaked and tuned to replicate home user usage patterns- is still a tough test. This by itself wouldn’t mean much except that the other controller manufactures have gone for a different approach and basically build ONE controller for the various markets and use different quality NAND to differentiate them.
At an even more basic level, the SF-1200 controller has a LOT of things to juggle at one time. Between real time compression / decompression, to hash writing this drive’s controller has a lot more overhead then a typical controller does. This obviously takes up a lot of cycles which are thus not available to handle the steady stream of read/write commands being sent its way.
IOMeter Controller Stress Test
In our usual IOMeter test we are trying to replicate real world use where reads severely outnumber writes. However, to get a good handle on how powerful the controller is we, we have also run an additional test. This test is made of 1 section at que depth of 1. In this test we ran 100% random. 100%writes of 4k size chunks of information. In the past we found this tests was a great way to check and see if stuttering would occur. Since the introduction of ITGC and / or TRIM the chances of real world stuttering happening in a modern generation SSD are next to nill; rather the main focus has shifted from predicting "stutter" to showing how powerful the controller used is. By running continuous small, random writes we can stress the controller to its maximum, while also removing its cache buffer from the equation (by overloading it) and showing exactly how powerful a given controller is. In the .csv file we then find the Maximum Write Response Time. This in ms is worst example of how long a given operation took to complete. We consider anything higher than 350ms to be a good indicator that the controller is either relying heavily on its cache buffer to hide any limitations it possess or the firmware of the controller is severely limiting it.
<img src="http://images.hardwarecanucks.com/image/akg/Storage/F100/stutter.jpg" border="0" alt="" />
While the average speed is merely good, the maximum write response time is just bloody impressive. To be honest if we didn’t know better we would say (based on these results) that is was using more expensive SLC NAND and not MLC. They really are that good. Simply put, this all new controller really is a beast which can easily juggle all the tasks SandForce has given it and STILL handle the IOMeter crucible with aplomb.
Last edited by a moderator: