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). I perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.

Desktop Iometer - 4KB Random Read (4K Aligned)

The Ultra Plus gets off to a good start, doing very well in our low queue depth random read test, bested only by Samsung's SSD 840 Pro out of our list of contenders here.

Desktop Iometer - 4KB Random Write (4K Aligned) - 8GB LBA Space

Random write performance is pretty good but the Ultra Plus doesn't hit any of the insanely high speeds set by most of the modern drives. Note that its performance is equal to the Samsung SSD 830, which was a favorite of ours. Not having a first class showing here isn't a huge problem.

Many of you have asked for random write performance at higher queue depths. What I have below is our 4KB random write test performed at a queue depth of 32 instead of 3. While the vast majority of desktop usage models experience queue depths of 0 - 5, higher depths are possible in heavy I/O (and multi-user) workloads:

Desktop Iometer - 4KB Random Write (8GB LBA Space QD=32)

We don't see much scaling with higher queue depths, likely a limit of the Marvell SS889175's 4-channel implementation here.

Steady State 4KB Random Write Performance

SanDisk has a completely separate division that handles enterprise drives, but I was curious to see what steady state 4KB random write performance using a 100% LBA span would look like. To find out I borrowed from our Enterprise Storage tests and compared to the results from our OCZ Vector review. Note that many of these drives are enterprise focused and as a result do much better so don't get too turned off by the comparison:

Enterprise Iometer - 4KB Random Write

The Ultra Plus fares much better than I expected, nipping at the heels of the Vertex 4. The Vertex 4 used similar Marvell silicon so I'm not too surprised here.

Sequential Read/Write Speed

To measure sequential performance I ran 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 (4K Aligned)

Like most drive vendors looking to address the light use client market, SanDisk's sequential read performance is actually really good.

Desktop Iometer - 128KB Sequential Write (4K Aligned)

Low queue depth sequential write speed is also quite competitive, both of these will help deliver a pretty decent client experience.

AS-SSD Incompressible Sequential 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.

Incompressible Sequential Read Performance - AS-SSD

Incompressible Sequential Write Performance - AS-SSD

Higher queue depth sequential IO is still very good on the Ultra Plus. There's no penalty to using incompressible data as the controller does no real time data compression/de-duplication.

 

Introduction Performance vs. Transfer Size
POST A COMMENT

37 Comments

View All Comments

  • Kristian Vättö - Monday, January 07, 2013 - link

    Performance vs Transfer Size and TRIM graphs are missing, I know. Already pinged Anand about those so expect to see them soon (the graphs weren't in our admin engine so I couldn't add them, Anand needs to upload them). Reply
  • vol7ron - Monday, January 07, 2013 - link

    The impact of spare area graphs are interesting. OWC has claimed that the spare area doesn't have much of an influence on drives using SF controller, thus defending their non-TRIM support.

    Perhaps Anand could include an OWC drive in there for comparison.
    Reply
  • dave_the_nerd - Monday, January 07, 2013 - link

    OWC has to run down TRIM because they sell third-party SSDs to Mac OS X users. Apple forces OS X to disable TRIM on SSDs they don't supply, because they're jerks sometimes.

    Apple ships its own machines with TRIM enabled, just like everybody else,

    There are hacks. But nobody, OWC or otherwise, is going to say, "oh, yeah, our product supports TRIM, but you need to download this sketchy looking program from this guys blog to make it work. Good luck."
    Reply
  • Darnell021 - Monday, January 07, 2013 - link

    haha yess I just went through that process myself and it's worth adding that every incremental OSX update resets that sketchy little program hack to turn TRIM back off.

    Still worth it though if you know what you're doing ;)
    Reply
  • Samus - Monday, January 07, 2013 - link

    "but you need to download this sketchy looking program from this guys blog to make it work."

    word. true dat, had to do this when I put an Intel X25-M 160GB in my wife's Macbook a few years ago. after about a year it started running crazy slow and fortunately that was just around the time the 3rd party TRIM tool surfaced. works like a charm, but definitely a sketchy solution.

    no more sketchy than jail-breaking an iPhone though. pretty much the only reason I jailbroke my iPod Touch was to disable wifi while its sleeping, because, for some reason, Apple DOESN'T allow that.
    Reply
  • NCM - Monday, January 07, 2013 - link

    I don't see anything "sketchy" about it. A quick trip to the Unix command line enables/disables TRIM in OSX. All the TRIM Enabler utility does is to offer a convenient GUI for that process. It can hardly be said to rise to the level of a hack. The System Profiler correctly shows whether TRIM is enabled or not for either an original or aftermarket SSD.

    It's always dangerous to impute motives to others, and especially so in the case of the typically secretive Apple. Nonetheless I'd guess that Apple, whose customer support is consistently rated well above that of other PC manufacturers, isn't going to endorse something it hasn't tested, and isn't going to test something it doesn't sell. Therefore OSX neither enables TRIM automatically for third party SSDs, nor prevents users from doing so themselves. Sound pretty neutral to me.
    Reply
  • PJCarmody - Tuesday, January 08, 2013 - link

    NCM,

    To your point "isn't going to endorse something it hasn't tested" - Apple is not being asked to endorse the third party options. Not for a moment. So your point is invalid.

    I like your open mind but let's face facts: Apple has a history of crippling third party competitors e.g. for storage.
    Reply
  • gw019 - Monday, September 16, 2013 - link

    "But nobody, OWC or otherwise, is going to say, "oh, yeah, our product supports TRIM, but you need to download this sketchy looking program from this guys blog to make it work. Good luck."

    Well, I am surprised but in fact Plextor did say something similar: http://www.plextoramericas.com/index.php/faq/22-ma...
    Reply
  • Kristian Vättö - Monday, January 07, 2013 - link

    Yeah, that's true. SandForce drives perform well when it comes to consistency and there is no big benefit from more OP (I've tested this with 240GB Intel SSD 335). Reply
  • Samus - Monday, January 07, 2013 - link

    I'm just dying for a mainstream Intel S3700 to hit the consumer corner... Reply

Log in

Don't have an account? Sign up now