Back in April, we published one of the first reviews of OCZ's Vertex 4. In those three months, the company has issued three firmware updates, with a fourth reportedly in the pipeline. We take another look at the drive using its latest software.
Early last month, OCZ released firmware version 1.4RC for its Vertex 4 SSDs. The update was deliberately destructive, meaning it wiped drives clean. When a company goes to the trouble of issuing an update like that, you know something significant is happening under the hood.
In this case, the 128, 256, and 512 GB drives received minor sequential read performance improvements, while the 128 and 256 GB drives purportedly enjoyed massive sequential write speed enhancements (from 200 to 420 MB/s, in the case of the 128 GB model).
Since that introduction, OCZ has rolled out revisions 1.4.1.2 and 1.4.1.3, which appear to correct bugs, rather than augmenting performance further. We do hear, however, that the imminent release of firmware 1.5 will provide the Vertex 4s with additional performance.
The table below reflects the same information presented in our earlier news post. Mainly: sequential writes speed is most significantly impacted by firmware 1.4.

So, within three months of our initial review (OCZ Vertex 4 Review: A Flagship SSD Powered By...Indilinx?), one of OCZ's newest SSDs has had its performance profile almost completely transformed. But do you end up making any compromises for the additional sequential write speed? Today, we take a look at the 128 GB Vertex 4's exceptional sequential performance results, which, to date, have only been achieved by competing architectures heavily reliant on compression algorithms.
Test Setup
| Test System | |
|---|---|
| CPU | Intel Core i7-2700K (Sandy Bridge), 3.5 GHz, 8 MB Shared L3 Cache, Hyper-Threading enabled, Power-saving features enabled |
| Motherboard | Asus P8Z68-V, Z68 Express Chipset, LGA 1155, BIOS 3402 |
| Memory | 4 x 4 GB Corsair Vengeance DDR3-1600 |
| Graphics | AMD Radeon HD 6970 2 GB |
| Storage | OCZ Vertex 4 128 GB, SATA 6Gb/s, Firmware 1.4.1.3 |
| Software Setup | |
| Operating System | Windows 7 Ultimate x64 Service Pack 1 |
| Intel Chipset Drivers | 10.8.0.1003 |
| AMD Graphics | Catalyst 12.4 |
| Benchmarks | |
| HD Tune Pro | 5.00 |
| Anvil's Storage Utility | RC2 |
| Iometer | 2006.07.27 |
Why can't you just get the consistent performance like you do on samsung 830's ad crucial m4's, there is nothing wrong with consistency.
i was almost on the point of buying a 128GB Vertex4.
NOT NOW. will wait for the next 1.5 firmware.
its strange that such type of behavior was documented on Toms only, while multiple other sites have already reviewed this drive with 1.4 fw, giving it a very good rating.
+1 to Toms review team
They also tell me that Tom's Hardware is actually aware of this.
Read about it here: http://www.ocztechnologyforum.com/forum/showthread.php?102254-Anormal-128GB-Vertex-4-Performance
I read that RAID doesn't support TRIM (never checked beyond that) so I've not bothered with it. Have you done any tests with this?
I am sorry, but there should be never be a slow down, this is ssd, people expect top speed all the time from their drives.
Reading Comprehension Fail... Let say you have a 20 Gigabytes of Free Space (The SSD has 512GB total).
If you try to write a file that is more than 10 GB you'll experience less than optinum performance.
Note we are talking about Sequential Writing.
i understand very well, during the momentary transition from performance mode to storage mode there is a temporary slowdown. How come other vendors don't exhibit this issue, I dont get why ocz would create a problem for themselves, why have two storage modes? Make life simple, make one storage mode.
Its improbable you'll ever experience this slow down.
No testing needed, it simply doesn't work in the overwhelming majority of RAID controllers. Intel produced a beta version of their RST driver that enables RAID 0 support, and there's some really limited support in Linux via dmraid, but that's pretty much it in terms of RAID support and TRIM.
While OCZ won't fully explain the reasonings behind this (trade secrets and whatnot), it seems that the likely case is to actually improve upon the performance in low-capacity situations.
As I'm sure you know, as a SSD fills up, it slows down. I'd imagine that the shift, then, is to rework the storage algorithms for the Vtx4 to improve speeds in this more-filled state. If you read the thread Todd Suave posted, you'll get a much better explanation from much smarter people than I.
Second, the dual storage modes is smart actually. Misleading, but smart. "Performance" mode is obviously MLC being treated as SLC and "Storage" mode is where it's once again treated as MLC. It's a known technique mentioned in research (by storage vendors) to make "cheap" unified product lines by using the same MLC chips in ALL their drives, rather than having two supplies for SLC vs MLC per line. Fast performance by not worrying about the extra bit per cell, but as soon as they have to worry about it, things slow down.
HD Tune Pro doesn't use partitions/formatting at all, but raw writes to the drive, so hiding behind a "It's NTFS, and thus MS fault" does not work in this case.
Hm. My understanding is that SLC NAND is more expensive, more reliable, and faster, yet is not capable of providing the level of storage MLC can. Does this mean that the transition from 'SLC' mode to MLC mode would be caused by 'SLC' mode running out of capacity? OCZ has stated that the performance-to-storage threshold is different between the 128GB model and 256GB model, which seems a bit conflicting with this theory; there's also the fact that the 512GB model has no performance-mode switch at all.
OCZ has also stated that this performance dip only occurs when switching between performance and storage, and that the average user wouldn't notice it at all, as the speeds would go back up once it's fully transitioned into storage mode (although it won't be as fast as performance).
The reason that was brought up is exactly that - no user sits there writing in RAW mode. They're saying that it's designed to take advantage of the file system, not that the slows are caused by it.
The 128GB drive likely doesn't saturate all I/O channels available to the controller (due to 1 64Gb die per channel likely, or even 2 dies per channel with only half the channels used). The 256GB+ sized drives may not have this dual-mode firmware enabled since they achieve 450+MB/s performance simply due to physical hardware. The performance/storage modes would be a trick used to achieve 256GB+ drive performance, but at 128GB-drive sizes. Also, treating MLC as SLC effectively halves the available space (1 bit per cell instead of 2 bits), thus at 50%, you hit that "out of space in performance mode" threshold, thus forcing the controller into "storage" mode (packing 2 bits per cell, thus having the read-alter-write cycle problems again).
As for NTFS, no user normally writes in RAW mode, but doing so can simulate dumping a large AVI or somesuch to the drive. Likely they were hoping disk write caching of Windows would save them from micro-writes.
This is why I brought up the 256GB model - I haven't seen any specific numbers for it, but it was made apparent that it employs a similar data/drive fill manager as the 128GB:
While treating MLC as SLC in the 128GB model makes perfect sense, I don't quite see how it'd work out with the 256GB model if it doesn't swap modes at 50%.
This is really interesting me; I know OCZ is being real protective of their technology behind the Vertex 4, but I would really like to know how this is working.