Results – M550 and MX100

To get more of an apples to apples comparison, we subjected a few prior generation Micron samples to a similar test sequence:

  • Partition full drive capacity and format NTFS.
  • Perform a truncated round of benchmarks to simulate an OS install.
  • Fill to 30% in 10% increments (with wait periods each 10%).
  • Perform abbreviated random workload on the first 10% to simulate OS file writes over time (registry, log files, etc).
  • Fill to 50% in 10% increments (with waits after each 10%).
  • Perform truncated round of benchmarks to evaluate performance.
  • Evaluate sequential read speed of first 50% (fragmentation check).

We didn't take these to 95% since getting them to 50% showed enough consistency to prove there is negligible change as these are filled. To show this, first lets look at the consistency of write speeds as the drives are being filled. The following will be sequences of each 10% write increment for each sample:

M550 128GB:

M550 256GB:

X100 512GB:

ATTO:

As you can see, there's not really any noticable difference in write speeds as these drives are filled. The same goes for ATTO results. Here's one example, from the MX100:

Empty:

50% full:

The two capacities of the M550 gave the same consistent results.

Fragmented file reads:

Recall that at the 30% mark, we initiated a brief (few minute) random workload within the first 10% of the data written to the drive. Once we reached 50%, we read back all written data sequentially, this gave us some interesting results with this new test method:

M550 128GB:


(minimum: 271 MB/sec)

M550 256GB:


(minimum: 355 MB/sec)

MX100 512GB:


(minimum: 382 MB/sec)

Note the first 10% (20% of the above 50% total copy) in the above three images. There is a clear reduction in read speed from areas that had been randomly written to. This effect is likely due to the way the controller handles its internal data tables, and how those entries interact with reading data back from the flash. Random writes may force an increased number of table entries, as well as that flash being written in a more fragmented fashion. Both of these stack up and result in lower read speeds from those areas which had been fragmented in-place. Real-world causes for this are Windows registry files, pagefile (swapfile), hibernation data files, VMware hard disk files (VMDK), among other things. Reading this data back at a slower rate can impact performance, which is why the effect is important to point out here.

Now to try these workloads on the 840 EVO and M600…

« PreviousNext »