OCZ Vertex 4 Review (256GB, 512GB)
by Anand Lal Shimpi on April 4, 2012 9:00 AM ESTAnandTech Storage Bench 2011 - Light Workload
Our new light workload actually has more write operations than read operations. The split is as follows: 372,630 reads and 459,709 writes. The relatively close read/write ratio does better mimic a typical light workload (although even lighter workloads would be far more read centric).
The I/O breakdown is similar to the heavy workload at small IOs, however you'll notice that there are far fewer large IO transfers:
| AnandTech Storage Bench 2011 - Light Workload IO Breakdown | ||||
| IO Size | % of Total | |||
| 4KB | 27% | |||
| 16KB | 8% | |||
| 32KB | 6% | |||
| 64KB | 5% | |||
Our light workload is far more representative of a mainstream client workload (read heavy) and this is where the Vertex 4's sequential read performance hurts it the most. The Samsung SSD 830 ends up being considerably faster here. Once again, if we look at the breakdown of reads and writes we see why:
Read performance is around half of the best performers, while write speed is around 30% better. The combination results in competitive but not class-leading performance.If OCZ is able to deliver, at a minimum, Octane levels of read performance, the Vertex 4 should find itself much higher in the overall charts.
Facebook
Twitter
RSS
127 Comments
View All Comments
Kristian Vättö - Wednesday, April 4, 2012 - link
240GB Vertex 3 is actually faster than 480GB Vertex 3:http://www.anandtech.com/bench/Product/352?vs=561
http://www.ocztechnology.com/res/manuals/OCZ_Verte...
MarkLuvsCS - Wednesday, April 4, 2012 - link
256gb and 512gb should perform nearly identical because they have the same number of NAND packages - 16. the 512gb version just uses 32gb vs 16gb NAND in the 256gb version. The differences between the 256 and 512 gb drives are negligible.Iketh - Wednesday, April 4, 2012 - link
that concept of yours depends entirely on how each line of SSD is architected... it goes without saying that each manufacturer implements different architectures....your comment is what is misleading
Glock24 - Wednesday, April 4, 2012 - link
"...a single TRIM pass is able to restore performance to new"I've seen statements similar to this on previous reviews, but how do you force a TRIM pass? Do you use a third party application? Is there a console command?
Kristian Vättö - Wednesday, April 4, 2012 - link
Just format the drive using Windows' Disk Management :-)Glock24 - Wednesday, April 4, 2012 - link
Well, I will ask this another way:Is there a way to force the TRIM command that wil nor destroy the data in the drive?
Kristian Vättö - Wednesday, April 4, 2012 - link
If you've had TRIM enabled throughout the life of the drive, then there is no need to TRIM it as the empty space should already be TRIM'ed.One way of forcing it would be to multiply a big file (e.g. an archive or movie file) until the drive runs out of space. Then delete the multiples.
PartEleven - Wednesday, April 4, 2012 - link
I was also curious about this, and hope you can clarify some more. So my understanding is that Windows 7 has TRIM enabled by default if you have an SSD right? So are you saying that if you have TRIM enable throughout the life of the drive, Windows should automagically TRIM the empty space regularly?adamantinepiggy - Wednesday, April 4, 2012 - link
http://ssd.windows98.co.uk/downloads/ssdtool.exeThis tool will initiate a trim manually. Problem is that unless you can monitor the SSD, you won't know it has actually done anything. I know it works with Crucial Drives on Win7 as I can see the SSD's initiate a trim from the monitoring port of the SSD when I use this app. I can only "assume" it works on other SSD's too but since I can't monitor them, I can't know for sure.
Glock24 - Wednesday, April 4, 2012 - link
I'll try that tool.For those using Linux, I've used a tool bundled with hdparm calles wiper.sh:
wiper.sh: Linux SATA SSD TRIM utility, version 3.4, by Mark Lord.
Linux tune-up (TRIM) utility for SATA SSDs
Usage: /usr/sbin/wiper.sh [--max-ranges <num>] [--verbose] [--commit] <mount_point|block_device>
Eg: /usr/sbin/wiper.sh /dev/sda1