Random Read/Write Speed

The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.

Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). We perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time.

Desktop Iometer - 4KB Random Read

Desktop Iometer - 4KB Random Write

Desktop Iometer - 4KB Random Write (QD=32)

Random performance is decent but not overwhelming. I am surprised that the Ultra II is not faster considering the SLC cache that nCache 2.0 provides. Random write performance especially is a bit slow by today's standards and does not scale with queue depth, but for light client usage the Ultra II should still be fine.

Sequential Read/Write Speed

To measure sequential performance we run a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.

Desktop Iometer - 128KB Sequential Read

Fortunately sequential read performance is much better, although sequential write performance gets handicapped due to TLC, similar to the 840 EVO.

Desktop Iometer - 128KB Sequential Write

AS-SSD Incompressible Sequential Read/Write Performance

The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers, but most other controllers are unaffected.

Incompressible Sequential Read Performance

Incompressible Sequential Write Performance

AnandTech Storage Bench 2011 Performance vs. Transfer Size
Comments Locked

54 Comments

View All Comments

  • hojnikb - Wednesday, September 17, 2014 - link

    Name one, that competes with mx100 price wise.
  • milli - Monday, September 22, 2014 - link

    http://techreport.com/r.x/adata-sp610/db2-100-read...
    http://techreport.com/r.x/adata-sp610/db2-100-writ...

    One more confirmation to why the 256GB MX100 felt so sluggish to me during preparation/installation.
  • SSD Fan - Friday, September 26, 2014 - link

    I read this http://techreport.com/review/26905/ocz-arc-100-sol...
    TR compares MX100 with OCZ ARC and comments that ARC is better at the same (or close) price....
  • TelstarTOS - Wednesday, September 17, 2014 - link

    MX100 all the time. I do not trust TLC reliability, although Sandisk did a good job on this unit.
  • Notmyusualid - Wednesday, September 17, 2014 - link

    I concurr.

    I have 2x250GB 840 Evo's, and I think they are garbage. Had to beark the RAID0, as they performed so badly.

    I then gave one away to my brother.

    You won't see me buy TLC nand again in this lifetime.

    And by the way, my X25-E is still going strong, without hiccup, as my Linux drive. And how many years is that?
  • sweeper765 - Thursday, September 18, 2014 - link

    Of course the 840 EVO's perform badly , the old written data bug is kicking in. I wonder how long does it take Samsung to acknowledge the problem and then fix it (if it's fixable at all)
  • Kristian Vättö - Thursday, September 18, 2014 - link

    Stay tuned, I'll have an update to share regarding the bug within a couple of days.
  • hojnikb - Thursday, September 18, 2014 - link

    Can't wait :)
    I really wonder whats really up.
  • theuglyman0war - Thursday, September 18, 2014 - link

    really like to hear more from 840 pro users regarding this bug...
    Is it really inherent in the TLC?
  • hojnikb - Thursday, September 18, 2014 - link

    Nobody seems to have issues with MLC drives. There are lots of reports for 840EVO and a few for 840basic.
    So it must be limited to TLC.

Log in

Don't have an account? Sign up now