OCZ Trion 100 480 GB SSD Review

Jump To:

IOMeter Sequential Performance

Starting here in April 2015 Legit Reviews  has brought ack synthetic IOMeter v1.1.0 testing to our high-end Solid-State Drive reviews as we feel that the canned benchmarks no longer show enough of the performance picture nor do they expose many of the heat issues that we are starting to encounter on M.2 PCIe SSDs. We start out testing each drive with IOMeter, but first we prepare the drive. This is done by using Parted Magic to complete a full Secure Erase each and every drive. Next we use IOMeter to prefill the drive by performing the industry standard 128KB, aligned, sequential write workload across the entire drive for a period of 20 minutes. Once the drive is conditioned we run our saved sequential test profile that runs our 128KB test for two minutes without any idle time in between the tests. The queue depth is set to 32 as we feel with NVMe drives starting to come out that we need to increase our IO depth.

iometer-mb

The 128KB Sequential Read/Write test is done primarily to make sure the drives we are testing meet or surpass the manufacturer specifications for sequential Read/Write performance. The Samsung SSD 850 EVO 500GB drive  topped out at 553 MB/s read and 520 MB/s write. The OCZ Trion 100 came in with an impressive 558 MB/s read, but the write speeds were a rather unimpressive 164 MB/s.

iometer-128-iops

For those that like to know the IOPS results you are looking at around 4,200 IOPS for the sequential read on both drives, but the Samsung 850 EVO had 3,964 IOPS on the sequential write while the OCZ Trion 100 had 1,251 IOPS.

iometer-128-ms

Having high IOPs per second is generally considered good, but you also look at the latency when interpreting the results. Just because the IOPs are high it might not mean that the data is being delivered at a reasonable latency and this could cause for a poor user experience. The Samsung 850 EVO was right around 8ms on the average response times and the OCZ Trion 100 was in the ballpark for the reads, but was at over 25ms for the writes.

Jump To: