OCZ Agility 4 (256GB) Review
by Kristian Vättö on September 1, 2012 1:00 PM ESTRandom Read/Write Speed
The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews. Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see).
We perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.
The performance difference between synchronous and asynchronous NAND is pretty clear here. At queue depth of 1, 4KB random reads are heavily dependent on the speed of NAND. Queue depth of 1 means that only one I/O request is sent at a time, which means the controller can only read from one NAND at a time (write combining helps work around this issue). Increasing queue depth allows the controller to read from multiple NAND dies at the same time, which leads to better performance especially when dealing with slower NAND (you can always hide latency with parallelism). Our 4KB random read test happens at queue depth of 3, which gives the Agility 4 some breathing room but it's still enough to show the difference between asynchronous and synchronous NAND.
Note that with bigger transfers, this is not as big issue because they are usually broken into smaller pieces and striped across multiple NAND dies, again allowing the controller to utilize multiple NAND dies simultaneously. Obviously, you need a fast controller and firmware to really notice the impact of slower NAND, which is exactly what the Everest 2 is.
Random write performance isn't impacted as much by the slower NAND, not even at queue depth of 1. When reading data from an SSD, the data has to be fetched from the actual NAND, which can create a bottleneck with slower NAND. Write IOs, on the other hand, can be cached to much faster DRAM before written to NAND. Today's SSDs have fairly big caches so the NAND will have plenty of time to catch up. Of course, ultimately you will hit a wall and the NAND becomes a bottleneck. After our 20 minute torture session (4KB random writes at queue depth of 32 and 100% LBA space ran on a full drive), the Agility 4 was writing at 19.1MB/s, while 256GB Vertex 4 was chugging along at 28.4MB/s.
Sequential Read/Write Speed
To measure sequential performance we ran a one minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.
Sequential read performance is slower compared to Vertex 4 so we are definitely being limited by NAND here.
Sequential write speed is in fact on-par with Vertex 4. The bottleneck is obviously something else than NAND because quite a few drives are hitting the same speeds. We're likely running into the limits of how much parallelism you can extract from a low queue depth 128KB sequential transfer.
Facebook
Twitter
RSS
41 Comments
View All Comments
Wardrop - Sunday, September 2, 2012 - link
You guys should work on some kind type reporting method, e.g. when you highlight a portion of text in the article, is shows a button in the top-right (or bottom-right) of your selection with something like "report error". Clicking it yields a little popup form with a textarea and a submit button. On submit, it emails the author with the URL, the selected text containing the error, and the users comments.I'm not sure who your web developers is, but I personally wouldn't find this to be a difficult thing to implement in any of my Ruby applications (not Rails by the way), assuming you've already got some kind of popup framework. It'd be a matter of adding a bit of JavaScript into your article template/layout to handle the text selection button, and popup form. After that, it's just a matter of adding an endpoint on the server, e.g. http://www.anandtech.com/report_error/<article_... to handle the POST request and send the email off.
It would be a two hour job probably, but it depends on the framework you guys are using obviously, and the experience of your developer in doing this kind of thing.
Would be a worthy time investment considering that for every article, there's usually quite a number of typographic errors reported by users.
KZ0 - Sunday, September 2, 2012 - link
If not for any other reason - at least not to bloat the comment section with typo reports. I love how responsive you guys at AT are to comments and critizism, and how fast you respond, but reading about corrected typos isn't that interesting.maximumGPU - Tuesday, September 4, 2012 - link
Agreed!Impulses - Saturday, September 1, 2012 - link
I find their performance mode more disturbing than even SF's performance gap with compressible vs incompressible data... Conclusion makes total sense, it'd have to be a rather large discount for me to consider it or recommend it over the m4, 830, or M5S... Add to that all the PR problems OCZ still has due to being the first name a lot of people think of regarding last year's SF fiasco, and OCZ has a long road ahead to grab some positive mind share again.Zoomer - Saturday, September 1, 2012 - link
For these results to be valid, the drive has to be at most half full. Thus, this 256 GB drive would be effectively only have 128GB of usable capacity...throwing $/GB out the window.jb510 - Saturday, September 1, 2012 - link
I asked Anand about this drive a month or so ago in comparison to the Crucial m4. In part due to his reply I ended up buying a m4 and have been very happy with it. Still glad to see the full report of the agility4, it was tempting at the time both the m4 & a4 were $400 with the a4 being substantially newer to market.Runamok81 - Saturday, September 1, 2012 - link
In a move reminiscent of OCZs villainous 32nm / 25nm debacle,http://www.anandtech.com/show/4256/the-ocz-vertex-...
OCZ is shipping TWO flavors of this drive into the retail channel without informing consumers. It seems anandtech received the better performing (more reliable) micron NAND SSD. Why won't OCZ ship THEIR flavor of their drive for Anandtech to test?
http://images.tweaktown.com/content/4/8/4881_10_oc...
Along with its rumored increase in failure rates (tweaktown/newegg and amazon reviews), I'd be curious to see if there is a performance difference between the two flavors of the drives.
Fool me once, shame on you OCZ! Fool us twice, who should be ashamed?
hybrid2d4x4 - Saturday, September 1, 2012 - link
Asynchronous NAND drives had lower power consumption in past iterations - to what extent is this still true? How come there is no power consumption graph?Also, the A4 is slower overall in the storage bench tests than the Agility 3? What's going on here? This doesn't look like progress to me...
Kristian Vättö - Saturday, September 1, 2012 - link
Vertex 4 and Agility 4 require special power testing hardware which I don't have (our regular tools don't work with them for some reason).As for Agility 3 vs Agility 4, as I said in the article, Agility 3 gets away with async NAND because of real-time compression used by SandForce.
chris81 - Saturday, September 1, 2012 - link
Please make the same text which appears in all SSD reviews italic. It would ease skipping these:The four corners of SSD performance are as follows...