OCZ Vector (256GB) Review
by Anand Lal Shimpi on November 27, 2012 9:10 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). I 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.
Low queue depth random read performance sees a significant regression compared to the Vertex 4. OCZ derives the Vector's specs at a queue depth of 32, at which it'll push 373MB/s of 4KB random reads. As Intel has established in the past, low queue depth random read performance of around 40 - 50MB/s is sufficient for most client workloads as we'll soon see in our trace based storage bench suite.
Low queue depth random write performance is a very different story, here the Vector pretty much equals the Vertex 4's already excellent score.
Many of you have asked for random write performance at higher queue depths. What I have below is our 4KB random write test performed at a queue depth of 32 instead of 3. While the vast majority of desktop usage models experience queue depths of 0 - 5, higher depths are possible in heavy I/O (and multi-user) workloads:
Crank up the queue depth and the Vector does well, but Samsung's SSD 840 Pro manages a nearly 10% performance advantage here.
Steady State 4KB Random Write Performance
OCZ will surely derive enterprise versions of the Vector and its Barefoot 3 controller, but I was curious to see what steady state 4KB random write performance looked like on the drive. I grabbed some of our Enterprise Iometer results from the S3700 review and trimmed out the non-SATA drives. The results are hugely improved compared to the Vertex 4:
Keep in mind this isn't an enterprise drive, and thus it's not too surprising to see significantly higher numbers here from other enterprise drives but the improvement over the Vertex 4 is substantial. Note that Samsung's SSD 840 Pro lands somewhere in between the Vector and Vertex 4.
Facebook
Twitter
RSS
151 Comments
View All Comments
kmmatney - Tuesday, November 27, 2012 - link
I don't see anything wrong with stating that. My 256 Samsung 830 also appears as a 238GB drive in windows...jwilliams4200 - Tuesday, November 27, 2012 - link
The problem is that "formatting" a drive does not change the capacity.Windows is displaying the capacity in GiB, not GB. It is just Windows bug that they label their units incorrectly.
Gigaplex - Tuesday, November 27, 2012 - link
Yes and no. There is some overhead in formatting which reduces usable capacity, but the GiB/GB distinction is a much larger factor in the discrepancy.jwilliams4200 - Wednesday, November 28, 2012 - link
The GiB/GB bug in Windows accounts for almost all of the difference. It is not worth mentioning that partitioning usually leaves 1MiB of space at the beginning of the drive. 256GB = 238.4186GiB. If you subtract 1MiB from that, it is 238.4176GiB. So why bother to split hairs?Anand Lal Shimpi - Wednesday, November 28, 2012 - link
This is correct. I changed the wording to usable vs. formatted space, I was using the two interchangeably. The GiB/GB conversion is what gives us the spare area.Take care,
Anand
suprem1ty - Thursday, November 29, 2012 - link
It's not a bug. Just a different way of looking at digital capacity.suprem1ty - Thursday, November 29, 2012 - link
Oh wait sorry I see what you mean now. Disregard previous postflyingpants1 - Wednesday, November 28, 2012 - link
I think I might know what his problem is.When people see their 1TB-labelled drive displays only 931GB in Windows, they assume it's because formatting a drive with NTFS magically causes it to lose 8% of space, which is totally false. Here's a short explanation for newbie readers. A gigabyte (GB) as displayed in Windows is actually a gibibyte (GiB).
1 gibibyte = 1073741824 bytes = 1024 mebibytes
1 gigabyte = 1000000000 bytes = 1000 megabytes = 0.931 gibibytes
1000 gigabytes = 931 gibibytes
Windows says GB but actually means GiB.
SSDs and HDDs are labelled differently in terms of space. Let's say they made a spinning hard disk with exactly 256GB (238GiB) of space. It would appear as 238GB in Windows, even after formatting. You didn't lose anything,
because the other 18 gigs was never there in the first place.
Now, according to Anandtech, a 256GB-labelled SSD actually *HAS* the full 256GiB (275GB) of flash memory. But you lose 8% of flash for provisioning, so you end up with around 238GiB (255GB) anyway. It displays as 238GB in Windows.
If the SSDs really had 256GB (238GiB) of space as labelled, you'd subtract your 8% and get 235GB (219GiB) which displays as 219GB in Windows.
flyingpants1 - Wednesday, November 28, 2012 - link
IMO drive manufacturers should stop messing around and put 256GiB of USABLE space on each 256GiB drive, and start marking them as such.Holly - Wednesday, November 28, 2012 - link
Tbh imho using base 10 units in binary environment is just asking for a facepalm. Everything underneath runs on 2^n anyway and this new "GB" vs "GiB" is just a commercial bullshit so storage devices can be sold with flashier stickers. Your average raid controller bios will show 1TB drive as 931GB one as well (at least few ICHxR and one server Adaptec I have access to right now all do).