AnandTech Storage Bench 2011

I didn't expect to have to debut this so soon, but I've been working on updated benchmarks for 2011. Last year we introduced our AnandTech Storage Bench, a suite of benchmarks that took traces of real OS/application usage and played them back in a repeatable manner. I assembled the traces myself out of frustration with the majority of what we have today in terms of SSD benchmarks.

Although the AnandTech Storage Bench tests did a good job of characterizing SSD performance, they weren't stressful enough. All of the tests performed less than 10GB of reads/writes and typically involved only 4GB of writes specifically. That's not even enough exceed the spare area on most SSDs. Most canned SSD benchmarks don't even come close to writing a single gigabyte of data, but that doesn't mean that simply writing 4GB is acceptable.

Originally I kept the benchmarks short enough that they wouldn't be a burden to run (~30 minutes) but long enough that they were representative of what a power user might do with their system.

Not too long ago I tweeted that I had created what I referred to as the Mother of All SSD Benchmarks (MOASB). Rather than only writing 4GB of data to the drive, this benchmark writes 106.32GB. It's the load you'd put on a drive after nearly two weeks of constant usage. And it takes a *long* time to run.

I'll be sharing the full details of the benchmark in some upcoming SSD articles but here are some details:

1) The MOASB, officially called AnandTech Storage Bench 2011 - Heavy Workload, mainly focuses on the times when your I/O activity is the highest. There is a lot of downloading and application installing that happens during the course of this test. My thinking was that it's during application installs, file copies, downloading and multitasking with all of this that you can really notice performance differences between drives.

2) I tried to cover as many bases as possible with the software I incorporated into this test. There's a lot of photo editing in Photoshop, HTML editing in Dreamweaver, web browsing, game playing/level loading (Starcraft II & WoW are both a part of the test) as well as general use stuff (application installing, virus scanning). I included a large amount of email downloading, document creation and editing as well. To top it all off I even use Visual Studio 2008 to build Chromium during the test.

Update: As promised, some more details about our Heavy Workload for 2011.

The test has 2,168,893 read operations and 1,783,447 write operations. The IO breakdown is as follows:

AnandTech Storage Bench 2011 - Heavy Workload IO Breakdown
IO Size % of Total
4KB 28%
16KB 10%
32KB 10%
64KB 4%

Only 42% of all operations are sequential, the rest range from pseudo to fully random (with most falling in the pseudo-random category). Average queue depth is 4.625 IOs, with 59% of operations taking place in an IO queue of 1.

Many of you have asked for a better way to really characterize performance. Simply looking at IOPS doesn't really say much. As a result I'm going to be presenting Storage Bench 2011 data in a slightly different way. We'll have performance represented as Average MB/s, with higher numbers being better. At the same time I'll be reporting how long the SSD was busy while running this test. These disk busy graphs will show you exactly how much time was shaved off by using a faster drive vs. a slower one during the course of this test. Finally, I will also break out performance into reads, writes and combined. The reason I do this is to help balance out the fact that this test is unusually write intensive, which can often hide the benefits of a drive with good read performance.

There's also a new light workload for 2011. This is a far more reasonable, typical every day use case benchmark. Lots of web browsing, photo editing (but with a greater focus on photo consumption), video playback as well as some application installs and gaming. This test isn't nearly as write intensive as the MOASB but it's still multiple times more write intensive than what we were running last year.

As always I don't believe that these two benchmarks alone are enough to characterize the performance of a drive, but hopefully along with the rest of our tests they will help provide a better idea.

The testbed for Storage Bench 2011 has changed as well. We're now using a Sandy Bridge platform with full 6Gbps support for these tests. All of the older tests are still run on our X58 platform.

AnandTech Storage Bench 2011 - Heavy Workload

We'll start out by looking at average data rate throughout our new heavy workload test:

AnandTech Storage Bench 2011 - Heavy Workload

In our heavy test for 2011 the 120GB Vertex 3 is noticeably slower than the 240GB sample we tested a couple of months ago. Fewer available die are the primary explanation. We're still waiting on samples of the 120GB Intel SSD 320 and the Crucial m4 but it's looking like this round will be more competitive than we originally thought.

The breakdown of reads vs. writes tells us more of what's going on:

AnandTech Storage Bench 2011 - Heavy Workload

Surprisingly enough it's not read speed that holds the 120GB Vertex 3 back, it's ultimately the lower (incompressible) write speed:

AnandTech Storage Bench 2011 - Heavy Workload

The next three charts just represent the same data, but in a different manner. Instead of looking at average data rate, we're looking at how long the disk was busy for during this entire test. Note that disk busy time excludes any and all idles, this is just how long the SSD was busy doing something:

AnandTech Storage Bench 2011 - Heavy Workload

AnandTech Storage Bench 2011 - Heavy Workload

AnandTech Storage Bench 2011 - Heavy Workload

Random & Sequential Performance AnandTech Storage Bench 2011 - Light Workload
POST A COMMENT

154 Comments

View All Comments

  • miscellaneous - Thursday, April 07, 2011 - link

    Given this particularly insidious paragraph:
    "OCZ will also continue to sell the regular Vertex 2. This will be the same sort of grab-bag drive that you get today. There's no guarantee of the NAND inside the drive, just that OCZ will always optimize for cost in this line."

    Will these "grab-bag" drives be using the same SKU(s)/branding as the original - well reviewed - Vertex 2? If so, how is using the _old_ SKU(s) to identify the _new_ "grab-bag" drives, whilst introducing _new_ SKU(s) to help identify drives with the _old_ level of performance a satisfactory solution?
    Reply
  • erple2 - Friday, April 08, 2011 - link

    I believe that the issue is scale. It would not be possible financially for OCZ to issue a massive recall to change the packaging on all existing drives in the marketplace. Particularly given that while the drives have different performance characteristics (I'd like to see what the real world differences are, not just some contrived benchmark), it's not like one drive fails while another works.

    So it sounds to me like they're doing more or less what's right, particularly given the financial difficulty of a widespread recall.
    Reply
  • Dorin Nicolaescu-Musteață - Thursday, April 07, 2011 - link

    IOmeter results for the three NAND types are the same for both compressible and uncompressible data in ”The NAND Matrix”. Yet, the text suggests the opposite. Reply
  • gentlearc - Thursday, April 07, 2011 - link

    The Vertex 3 is slower
    It doesn't last as long
    Performance can vary

    Why would you write an entire article justifying a manufacturers decisions without speaking about how this benefits the consumer?

    The real issue is price and you make no mention of it. If I'm going to buy a car that doesn't go as fast, has a lower safety rating, and the engine can be any of 4 different brands, the thing better be cheaper than what's currently on the market. If the 25nm process allows SSDs to break a price barrier, then that should be the focal point of the article. What is your focal point?

    "Why not just keep using 34nm IMFT NAND? Ultimately that product won't be available. It's like asking for 90nm CPUs today, the whole point to Moore's Law is to transition to smaller manufacturing processes as quickly as possible."

    Pardon? This is not a transistor count issue, it's further down the road. I am surprised you would quote Moore's Law as a reason why we should expect worse from the new generation of SSDs. The inability for a company to address the complications of a die shrink are not the fault of Moore's Law, it's the fault of the company. As you mentioned in your final words, the 250GB will probably be able to take better advantage of the die shrink. Please don't justify manufacturers trying to continue using a one-size-fits-all approach without showing how we, the consumer (your readership), are benefited.
    Reply
  • erple2 - Friday, April 08, 2011 - link

    I think that you've missed the point entirely. The reason why you can't get 34nm IMFT NAND going forwards, is that Intel is ramping that production down in favor of the smaller manufacturing process. They may already have stopped manufacturing those products in bulk. Therefore, the existing 34nm NAND is "dying off". They won't be available in the future.

    The point about Moore's Law - I think Anand may be stretching the meaning of Moore's Law, but ultimately the reason why we get faster, smaller chips is because of cost. It's unclear to me what the justification behind Moore's law is, but ultimately, that's not important to the actual Law itself. It is simply a reflection of the reality of the industry.

    I believe transistor count IS the issue. The more transistors Intel (or whomever) can pack in to a memory module for the same cost to them (thereby increasing capacity), the more likely they are to do that. It is a business, after all. Higher density can be sold to the consumer at a higher price (more GB's = more $'s). Intel (the manufacturer of the memory) doesn't care whether the performance of the chips is lower to some end user. As you say, it's up to the controller manufacturer to figure out how to take into account the "issues" involved in higher density, smaller transistor based memory. If you read the article again, Anand isn't justifying anything - he's simply explaining the reasons behind why RIGHT NOW, 25nm chips are slower on existing SF drives than 34nm chips are.

    It's more an issue of the manufacturers trying to reuse "old" technology for the current product line, until the SF controller optimizations catch up to the smaller NAND.
    Reply
  • gentlearc - Saturday, April 09, 2011 - link

    Once again, why do an article explaining a new product that is inferior to the previous generation with no reason why we should be interested? AMD's Radeon HD 6790 was titled "Coming Up Short At $150" because regardless of the new technology, it offers too little for too much. Where is the same conclusion?

    Yes, this article was an explanation. Anand does a 14-page explanation, saving a recommendation for the future.

    "The performance impact the 120GB sees when working with incompressible data just puts it below what I would consider the next-generation performance threshold."

    The questions remains. Why should the120GB Vertex 3 debut $90 more than it's better performing older brother?
    Reply
  • mpx999 - Sunday, April 10, 2011 - link

    If you have a problem with speed of flash memory then a good choice for you are drives with SLC memory, which doesn't have as much speed limitations. Unfortunately manufacturers severy overprice them, as SLC drives are much more than 2 times more expansive than MLC ones at the same amount GB, despite the fact that the flash is only 2 times more expansive. You can buy reasonably priced (2x MLC version price) SDHC cards with SLC flash, but you can't get reasonably priced (2 x MLC version price) SSD with SLC flash. Reply
  • taltamir - Thursday, April 07, 2011 - link

    "After a dose of public retribution OCZ agreed to allow end users to swap 25nm Vertex 2s for 34nm drives"

    Actually OCZ lets customers swap their 25nm 64Gbit drives for 25nm 32Gbit drives. There are no swaps to the 32nm 32Gbit drives
    Reply
  • garloff - Thursday, April 07, 2011 - link

    Anand -- thanks for your excellent coverage on SSDs -- it's the best that I know of. And I certainly appreciate your work with the vendors, pushing them for higher standards -- something from which everybody benefits.

    One suggestion to write power consumption:
    I can see drives that write faster consume more power -- that's no surprise, as they write to more chips (or the SF controller has to compress more data ...) and it's fair. They are done sooner, going back to idle.
    Why don't you actually publish a Ws/GB number, i.e. write a few Gigs and then measure the energy consumed to do that? That would be very meaningful AFAICT.

    (As a second step, could could also do a mix, by having a bench run for 60s, writing a fixed amount of data and then comparing energy consumption -- faster drives will be longer in idle than slower ones ... that would also be meaningful, but that's maybe a second step. Or you measure the energy consumed in your AS bench, assuming that it transfers a fixed amount of data as opposed to running for a fixed amount of time ...)
    Reply
  • Nihil688 - Thursday, April 07, 2011 - link

    Hello all,
    I am kinda new to all this and since I am about to get a new 6GB/s Sata3 system I need to ask this

    The main two SSDs that I am considering are the Micron's C400 or the OCZ Vertex3 120' version.
    I can see that their sequential speeds in both write and read are completely different with V3 winning
    but their Random IOPSs (always comparing the 120GB V3 and the 128GB C400) differ with C400 winning in reads and V3 winning with big difference in writes.
    I must say I am planning to install my windows 7 OS in this new SSD I am getting and what I would
    consider doing is the following:
    -Compiling
    -Installing 1 game at a time, playing, erasing, redo
    -Maybe Adobe work: Photoshop etc

    So I have other hard drives to store stuff but the SSD would make my work and gaming quite faster.
    The question is, C400 gives 40K of read which is more important for an OS whilst V3 gives better overall stats and is only lacking in random reads. What would be more important for me? Thanks!
    Reply

Log in

Don't have an account? Sign up now