Sequential Performance – HDTach, HDTune, File Copy, YAPT (sequential)
We have shifted over to combining our results into two groupings for consumer reviews. First up is sequential performance:
HDTach:
HD Tach will test the sequential read, random access and interface burst speeds of your attached storage device (hard drive, flash drive, removable drive, etc). All drive technologies such as SCSI, IDE/ATA, 1394, USB, SATA and RAID are supported. HDTach tests sequential performance by issuing reads in a manner that was optimized more for HDD access, but this unique method has proven useful in evaluating the sequential response time of SSDs. The accesses are relatively small in size (2k), and are issued with a single working thread (QD=1). The end result is that devices with relatively IO high latency will not reach their ultimate rated speed.
Good QD=1 sequentials from the Vector 180, with slight drop at the 240GB capacity.
HDTune:
HDTune tests a similar level of features as compared with HDTach, but with a different access pattern. Thus provides us with an additional set of benchmark numbers to compare between storage configurations. CPU utilization has proven negligible with modern processing horsepower, and is no longer included. Additionally, we do not include write performance due to HDTune's write access pattern not playing nicely with most SSDs we have tested it on.
The lowest capacity Vector sees the lowest read speeds and most variance during those reads (compare directly against the equivalent capacity Crucial M550 256GB).
PCPer File Copy Test
Our custom PCPer-FC test does some fairly simple file creation and copy routines in order to test the storage system for speed. The script creates a set of files of varying sizes, times the creation process, then copies the same files to another partition on the same hard drive and times the copy process. There are four file sizes that we used to try and find any strong or weak points in the hardware: 10 files @ 1000 MB each, 100 files @ 100 MB each, 500 files @ 10 MB each and 1000 files at 1 MB each.
The tool that does the file creation does so in a single threaded manner, so that that into account when considering the above results. You may note a steadily longer duration for the increasing capacity Vector 180 samples in this test – and those increses do not happen as badly at the largest transfer size. This is because the Vector 180 essentially stops all writing where a file deletion has recently taken place, and the size of the files deleted determines how long it stalls. In the sequence above, the 100@100MB test starts after deleting the 10x 1000MB files from the prior test, and the Vector 180 halts all writes as it TRIMs the data, causing the abnormally long times to complete each subsequent test. The 100@100MB test is bad for the 960GB Vector 180 just about as slow as a 1TB VelociRaptor (yes, a HDD) in that test and all three capacities of the Vector 180 are all *slower* than the HDD in the 500@10MB test. More on that later in this article.
File copies uses a batch copy from within Windows, and sees added threading compared to our file creation test. These take place long enough after the TRIM operations that all SSDs turn in reasonably consistent figures here.
YAPT:
YAPT (yet another performance test) is a benchmark recommended by a pair of drive manufacturers and was incredibly difficult to locate as it hasn't been updated or used in quite some time. That doesn't make it irrelevant by any means though, as the benchmark is quite useful. It creates a test file of about 100 MB in size and runs both random and sequential read and write tests with it while changing the data I/O size in the process. The misaligned nature of this test exposes the read-modify-write performance of SSDs and Advanced Format HDDs.
Back when we looked at the Radeon R7, we figured those few dips in performance were just an anomaly. When we add in the results of the Vector 180s, we see more seemingly random drops in performance. We will explain these anomalies later in this article.
Man, Allyn, you really
Man, Allyn, you really reestablished my faith in you. Historically, you have been very easy on OCZ SSD’s, often giving them the benefit of the doubt with respect to problems with them at review time that you assumed would be fixed eventually by firmware updates and lower pricing. Just saying, with the conclusions you reached, this is a drive I will definitely be steering clear of.
thanks
As the saying goes: “Fool me
As the saying goes: "Fool me once…"
“There’s an old saying in
“There’s an old saying in Tennessee — I know it’s in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can’t get fooled again.”
There’s some genuine
There’s some genuine investigative reporting going on there in the fifth page of this review and it’s very refreshing. Nicely done Mr. Malventano.
In my view page 5 basically blows the lid off of OCZ and the reliability of their Barefoot controller. Despite reporting from most outlets, for years now drives based off of this technology have suffered massive failure rates due to sudden power loss. Here we have definitive evidence of those flaws and the lengths OCZ is going to in order to work around them (note, i didn’t say ‘fix’ them).
The fact that they were willing to go to the extra cost of adding the power loss module in addition to crippling the sustained performance of their flagship drive in order to flush the cache out of DRAM speaks VOLUMES about how bad their reliability was before. You don’t go to such extreme – potentially kiss of death measures – without a good boot up your ass pushing you headlong toward them. In this case said boot was constructed purely out of OCZ’s fear that releasing yet ANOTHER poorly constructed drive would finally put their reputation out of it’s misery for good and kill any chance a future sales.
OCZ has cornered themselves in a no win scenario:
1) They don’t bother making the drive reliable and in doing so save the cost of the power loss module and keep the sustained speed of the Vector 180 high. The drive reviews well with no craters in performance and the few customers OCZ has left buy another doomed Barefoot SSD that’s practically guaranteed to brick on them within a few months. As a result they loose those customers for good along with their company.
or
2) The go to the cost of adding the power loss module and cripple the drives performance to ensure that the drive is reliable. The drive reviews horribly and no one buys it.
This is their position. Kiss of death indeed.
Ultimately, i think it speaks to how complicated controller development is and that if you don’t have a huge company with millions of R&D funds at your disposal it’s probably best if you don’t throw your hat into that ring. It’s a shame but it seems to be the way high tech works. (Global oligopoly, here we come.)
All things considered, it’s nice that this is finally all out in the open. Thanks Allyn.
Somehow I’m not suprised.
Somehow I’m not suprised.
You tested the Vector 180
You tested the Vector 180 with the new 1.01 firmware, but was the Radeon R7 also updated to 1.01, as OCZ recommends? Does it show the same write hitching?
The R7 results in this piece
The R7 results in this piece were based on the initial firmware. We're going to take a closer look at all other M00 based drives (with updates applied) now that we've uncovered this behavior.
beta testing on consumers.
beta testing on consumers. fail products fail company fail fail fail! all computer parts should handle power fails the same way: not requiring a 2-3 week rma. ocz should not exist anymore.
>Blah-blah-blah
>Blah-blah-blah walloftextsomethingsomething blah-blah-somethingwalloftext-blah-somethingsomethingwalloftext >aaand…it’s crap.
You should have said so right away, d00ds.
“Write hitching”. I first saw
“Write hitching”. I first saw that and all I could think of was the the old stuttering jmicron controllers….on older OCZ drives no less. Bad memories.
Now you show compelling evidence on why you might want to flat out avoid drives with Barefoot controllers.
Love these in-depth articles. Awesome job as usual.
Even though JMicron was
Even though JMicron was always slow as hell (and still is even these days), AT LEAST IT DIDN’T FAIL RIGHT OUT OF IT’S ASS, like that SandForce trash does all the time. JMicron’s stuff slow, true, but also one of the more reliable controllers out there.
As a data point, no JMicron
As a data point, no JMicron controller we ever tested halted all writes for more than one second, and it certainly didn't do so every 20 seconds.
How long is it going to take
How long is it going to take to forget-
“Friends DON’T let friends OCZ”
Unless you’re buying their
Unless you’re buying their “extremely-rare-now-since-they’re-not-doing-them-anymore” PSUs, that is.