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.
I see what you're saying:
That's from the post chain he linked. Basically the "conversion" between performance to storage mode takes longer than the IOMeter, etc tests, so they don't see the performance go back up. Makes me wonder what the "conversion" is though. Still thinking SLC to MLC mode. Only thing besides compression I can think of to speed up IOPS on smaller drives and have a coincidental 50% tipping point.
**********************************************
I think I understand now why the vertex 4 128gig on firmware 1.4 performs the way it does.
The way OCZ have programmed the Vertex 4 128gig firmware is quite ingenious actually.
For MLC NAND, as discussed in this paper (http://cseweb.ucsd.edu/users/swanson...11PowerCut.pdf), pages are actually programmed twice to store 2 bits per cell. The first time a page is programmed from erased is very fast, as it is going from a known state to a roughly central voltage (or staying unprogrammed). The second time a page is programmed is quite slow, because there is existing data that needs to be conserved, while the programmed state is adjusted by 1/4.
So what the 128gig vertex 4 is doing while more then half the drive is free, is programming only the first layer of each page. This is the performance mode and performs more like SLC NAND rather then a normal MLC drive would, resulting in amazingly high write speeds on the 128gig drive (350meg per second or more). However, once you reach 50% full, the drive no longer can perform any first layer writes, and now must write the much slower second layer, which seems to take up to 4 times as long to do. This is the switch to storage mode is.
During storage mode while the drive is more then half full, the drive will maintain 2 bits per cell, but when garbage collection is performed, it will attempt to free up NAND blocks so future writes can be performed only on the first layer, resulting in pretty good performance for burst writes.
Other drives, along with the Vertex 4 128gig under firmware 1.3, must distribute first and second layer writes evenly, resulting in a more consistent, but quite a lot slower, performance over the full surface of the drive.
The reason why the vertex 4 256, 512g don't really show this behavior is that it isn't needed for high performance ... the controller can interleave enough operations that, at least for the 512gig drive, it can distribute writes to the first and second layer evenly without a performance impact.
Edit: however, this is just a guess from someone who doesn't have any inside knowledge, so I could be completely wrong.
************************************************
I don't know about you guys, but to me this looked mighty ingenious on OCZ's part.
Todd Sauve
- The write speed improvement on Vertex 4 should be possible on Samsung and other SSDs (if Samsung wasn't doing the trick already).
- The speed improvement comes to a price: using half the free capacity or suffering a GC process to consolidate from SLC to MLC once half the free size is filled. 90% of the time on 90% of scenarios, this shouldn't be an issue.