Delving Deeper

I had suspicions as to the nature of the problem based on my experience with it in my Mac Pro. The SuperTalent MLC drive in my machine would pause, most noticeably, randomly when I'd want to send an IM. What happens when you send an IM? Your logfile gets updated; a very small, random write to the disk. I turned to Iometer to simulate this behavior.

Iometer is a great tool for simulating disk accesses, you just need to know what sort of behavior you want to simulate. In my case I wanted to write tons of small files to the drive and look at latency, so I told Iometer to write 4KB files to the disk in a completely random pattern (100% random). I left the queue depth at 1 outstanding IO since I wanted to at least somewhat simulate a light desktop workload.

Iometer reports four results of importance: the number of IOs per second, the average MB/s, the average write latency and the maximum write latency. I looked at performance of four drives, the OCZ Core (Jmicron controller MLC), OCZ SLC (Samsung controller), Intel MLC (Intel controller) and the Seagate Momentus 7200.2 (a 7200RPM 2.5" notebook drive).

Though the OCZ core drive is our example, but please remember that this isn't an OCZ specific issue: the performance problems we see with this drive are apparent on all current MLC drives in the market that use a Jmicron controller with Samsung flash.

4KB, 100% random writes, IO queue depth 1 IOs per Second MB/s Average Write Latency Max Write Latency
OCZ Core (JMicron, MLC) 4.06 0.016MB/s 244ms 991ms
OCZ (Samsung, SLC) 109 0.43MB/s 9.17ms 83.2ms
Intel X25-M (Intel, MLC) 11171 43.6MB/s 0.089ms 94.2ms
Seagate Momentus 7200.2 106.9 0.42MB/s 9.4ms 76.5ms

 

Curiouser and curiouser...see a problem? Ignore the absolute ridiculous performance advantage of the Intel drive for a moment and look at the average latency column. The OCZ MLC drive has an average latency of 244 ms, that's over 26x the latency of the OCZ SLC drive and 25.9x the latency of a quick notebook drive. This isn't an MLC problem however, because the Intel MLC drive boasts an average latency of 0.09ms - the OCZ MLC drive has a 2700x higher latency!

Now look at the max latency column, the worst case scenario latency for the OCZ Core is 991ms! That's nearly a full second! This means that it takes an average of a quarter second to write a 4KB file to the drive and worst case scenario, a full second. We complain about the ~100 nanosecond trip a CPU has to take to main memory and here we have a drive that'll take nearly a full second to complete a task - totally unacceptable.

In order to find out if the latency is at all tied to the size of the write I varied the write size from 4KB all the way up to 128KB, but kept the writes 100% random. I'm only reporting latencies here:

100% random writes, IO queue depth 1 4KB 16KB 32KB 64KB 128KB
OCZ Core (JMicron, MLC) 244ms 243ms 241ms 243ms 247ms
OCZ (Samsung, SLC) 9.17ms 14.5ms 21.2ms 28ms 28.5ms
Intel X25-M (Intel, MLC) 0.089ms 0.23ms 0.44ms 0.84ms 1.73ms
Seagate Momentus 7200.2 9.4ms 8.95ms 9.14ms 9.82ms 12.1ms

 

All the way up to 128KB the latency is the same, 0.25s on average and nearly a second worst case for the OCZ Core and other similar MLC drives. If it's not the file size, perhaps it's the random nature of the writes?

For this next test I varied the nature of the writes, I ran the 4KB write test with a 100% sequential workload, 90% sequential (10% random) and 50% sequential (50% random):

4KB writes, IO queue depth 1 100% Sequential/0% Random 90% Sequential/10% Random 50% Sequential/50% Random 0% Sequential/100% Random
OCZ Core (JMicron, MLC) 0.36ms 25.8ms 130ms 244ms
OCZ (Samsung, SLC) 0.16ms 1.97ms 5.19ms 9.17ms
Intel X25-M (Intel, MLC) 0.09ms 0.09ms 0.09ms 0.089ms
Seagate Momentus 7200.2 0.16ms 0.94ms 4.35ms 9.4ms

 

The average latency was higher on the OCZ Core (MLC) than the rest of the drives, but still manageable at 0.36ms when I ran the 100% sequential test, but look at what happened in the 90% sequential test. With just 10% random writes the average latency jumped to 25.8ms, that's 13x the latency of the OCZ SLC drive. Again, this isn't an MLC issue as the Intel drive does just fine. Although I left it out of the table to keep things simpler, the max latency in the 90/10 test was 983ms for the OCZ Core drive once again. The 90/10 test is particularly useful because it closely mimics a desktop write pattern, most writes are sequential in nature but a small percentage (10% or less) are random in nature. What this test shows us is that even 10% of random writes is all it takes to bring the OCZ Core to its knees.

The problem gets worse as you increase the load on the drive. Most desktop systems have less than 1 outstanding IO during normal operation, but under heavy multitasking you can see the IO queue depth hit 4 or 5 IOs for writes. Going much above that and you pretty much have to be in a multi-user environment, either by running your machine as a file server or by actually running a highly trafficked server. I ran the same 100% random, 4KB write test but varied the number of outstanding IOs from 1 all the way up to 64. Honestly, I just wanted to see how bad it would get:

This is just ridiculous. Average write latency climbs up to fifteen seconds, while max latency peaked at over thirty seconds for the JMicron based MLC drives. All this graph tells you is that you shouldn't dare use one of these drives in a server, but even at a queue depth of four the max latency is over two seconds which is completely attainable in a desktop scenario under heavy usage. I've seen this sort of behavior first hand under OS X with the SuperTalent MLC drive, the system will just freeze for anywhere from a fraction of a second to over a full second while a write completes in the background. The write that will set it off will often times be something as simple as writing to my web browser's cache or sending an IM, it's horribly frustrating.

I did look at read performance, and while max latency was a problem (peaking at 250ms) it was a fairly rare case, average latency was more than respectable and comparable to the SLC drives. This seems to be a write issue. Let's see if we can make it manifest itself in some real world tests.

Enter the Poorly Designed MLC The Generic MLC SSD Problem in the Real World
Comments Locked

96 Comments

View All Comments

  • Alleniv - Wednesday, August 19, 2009 - link

    Hi all,
    I report this new review about X25-M, that takes in consideration a comparative with other SSDs and also with HDDs, with several benchmarks ? http://www.informaticaeasy.net/le-mi...m-da-80gb.h...">http://www.informaticaeasy.net/le-mi...m-da-80gb.h...
  • Bytales - Saturday, January 3, 2009 - link

    You said this: For example, let's say you download a 2MB file to your band new, never been used SSD, which gets saved to blocks 10, 11, 12 and 13. You realize you downloaded the wrong file and delete it, then go off to download the right file. Rather than write the new file to blocks 10, 11, 12 and 13, the flash controller will write to blocks 14, 15, 16 and 17. In fact, those four blocks won't get used again until every other block on the drive has been written to once

    By this i understand that a bigger capacity SSD, for instance 320 vs 160 will have more blocks and hence you will need more writes to deplete the number a write cycles the SSD was designed for. So for SSD bigger means even longer lasting. IS this TRUE ?
  • lpaster - Wednesday, November 26, 2008 - link

    Can you overclock this SSD?
  • Sendou - Wednesday, February 9, 2011 - link

    There are optimization methods available for SSD's which can mitigate performance loss through genuine usage over time.

    One such is Diskeeper's HyperFast Technology.

    There is a white paper regarding HyperFast available at:

    http://downloads.diskeeper.com/pdf/Optimizing-Soli...
  • BludBaut - Thursday, March 31, 2011 - link

    I read the pdf article you linked from Diskeeper.

    Based on the information Anand has given in his articles about Intel's technology, Diskeeper's "whitepaper" sounds like crap advertising by a company who's afraid their technology might be considered not only useless but detrimental to use with SSDs. I'm inclined to agree since Diskeeper's own results show a 4x write loss by just *one* "optimization" while Anand's article clearly suggests that the proper design (which he says Intel has accomplished) eliminates the need for Diskeeper's service.

    Until I find more thorough examination of the facts, Diskeeper's remarks make me distrust them.

    On the other hand, Anand's article definitely sounds not just like a puff piece for Intel, but qualifies in my mind as advertising. Wonder how much money Intel has spent on Anandtech? That's not to suggest that anything is misrepresentative (well, it wasn't meant to sound that way, but keep reading and you'll find the one-sided praise will later be partially retracted and I don't know the end of the story yet), but we all know that advertising always leaves out the negatives.

    (Reviews shouldn't sound like advertisements but anyone who's been reading magazine reviews for 30 years knows that's frequently the case. The reviewer's bills get paid by the manufacturers' of the products he's reviewing. But, the reviewer is objective of course. It's a matter of journalistic integrity. Yeah, I believe that. Don't you?)

    One such negative was the promotion of the life of the drive. "20GB a day for five years"? Anand praises Intel for multiplying that by five to "100GB a day for five years" but then tells us that they'll only guarantee the drive for three years and has the audacity to suggest we'll likely have a recourse "if we can prove" ... -- how is anyone going to prove how many GBs a day they put on their computer? The annoyance of trying to keep track is not something 99% of people would do.

    Did you do the math to see how long it takes to write 100GB to a drive with a write speed of 200MB/s? Eight minutes and twenty seconds is all it takes.

    Well, that's great if all you use your computer for is reading articles, checking the news and sales prices and sending email. The drive should last as long as your computer. But if you love video (who loves video???), it's a different story entirely.

    There's another negative that, though first denied, eventually was acknowledged. More than six months later, Anand reports back and says essentially, 'Intel is still the best but the performance does degrade with time and I don't know why.' If he's explained it since then, I've yet to read it.

    So, for those just reading the article, don't get so encouraged that you start drooling. The article has a tendency to make one think, "What am I waiting for? I want one of these puppies!" Unfortunately, Intel's technology isn't as rosy and bulletproof and Anand made it sound.
  • kevonly - Friday, November 21, 2008 - link

    I hope you do some benchmark on Samsung's new 256GB SSD. Hopefully it's as good as Intel's.
  • kevonly - Friday, November 21, 2008 - link

    its read/write speed is 200/160 mb/s. Will it sustain that speed in a multi applications running environment??
  • kevonly - Friday, November 21, 2008 - link

    sorry

    read/write speed is 220/200 mb/s.
  • scotopicvision - Monday, November 10, 2008 - link

    The article was an amazing read, fantastic, and well done thank you.
  • D111 - Saturday, October 25, 2008 - link


    Legacy OS like Windows Vista, XP, and Applications like Microsoft Office 2003, 2007, etc. have built in, inherent flaws with regard to SSDs.

    Specifically, optimizations of these OS for mechanical hard drives like superfetch, prefetch, etc. tend to slow down, rather than help performance and is unnecessary to speed up reads in an SSD, but slow it down with unnecessary writes of small files, which SSDs are slower than a regular hard drive.

    Things like automatic drive defragmentation with Vista does nothing for SSDs except to slow them down.

    Properly optimized, even low cost 2007 generation SSDs test out as equivalent to a 7200 rpm consumer grade drive, and typical SSDs made in 2008 or later tend to outperform mechanical hard drives.

    The tests done here have done nothing to "tweak" the OS to remove design hindrances to SSD performance, and thus, have no validity or technical merit.

    The test, as presented, would be similar to installing a 19th century steam engine on a sailing ship, and observing that it is rather slow ---- without mentioning the drag and performance hits caused by the unused sail rigging, masts, etc.

    See the discussion here for a detailed discussion of SSD performance tweaks and what it takes to make them perform well with legacy OS and Applications.

    http://www.ocztechnologyforum.com/forum/forumdispl...">http://www.ocztechnologyforum.com/forum...display....

Log in

Don't have an account? Sign up now