MLC vs SLC SSDs: What are the differences?

[Baasha]

I have two SLC SSDs in RAID-0 for my OS drive.

They are great but I've noticed performance deterioration over the past year.

The MLC drives are CHEAP compared to the SLC and I was told that the performance of the SLC drives are MUCH better than that of the MLC.

What are the main differences and the pros and cons of the MLC vs SLC SSDs?

I am waiting for the next-gen Intel SSDs before getting a new set but I want to get the 'best' (fastest read & write) SSDs out there that are 2.5" and not the PCI-E drives.

 

[sub.mesa]

SSD performance depends 90% on the controller and only 10% on the actual NAND memory, more or less. The same controller with SLC will be faster than the same controller with MLC.

But SLC is only really needed if you need high write endurance. Basically; buy MLC since SLC is getting more rare, due to MLC SSDs being so good and about twice as affordable per GB.

 

[Mark R]

Older MLC memory has slow writes, and can be a bottleneck when used on an SSD. e.g. On the Intel G2 SSDs, and other SSDs of the same generation. E.g. you many 'only' get 10,000 IOPS or 150 MB/s sustained write speed. To some extent, random access speed and sustained write speed can be traded off against each other.

MLC also has a relatively limited number of write cycles - estimated by manufacturers at approx 10,000 write cycles. So, taking into account some inefficiency in the write algorithms - you might be taking a bit of a risk, by putting an 80 GB MLC drive if you need it to do 500 GB of writes per day for 5 years.

SLC gets around these problems by having super-fast write speed. This allows a relatively primitve controller to get extremely high write performance. Additionally, SLC has much higher wear tolerance. An 80 GB SLC drive, should be good for several TB of updates per day for 5 years. Finally, SLC has slightly better data integrity than MLC - this is pretty marginal, and ECC reduces the relevance of this - but theoretically, SLC drives should be less likely to corrupt data.

A lot of this is in the past, however. The very latest SSD controllers are significantly more advanced - and the latest flash has got massively boosted speeds. As a result, a new generation MLC SSD with advanced controller should outperform any old-generation SLC SSD.

Further, state-of-the-art ECC and data-protection algorithms on the latest controllers should ensure that data-integrity even on an MLC drive, far exceeds the data integrity of an old generation SLC drive. (Although, it is dependent on the drive manufacturer using this facility. E.g. Sandforce have this advanced data integrity as an option - but most new models of drive have the feature deactivated at the factory, because the drive has more usable drive space with it disabled)

The only thing that isn't addressed is the lifetime of the flash memory - but, even that can be partially mitigated by advanced controllers. That said, the life time isn't really a big issue - 500 GB a day is a heck of a lot of use - and that's for an 80 GB drive. A 600 GB drive, should be able to take many TB of writes per day.

It's likely that any 3rd generation SSD - with a big-brand controller (e.g. Sandforce or Intel) should soundly outperform any 2nd gen SSD (SLC or not).

 

[sub.mesa]

Good post Mark R!

I would add that write endurance doesn't only depend on number of write cycles per cell, but also the total number of NAND pages and erase blocks is important, and the 'write amplification' that amplifies writes from the OS.

I like to look at write endurance as:

Host writes * Write Amplification = Physical Writes
Write cycles per cell * number of cells * wear leveling factor = total write endurance

Example calculation:
34k writes per cell * 60M cells (arranged in pages and erase blocks) * 0.98 wear leveling factor = ~2.0TB write endurance

So you could say:
40GB SSD - 1.0TB endurance
80GB SSD - 2.0TB endurance
160GB SSD - 4.0TB endurance

However, this story doesn't always come true, because higher capacity SSDs may use different memory instead.

It's also interesting to note that Intel's X25-E SSD family, which used SLC memory up until now, will get a special flavor of MLC called eMLC or Enterprise-MLC; which is MLC with more write cycles per cell. These products would be cheaper in the long end, since MLC disks might wear out in 12 months of extremely heavy write duty, while the eMLC or SLC products can live much longer making the total costs of ownership lower than the normal MLC products.

So i think MLC is for most users, and SLC/eMLC is useful for special environments with a high number of write cycles. The performance differences between SLC and MLC disappear with an advanced controller design. But controllers are not that good yet; only the native PCIe FusionIO looks promising but it's bathed in proprietary glue so companies like Sandforce might be more promising as they ship to third party vendors creating competition.

 

[mcm]

Why not recondition your existing SSD to return performance back to what it was like when they were new:
http://macperformanceguide.com/Storage-SSD-Reconditioning.html

The issue of degrading performance is due to flash chips needing to have memory blocks erased before new data can be written. So technologies like TRIM help by erasing the memory block during delete instead of when new data is written (requires both SSD and OS support), and software programs like FlashFire (http://flashfire.org/xe/) help reduce the effects.

To add to the SLC vs MLC discussion this article adds a few more interesting points to what has already been said:
http://www.storagesearch.com/ssd-slc-mlc-notes.html

 

[Emulex]

emlc is a hybrid - store the dirty work on slc and the rest is regular mlc.

 

[Mark R]

emlc is a hybrid - store the dirty work on slc and the rest is regular mlc.

I don't think so.

eMLC, from most manufacturers, is the same MLC for consumer use - but with higher quality control and tighter binning, and different operating specifications (slower programming, and more frequent 'refreshes' to prevent 'fade' in static data blocks).