OCZ Apex 120GB SSD Review

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 reporst 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.


Hmm, it appears the X-25M just condenses the other drives results too much to get a good idea of how the competitors perform. Heck, the APEX is so close to the Titan they overlap at this graph size! Lets yank the X-25M and Warp V2 to get a better idea of its results compared to the Titan.


Zoomed-in Version


Ack…refinement or no, this generation of Samsung drives simply hate the IOMeter tests. We were really hoping to see a marked improvement in this test as we have seen in all the others and instead were greeted with a minor decrease in performance if anything. To bad OCZ engineers can’t perform miracles as this RAID 0 generation’s RAID controller is certainly a less than optimal solution.

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 SSD 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 any number under 100ms (.1 of second) to be very good, 100 – 200 (decent), 200 – 300 (acceptable) and anything higher than this to be a good indicator that stuttering may happen and the higher the number the worse the duration of the stutter will most likely be.


The average write time is still not that great but both it and the maximum amount of time have been improved. It appears that the higher average write time is just the cost associated with lowering the maximum time and there was not much OCZ’s engineers could do about it. We firmly believe the added latency is due to the sub optimal RAID controller and the underpowered JM602s used. We are sure that if OCZ had not only tweaked the firmware but used different controllers these times would be even better. As it is they are certainly respectable enough and we are more worried about shortening stutters than worrying about small, barely perceivable write time lags.