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 report 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.
Talk about a funky looking happy-faced graph result. The reason it is so different from all the rest is that the firmware is slightly out dated and less refined yet its double load of NAND at low levels give the Summit that performance boost or spike seen at 1 que depth when compared to the P64. As with the Corsair, the middle levels do not fully take advantage of the large cache and only at extremely deep ends do we see a slow but steady increase in performance.
With a firmware revision or three we could conceivably see results which, while still not as good as the Indlinx, would be better than they are now.
In our usual IOMeter test we are trying to replicate real world use where reads severly outnumber writes. However, to get a good handle on how well a Solid State Disk Drive will handle a worse case scenario (and thus how likely the dreaded stutter issue will happen) 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 .csv file we then found 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 333ms (one third of a second) to be a good indicator that stuttering may happen, with the higher the number the worse the duration of the stutter will most likely be.
We are not surprised that this drive acts just like the P64 did. As we said earlier, the Summit has the same NAND and same controller, there just happens to be more chips than the smaller P64. While the firmware maybe outdated it still NOT that old and as such stuttering is not an issue. The other possibility is the amount of transaction time has more to do with the RAM used rather than the controller itself as the controller relies heavily upon its ram to get the performance numbers it boasts.
Please don’t get us wrong, this drive does not stutter and these transaction speeds will NOT be noticeable in the real world.
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 report 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/Summit/OCZ_Summit_IOM.jpg" border="0" alt="" />
Talk about a funky looking happy-faced graph result. The reason it is so different from all the rest is that the firmware is slightly out dated and less refined yet its double load of NAND at low levels give the Summit that performance boost or spike seen at 1 que depth when compared to the P64. As with the Corsair, the middle levels do not fully take advantage of the large cache and only at extremely deep ends do we see a slow but steady increase in performance.
With a firmware revision or three we could conceivably see results which, while still not as good as the Indlinx, would be better than they are now.
IOMeter Stutter Test
In our usual IOMeter test we are trying to replicate real world use where reads severly outnumber writes. However, to get a good handle on how well a Solid State Disk Drive will handle a worse case scenario (and thus how likely the dreaded stutter issue will happen) 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 .csv file we then found 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 333ms (one third of a second) to be a good indicator that stuttering may happen, with the higher the number the worse the duration of the stutter will most likely be.
<img src="http://images.hardwarecanucks.com/image/akg/Storage/Summit/OCZ_Summit_stutter.jpg" border="0" alt="" />
We are not surprised that this drive acts just like the P64 did. As we said earlier, the Summit has the same NAND and same controller, there just happens to be more chips than the smaller P64. While the firmware maybe outdated it still NOT that old and as such stuttering is not an issue. The other possibility is the amount of transaction time has more to do with the RAM used rather than the controller itself as the controller relies heavily upon its ram to get the performance numbers it boasts.
Please don’t get us wrong, this drive does not stutter and these transaction speeds will NOT be noticeable in the real world.
Last edited by a moderator: