OCZ Vector (256GB) Review
by Anand Lal Shimpi on November 27, 2012 9:10 PM ESTPerformance vs. Transfer Size
ATTO does a good job of showing us how sequential performance varies with transfer size. Most controllers optimize for commonly seen transfer sizes and neglect the rest. The optimization around 4KB, 8KB and 128KB transfers makes sense given that's what most workloads are bound by, but it's always important to understand how a drive performs across the entire gamut.
Vector clearly attempts to shift the Vertex 4's performance curve up and towards that of Samsung's SSD 840 Pro. There's a fairly repeatable anomaly at 32KB and 64KB where performance drops down to Vertex 4 levels, but generally speaking there's a tangible improvement across the board. My guess is whatever is happening at 32KB and 64KB is a bug though. Barefoot 3 has no issues parallelizing workloads that are smaller.
I would still like to see improved 512B transfer performance, but other than Samsung it doesn't look like anyone is really focusing on smaller-than-4KB performance anymore. Even Intel has pretty much abandoned focusing on it with its S3700 controller. I may just have to give up caring about it. Smaller than 4KB performance really doesn't impact most client workloads, it's really the weird corner cases where it would matter. Just don't go off and use any of these drives under Windows XP and you'll be fine.
When it comes to write performance, OCZ has delivered a solution that seems to be a hair quicker than the 840 Pro in many of the smaller transfer sizes, and a lot faster once we get to the larger block sizes. Performance vs. the Vertex 4 is clearly improved, and there's only a mild indication of whatever weird issue was happening in the read test.
Facebook
Twitter
RSS
151 Comments
View All Comments
dj christian - Thursday, November 29, 2012 - link
"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. "
Uuh what?
sully213 - Wednesday, November 28, 2012 - link
I'm pretty sure he's referring to the amount of NAND on the drive minus the 6.8% set aside as spare area, not the old mechanical meaning where you "lost" disk space when a drive was formatted because of base 10 to base 2 conversion.JellyRoll - Tuesday, November 27, 2012 - link
How long does the heavy test take? The longest recorded busy time was 967 seconds from the Crucial M4. This is only 16 minutes of activity. Does the trace replay in real time, or does it run compressed? 16 minutes surely doesnt seem to be that much of a long test.DerPuppy - Tuesday, November 27, 2012 - link
Quote from text "Note that disk busy time excludes any and all idles, this is just how long the SSD was busy doing something:"JellyRoll - Tuesday, November 27, 2012 - link
yes, I took note of that :). That is the reason for the question though, if there were an idea of how long the idle periods were we can take into account the amount of time the GC for each drive functions, and how well.Anand Lal Shimpi - Wednesday, November 28, 2012 - link
I truncate idles longer than 25 seconds during playback. The total runtime on the fastest drives ends up being around 1.5 hours.Take care,
Anand
Kristian Vättö - Wednesday, November 28, 2012 - link
And on Crucial v4 it took 7 hours...JellyRoll - Wednesday, November 28, 2012 - link
Wouldn't this compress the QD during the test period? If the SSDs recorded activity is QD2 for an hour, then the trace is replayed quickly this creates a high QD situation. QD2 for an hour compressed to 5 minutes is going to play back at a much higher QD.dj christian - Thursday, November 29, 2012 - link
What is QD?doylecc - Tuesday, December 4, 2012 - link
Que Depth