Times are changing at OCZ. There's a new CEO at the helm, and the company is now focused on releasing fewer products but that have gone through more validation and testing than in years past. The hallmark aggressive nature that gave OCZ tremendous marketshare in the channel overstayed its welcome. The new OCZ is supposed to sincerely prioritize compatibility, reliability and general validation testing. Only time will tell if things have changed, but right off the bat there's a different aura surrounding my first encounter with OCZ's Vector SSD.

Gone are the handwritten notes that accompanied OCZ SSD samples in years past, replaced by a much more official looking letter:

The drive itself sees a brand new 7mm chassis. The aluminum colored enclosure features a new label. Only the bottom of the SSD looks familiar as the name, part number and other details are laid out in traditional OCZ fashion.

Under the hood the drive is all new. Vector uses the first home-grown SSD controller by OCZ. Although the Octane and Vertex 4 SSDs both used OCZ Indilinx branded silicon, they were both based on Marvell IP - the controller architecture was licensed, not designed in house. Vector on the other hand uses OCZ's brand new Barefoot 3 controller, designed entirely in-house.

Barefoot 3 is the result of three different teams all working together. OCZ's UK design team, staffed with engineers from the PLX acquisition, the Korea design team inherited after the Indilinx acquisition, and folks at OCZ proper in California all came together to bring Barefoot 3 and Vector to life.

The Barefoot 3 controller integrates an unnamed ARM Cortex core as well as an OCZ Aragon co-processor. OCZ isn't going into a lot of detail as to how these two cores interact or what they handle, but multi-core SoCs aren't anything new in the SSD space. A branded co-processor is a bit unusual, and I suspect that whatever is responsible for Vector's distinct performance has to do with this part of the SoC.

Architecturally, Barefoot 3 can talk to NAND across 8 parallel channels. The controller is paired with two DDR3L-1600 DRAMs, although there's a pad for a third DRAM for use in the case where parity is needed for ECC.

Hardware encryption is not presently supported, although OCZ tells us Barefoot 3 is more than fast enough to handle it should a customer demand the feature. Hardware encryption remains mostly unused and poorly executed on client drives, so its absence isn't too big of a deal in my opinion.

OCZ does its own NAND packaging, and as a result Vector is home to a sea of OCZ branded NAND devices. In reality you're looking at 25nm IMFT synchronous 2-bit-per-cell MLC NAND, just with an OCZ silkscreen on it. There's no NAND redundancy built in to the drive as OCZ is fairly comfortable with the error and failure rates at 25nm. The only spare area set aside is the same 6.8% we see on most client drives (e.g. a 256GB Vector offers 238GB usable space in Windows).

OCZ Vector
  128GB 256GB 512GB
Sequential Read 550 MB/s 550 MB/s 550 MB/s
Sequential Write 400 MB/s 530 MB/s 530 MB/s
Random Read 90K IOPS 100K IOPS 100K IOPS
Random Write 95K IOPS 95K IOPS 95K IOPS
Active Power Use 2.25W 2.25W 2.25W
Idle Power Use 0.9W 0.9W 0.9W

Regardless of capacity, OCZ is guaranteeing the Vector for up to 20GB of host writes per day for 5 years. The warranty on the Vector expires after 5 years or 36.5TB of writes, whichever comes first. As with most similar claims, the 20GB value is pretty conservative and based on a 4KB random write workload. With more realistic client workloads you can expect even more life out of the NAND.

Despite being built on a brand new SoC, there's a lot of firmware carryover from Vertex 4. Indeed if you look at the behavior of Vector, it is a lot like a much faster Vertex 4. OCZ does continue to use its performance mode that enables faster performance if less than 50% of the drive's capacity is used, however in practice OCZ seems to rely on it less than in the Vertex 4.

The design cycle for Vector is the longest OCZ has ever endured. It took OCZ 18 months to bring the Vector SSD to market, compared to less than 12 months for previous designs. The additional time was used not only to coordinate teams across the globe, but also to put Vector through more testing and validation than any previous OCZ SSD. It's impossible to guarantee a flawless drive, but doing considerably more testing can't hurt.

The Vector is available starting today in 128GB, 256GB and 512GB capacities. Pricing is directly comparable to Samsung's 840 Pro:

OCZ Vector Pricing (MSRP)
  64GB 128GB 256GB 512GB
OCZ Vector - $149.99 $269.99 $559.99
Samsung SSD 840 Pro $99.99 $149.99 $269.99 $599.99

OCZ is a bit more aggressive on its 512GB MSRP, otherwise it's very clear what OCZ views as Vector's immediate competition.

Random IO Performance
Comments Locked


View All Comments

  • melgross - Wednesday, November 28, 2012 - link

    What does that mean; usable space? Every OS leaves a different amount after formatting, so whether the drive is rated by GB or GiB, the end result would be different. Normally, SSD's are rated as to the around seen by the OS, not by that plus the around overrated. So it isn't really a problem.

    Actually, the differences we're talking about isn't all that much, and is more a geeky thing to concern oneself with more than anything else. Drives are big enough, even SSD's, so that a few GB's more or less isn't such a big deal.
  • Kristian Vättö - Wednesday, November 28, 2012 - link

    An SSD can't operate without any over-provisioning. If you filled the whole drive, you would end up in a situation where the controller couldn't do garbage collection or any other internal tasks because every block would be full.

    Drive manufacturers are not the issue here, Microsoft is (in my opinion). They are using GB while they should be using GiB, which causes this whole confusion. Or just make GB what it really is, a billion bytes.
  • Holly - Thursday, November 29, 2012 - link

    Sorry to say so, but I am afraid you look on this from wrong perspective. Unless you are IT specialist you go buy a drive that says 256GB and expect it to have 256GB capacity. You don't care how much additional space is there for replacement of bad blocks or how much is there for internal drive usage... so you will get pretty annoyed by fact that your 256GB drive would have let's say 180GB of usable capacity.

    And now this GB vs GiB nonsense. From one point of view it's obvious that k,M,G,T prefixes are by default *10^3,10^6,10^9,10^12... But in computers capacity units they used to be based on 2^10, 2^20 etc. to allow some reasonable recalculation between capacity, sectors and clusters of the drive. No matter what way you prefer, the fact is that Windows as well as many IDE/SATA/SAS/SCSI controllers count GB equal to 2^30 Bytes.

    Random controllers screenshots from the internet:

    Also, if you say Windows measurement is wrong, why is RAM capacity shown in 'GB' but your 16GB shown in EVERY BIOS in the world is in fact 16384MiB?

    Tbh there is big mess in these units and pointing out one thing to be the blame is very hasty decision.

    Also, up to some point the HDD drive capacity used to be in 2^k prefixes long time ago as well... still got old 40MB Seagate that is actually 40MiB and 205MB WD that is actually 205MiB. CD-Rs claiming 650/700MB are in fact 650/700MiB usable capacity. But then something changed and your 4.7GB DVD-R is in fact 4.37GiB usable capacity. And same with hard discs...

    Try to explain angry customers in your computer shop that the 1TB drive you sold them is 931GB unformatted shown both by controller and Windows.

    Imho nobody would care slightest bit that k,M,G in computers are base 2 as long as some marketing twat didn't figure out that his drive could be a bit "bigger" than competition by sneaking in different meaning for the prefixes.
  • jwilliams4200 - Thursday, November 29, 2012 - link

    It is absurd to claim that "some marketing twat didn't figure out that his drive could be a bit "bigger" than competition by sneaking in different meaning for the prefixes".

    The S.I. system of units prefixes for K, M, G, etc. has been in use since before computers were invented. They have always been powers of 10. In fact, those same prefixes were used as powers of ten for about 200 years, starting with the introduction of the metric system.

    So those "marketing twats" you refer to are actually using the correct meaning of the units, with a 200 year historical precedent behind them.

    It is the johnny-come-latelys that began misusing the K, M, G, ... unit prefixes.

    Fortunately, careful people have come up with a solution for the people incorrectly using the metric prefixes -- it is the Ki, Mi, Gi prefixes.

    Unfortunately, Microsoft persists in misusing the metric prefixes, rather than correctly using the Ki, Mi, Gi prefixes. That is clearly a bug in Microsoft Windows. Kristian is absolutely correct about that.
  • Holly - Friday, November 30, 2012 - link

    How much RAM does your bios report you have?
    Was the BIOS of your motherboard made by Microsoft?
  • jwilliams4200 - Friday, November 30, 2012 - link

    Would you make that argument in front of a judge?

    "But judge, lots of other guys stole cars also, it is not just me, so surely you can let me off the hook on these grand-theft-auto charges!"
  • Touche - Saturday, December 1, 2012 - link

    No, he is right. Everything was fine until HDD guys decided they could start screwing customers for bigger profits. Microsoft and everyone else uses GB as they should with computers. It was HDD manufacturers that caused this whole GB/GiB confusion regarding capacity.
  • jwilliams4200 - Saturday, December 1, 2012 - link

    I see that you are a person who never lets the facts get in the way of a conspiracy theory.
  • Touche - Monday, December 3, 2012 - link

  • Holly - Monday, December 3, 2012 - link

    Well, 2^10k prefixes marked with 'i' were made in a IEC in 1998, in IEEE in 2005, alas the history is showing up frequent usage of both 10^3k and 2^10k meanings. Even with IEEE passed in 2005 it took another 4 years for Apple (who were the first with OS running with 2^10k) to turn to 'i' units and year later for Ubuntu with 10.10 version.

    For me it will always make more sense to use 2^10k since I can easily tell size in kiB, MiB, GiB etc. just by bitmasking (size & 11111111110000000000[2]) >> 10 (for kiB). And I am way too used to k,M,G with byte being counted for 2^10k.

    Some good history reading about Byte prefixes can be found at http://en.wikipedia.org/wiki/Timeline_of_binary_pr... ...

    Ofc, trying to reason with people who read several paragraph post and start jumping around for one sentence they feel offended with is useless.

    But honestly even if kB was counted for 3^7 bytes it wouldn't matter... as long as everyone uses the same transform ratio.

Log in

Don't have an account? Sign up now