Results – 840 EVO

Here's the full sequence again, to save you from the need to flip back to page 2:

  • 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).
  • Fill to 80% in 10% increments (with waits).
  • Perform truncated round of benchmarks to evaluate performance.
  • Fill to near capacity (97%) (wait at 90%).
  • Perform truncated round of benchmarks to evaluate performance.

Let's see what filling the an EVO up looks like:

840 EVO 120GB:

840 EVO 250GB:

840 EVO 1TB:

I only included three of each to save you from the monotony. So long as the drive is given a minute or so to recover and purge its cache, an 840 EVO will respond the exact same way to writes as it is filled. Since the static SLC cache is completely emptied at every opportunity, you will always see its rated cache capacity fill at its rated write speed.

Now for ATTO results:

840 EVO 1TB empty:

840 EVO 1TB 50% full:

No issue with consistency here. The 120 and 250's performed similarly, as ATTO's test file easily fits within each drive's SLC cache area.

Fragmented file reads:

We saw a speed recution on files that were in-place fragmented on the previous page. We performed this same test on the 840 EVO to evaluate for the same issue:

840 EVO 120GB:

840 EVO 250GB:

840 EVO 1TB:

As we can see here, the 840 EVO appears nearly impervious to read speed reduction of fragmented files. To be clear, the EVOs saw the exact same random workload, duration, and sequence that the M550's and MX100 saw on the previous page.

Now for the M600…

« PreviousNext »