OCZ Vertex 4 128 GB: Testing Write Performance With Firmware 1.4
Benchmark Results: Iometer
Our Iometer benchmark started with static data occupying 50.4% of the drive. Then, we ran a 64 KB-block sequential write across all of the remaining capacity. Performance was reported at 187.74 MB/s.
Next, we deleted the static data and re-ran the test, resulting in 178.67 MB/s.
Finally, we created a partition that left 50% of the drive for over-provisioning and ran the same test once more. Performance clocked in at 327.17 MB/s. Over-provisioning by 50% appears to alleviate any reduction in write speed.
Summary
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.