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

Sequential IO Performance Performance Consistency
Comments Locked

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 post
  • flyingpants1 - 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).

Log in

Don't have an account? Sign up now