The OCZ Vertex 3 Review (120GB)
by Anand Lal Shimpi on April 6, 2011 6:32 PM ESTOCZ Listens, Again
I promised you all I would look into this issue when I got back from MWC. As is usually the case, a bunch of NDAs showed up, more product releases happened and testing took longer than expected. Long story short, it took me far too long to get around to the issue of varying NAND performance in SF-1200 drives.
What put me over the edge was the performance of the 32nm Hynix drives. For the past two months everyone has been arguing over 34nm vs 25nm however the issue isn't just limited to those two NAND types. In fact, SSD manufacturers have been shipping varying NAND configurations for years now. I've got a stack of Indilinx drives with different types of NAND, all with different performance characteristics. Admittedly I haven't seen performance vary as much as it has with SandForce on 34nm IMFT vs. 25nm IMFT vs. 32nm Hynix.
I wrote OCZ's CEO, Ryan Petersen, and Executive Vice President, Alex Mei, an email outlining my concerns last week:
Here are the drives I have:
34nm Corsair F120 (Intel 34nm NAND, 64Gbit devices, 16 devices total)
34nm OCZ Vertex 2 120GB (Hynix 32nm NAND, 32Gbit devices, 32 devices total)
25nm OCZ Vertex 2 120GB (Intel 25nm NAND, 64Gbit devices, 16 devices total)Here is the average data rate of the three drives through our Heavy 2011 Storage Bench:
34nm Corsair F120 - 120.1 MB/s
34nm OCZ Vertex 2 120GB - 91.1 MB/s
25nm OCZ Vertex 2 120GB - 110.9 MB/sIt's my understanding that both of these drives (from you all) are currently shipping. We have three different drives here, based on the same controller, rated at the same performance running through a real-world workload that are posting a range of performance numbers. In the worst case comparison the F120 we have here is 30% faster than your 32nm Hynix Vertex 2.
How is this at all acceptable? Do you believe that this is an appropriate level of performance variance your customers should come to expect from OCZ?
I completely understand variance in NAND speed and that you guys have to source from multiple vendors in order to remain price competitive. But something has to change here.
Typically what happens in these situations is that there's a lot of arguing back and forth, with the company in question normally repeating some empty marketing line because admitting the truth and doing the right thing is usually too painful. Thankfully while OCZ may be a much larger organization today than just a few years ago, it still has a lot of the DNA of a small, customer-centric company.
Don't get me wrong - Ryan and I argued back and forth like we normally do. But the resolution arrived far quicker and it was far more agreeable than I expected. I asked OCZ to commit to the following:
1) Are you willing to commit, publicly and within a reasonable period of time, to introducing new SKUs (or some other form of pre-purchase labeling) when you have configurations that vary in performance by more than 3%?
2) Are you willing to commit, publicly and within a reasonable period of time, to using steady state random read/write and steady state sequential read/write using both compressible and incompressible data to determine the performance of your drives? I can offer suggestions here for how to test to expose some of these differences.
3) Finally, are you willing to commit, publicly and within a reasonable period of time, to exchanging any already purchased product for a different configuration should our readers be unhappy with what they've got?
Within 90 minutes, Alex Mei responded and gave me a firm commitment on numbers 1 and 3 on the list. Number two would have to wait for a meeting with the product team the next day. Below are his responses to my questions above:
1) Yes, I've already talked to the PM and Production team and we can release new skus that are labeled with a part number denoting the version. This can be implemented on the label on the actual product that is clearly visable on the outside of the packaging. As mentioned previously we can also provide more test data so that customers can decide based on all factors which drive is right for them.
2) Our PM team will be better able to answer this question since they manage the testing. They are already using an assortment of tests to rate drives and I am sure they are happy to have your feedback in regards to suggestions. Will get back to you on this question shortly.
3) Yes, we already currently do this. We want all our customers to be happy with the products and any customer that has a concern about thier drives is welcome to come to us, and we always look to find the best resolution for the customer whether that is an exchange to another version or a refund if that is what the customer prefers.
I should add that this conversation (and Alex's agreement) took place between the hours of 2 and 5AM:
I was upset that OCZ allowed all of this to happen in the first place. It's a costly lesson and a pain that we have to even go through this. But blanket acceptance of the right thing to do is pretty impressive.
The Terms and Resolution
After all of this back and forth here's what OCZ is committing to:
In the coming weeks (it'll take time to filter down to etailers) OCZ will introduce six new Vertex 2 SKUs that clearly identify the process node used inside: Vertex 2.25 (80GB, 160GB, 200GB) and Vertex 2.34 (60GB, 120GB, 240GB). The actual SKUs are below:
| OCZ's New SKUs | ||||
| OCZ Vertex 2 25nm Series | OCZ Vertex 2 34nm Series | |||
| OCZSSD2-2VTX200G.25 | OCZSSD2-2VTX240G.34 | |||
| OCZSSD2-2VTX160G.25 | OCZSSD2-2VTX120G.34 | |||
| OCZSSD2-2VTX80G.25 | OCZSSD2-2VTX60G.34 | |||
These drives will only use IMFT NAND - Hynix is out. The idea is that you should expect all Vertex 2.25 drives to perform the same at the same capacity point, and all Vertex 2.34 drives will perform the same at the same capacity as well. The .34 drives may be more expensive than the .25 drives, but they also may be higher performance. Not all capacities are present in the new series, OCZ is starting with the most popular ones.
OCZ will also continue to sell the regular Vertex 2. This will be the same sort of grab-bag drive that you get today. There's no guarantee of the NAND inside the drive, just that OCZ will always optimize for cost in this line.
OCZ also committed to always providing us with all available versions of their drives so we can show you what sort of performance differences exist between the various configurations.
If you purchased a Vertex 2 and ended up with lower-than-expected performance or are unhappy with your drive in any way, OCZ committed to exchanging the drive for a configuration that you are happy with. Despite not doing the right thing early on, OCZ ultimately commited to doing what was right by its customers.
As far as ratings go - OCZ has already started publishing AS-SSD performance scores for their drives, however I've been pushing OCZ to include steady state (multiple hour test runs) incompressible performance using Iometer to provide a comprehensive, repeatable set of minimum performance values for their drives. I don't have a firm commitment on this part yet but I expect OCZ will do the right thing here as well.
I should add that this will be more information than any other SandForce drive maker currently provides with their product specs, but it's a move that I hope will be mirrored by everyone else building drives with varying NAND types.
The Vertex 2 is going to be the starting point for this sort of transparency, but should there be any changes in the Vertex 3 lineup OCZ will take a similar approach.
Facebook
Twitter
RSS
153 Comments
View All Comments
kmmatney - Thursday, April 7, 2011 - link
The answer is pretty easy, I think. Anand's own storage bench is a great test of real world performance, especially the "typical workload"http://www.anandtech.com/show/4256/the-ocz-vertex-...
The bottom line: Version 3 is better than Verion 2, although not by an amazing amount
sunbear - Thursday, April 7, 2011 - link
"3) Finally, are you willing to commit, publicly and within a reasonable period of time, to exchanging any already purchased product for a different configuration should our readers be unhappy with what they've got?"The problem is that it is not straight forward for a customer to know "what they've got" without opening up the SSD and voiding their warranty. OCZ provides the "OCZ Toolbox" that tells you whether your SSD contains 32Gb or 64Gb NAND chips but they don't currently provide any too; to determine whether you have the dreaded Hynix flash or the superior IMFT flash.
I asked in the OCZ forum and their response was to do a secure erase and run the AS SSD benchmark. I have no idea what numbers from the AS SSD benchmark would indicate Hynix versus IMFT.
cptcolo - Friday, April 8, 2011 - link
Hats off to both Anand and OCZ for fixing the Vertex 2 issue. I am really impressed by both Anand and Alex Mei. Anand thanks fo rbeing proactive and presenting OCZ with the problem, and thanks to Alex Mei and Ryan for taking care of the problem 100% (via the change in name and SKUs). You are both true alturists.B0GiE - Friday, April 8, 2011 - link
I just cancelled my order of the 120Gb OCZ Vertex. It says on Scan webpage that it is 550mbs Read and 500mbs Write.Due to this review i'm not sure i believe it. I will wait for further reviews before I purchase a new SSD.
I am interested in game load times for the Vertex 3 such as Black Ops but Anandtech does not show any???
gietrzy - Friday, April 8, 2011 - link
I've just cancelled 120GB Vertex 3 drive. I have no time to investigate whether or not my drive performs as promised.I also have a Vertex 2 60 GB I think "E" version - how do I check if it's faulty.
My scenario is #2 at this page http://www.anandtech.com/show/4256/the-ocz-vertex-...
I also have lots of 1080p avchd videos and even more raw files from my camera so I think I will wait for Intel 510 120 GB review and buy Intel.
One thing's for sure: I will never buy OCZ again.
Thanks Anand, thanks guys!
mattcpa - Friday, April 8, 2011 - link
I ordered the 120GB Vertex 3 from Computers4Sure on the morning before you published this review... :(I also picked up an HDD Optical Bay to put my MBPro 750GB HDD there and plan to put the 120GB in the 6gbps SATA.
I use the Macbook Pro 15" 2.2 SBP for laptop DJ work along with handbraking movies and such; sprinkle in some random gaming.
Hopefully for these processes, it appears this drive will still be near the top of the pack in terms of performance, as I feel I perform many read functions daily rather than performing constant writes. If someone has an opinion, let me know if I am wrong...
Affectionate-Bed-980 - Friday, April 8, 2011 - link
Come on. You HAVE to compare against last generation's Vertex 2. It's selling for $169 at Newegg, and you don't even bench against that. Sigh. Like it's fine if you miss out on some of the other ways say the Kingston, but to skip on the Vertex 2 is a major /facepalm.Shark321 - Friday, April 8, 2011 - link
Yes, Vertex 2 and Agility 2 benchmarks compared to Vertex 3 would be really helpful here.db808 - Friday, April 8, 2011 - link
Hi Anand,First, let me join in with the others in complementing you on your excellent article.
I saw some interesting data hidden in the information describing the IO access patterns of your new IO benchmarks. I was very surprised that the IO size was so small, and that you mentioned that a majority of the IO was sequential.
Some of this can be explained by the multi-threaded nature of the tests. Two applications, each doing sequential IO, running against each other, result in interleaved IOs going to the disk, with a result that is very non-sequential. Some of this may be explained by the application runtime actually requesting 4kb IO, and Windows not having time to do "read aheads".
Windows does have the capability to do larger-IO than was requested by the application (opportunistic IOs), as well as read-ahead and write behinds(that are often coalesced into larger IOs) ... but SSDs may actually be so fast, that the Windows IO optimization algorithms don't have enough time to "think".
You also pointed out that SSD IO performance increases very quickly has the IO size increases above 4kb. It appears that most of the modern controllers parallel stripe the IO across multiple channels, wear-leveling notwithstanding. So an 8kb IO is 2 parallel 4kb IO, for example (ignoring SandForce compression behavior).
The simplest way to cajole the large share of 4kb IO's to 8kb or larger sizes is to simply increase the NTFS cluster size. This has been a performance optimization techniques used with high performance storage arrays for many years. Many Unix systems actually default to 8kb or larger block sizes, and EMC internally uses a 32kb block size as examples.
There is a small negative tradeoff ... some additional slack space at the end of every file. The average slack space per file is 1/2 the cluster size, or 2kb for the default 4kb cluster. Increasing the cluster to 8kb, increases the slack space to 4kb per file ... for a 64kb cluster, it would be 32kb slack per file. The JAM Software "Treesize" utility will actually compute the total slack space for you. With TreeSize Pro, you can even do "what if" analysis and see the impact of changing the cluster size on total slack space.
In summary, slack space overhead only represent a few percentage points of the disk capacity. For example, on my business laptop, by C: drive has about 262K files, and my total wasted space is ~ 644 MB. Increasing the cluster size to 8kb would roughly double my wasted space ... an additional 644MB. Not much.
On my hard-disk based systems that are also memory rich, I regularly run NTFS cluster sizes of 8kb and 16kb ... 64kb for temp file systems. I am pro-actively trading a few percentage points of disk space for higher performance levels. The cost of a few GB of extra overhead on a 1TB disk is a no brainer.
But SSDs are a lot more expensive, and space is a lot tighter. I use a SSD as a boot disk on one PC, and I've filled it about 1/2 full, with the OS, applications, page, hibernate, and temps. Performance is great, and the 40%-ish free space is a form of over-provisioning.
My performance was so good, I had not yet experimented with increasing my cluster size, because I was not able to quantify what the IO size profile looked like. Your IO size statistics from your IO storage benchmark was very enlightening as it shows the (unexpected) large amount of small IO.
On Sandforce-based SSDs, the controller would compress away all the slack space at the end a file, since Windows pads the last cluster in a file with zeros. So with a larger cluster size, your file system would look fuller under Windows, but all the extra slack space would be compressed on the SSD ... with little detriment to the over-provisioning headroom.
I know you are exceedingly busy, but it would be extremely interesting to be able to re-run your controlled test environment with the Anand IO Storage 2011 tests on systems that were built with different cluster sizes. I suspect that using a larger cluster size would improve performance on all SSDs, with SSDs with weaker performance showing the most relative gain. From what I have read, increasing the cluster size beyond 16kb (for Sandforce controllers) will have diminishing (but still positive) returns.
Increasing a Windows 7 boot disk's cluster size from 4kb to 16 kb would increase the wasted space about 4-fold. On my system that would be less than 3GB. It could be a worthwhile trade for performance.
Another reason to explore larger cluster sizes is the fact that the new 28nm Flash chips typically have page sizes of 8kb, not the smaller 4kb used in the 32/34 nm Flash chips. When Windows does 4kb IO on these new 28nm Flash SSDs, it is actually doing sub-page IO, causing the controller to perform a read/modify/write function, and increasing the write amplification effect. The impact would be similar to doing 2kb IO on the SSDs with 4kb page sizes.
If you assume that the typical compression factor is 2:1 for Sandforce controllers, a 16kb NTFS cluster would often be compressed to fit in a single 8kb page ... sounds like a sweet spot.
Using a larger cluster size, also decrease the amount of work needed to append to a file, as fewer clusters need to be allocated. The cluster size also defines the lower limit of contiguousness. This could be important on SSDs, since we normally don't run defrag utilities on SSDs, so we know that fragmentation will only get worse over time.
I will point out that using larger cluster sizes may increase memory usage for the kernel buffer pool, and/or reduce the effective number of buffers for a buffer pool of a given size. I only recommend increasing cluster sizes on systems in a "memory rich" environment.
Again, thank you for your excellent report. Exploring the impact of larger cluster sizes, especially on 28nm based SSDs could add an additional dimension to your analysis. 8kb and larger cluster sizes could further improve real-world SSD performance, and mask some of the performance drop from using the 28nm chips.
db
mpx999 - Sunday, April 10, 2011 - link
That's a big limitation for number of total I/Os. Eg. in 300MB/s SATA-II you'd be limited to ~37.5k IOPS with 8kB transfers, less than some SSDs are capable of, while the limit with 4kB clusters is 2 times higher, which is still beyond current SSDs for random transfers.4kB clusters are a perfect match for x86 processors that use hardware 4kB page size, as each page size is one block on disk. This is especially important for pagefile reads, which tend to be random by nature, rather than pagefile writes that are mostly sequential dumps of memory content. Some Unix systems may use 8kB disc block sizes because it's a default page size for SPARC and Itanium processors. For Power and ARM 4kB is the default but also 64kB can be used. So I'd advice against using large (larger than hw. page size) block sizes on a system/boot partition.
8kB disk block sizes can be useful on partitions dedicated for SQL Server as default database blocks are 8kB for SQL Server, so it's doing 8kB transfers anyway. Oracle supports multiple page sizes and their advice is:
http://www.dba-oracle.com/t_multiple_blocksizes_su...
"Oracle recommends smaller Oracle Database block sizes (2 KB or 4 KB) for online transaction processing (OLTP) or mixed workload environments and larger block sizes (8 KB, 16 KB, or 32 KB) for decision support system (DSS) workload environments."
32kB cluster sizes are a default value on flash cards for digital cameras, as sequential writes of large prictures are done on them.
BTW. The slow speed of both Hynix and Intel 25nm versions of Vertex 2 may be because it's aging controller cannot deal with 8kB flash pages.