How come my Intel 520 180GB SSD performs extremely poorly?

I recently installed a new Intel 520 series 180GB SSD in my brand new MacBook Pro.

The system is as follows:

Model: MacBook Pro 15-inch, Late 2011 (MacBookPro8,2)
Processor: 2.4 GHz Intel Core i7
Memory: 16 GB 1333 MHz DDR3
Graphics: AMD Radeon HD 6770M 1024 MB
Software: Mac OS X Lion 10.7.3
Main Drive Bay: Intel 520-series 180GB SATA-3 (6GB/s negotiated link) SSD (Firmware: 400i) [80GB free]
Optical Bay: Toshiba 5400 RPM 750GB SATA-2 HDD
Trim: Enabled (according to Trim Enabler App)

And here are the speeds I'm getting:

enter image description here

Read: 412 MB/s
Write: 186 MB/s

What have I done wrong?

Ok, so I was informed in an answer that this could be because the test uses compressed data which will not allow the Intel 520 series SandForce controller to reach it's high write levels to to its architecture.

Here's another test (don't know if it uses compressed data or not):

enter image description here

It's better, but still not what I'm looking for. By the way, what's up with 32MB/s for 4k read operations?

Results expected:

Read/write both > 500MB/s

I have seen benchmarks with lesser SSD:s (SATA-2 even) outperform my write-speeds by far. Also, Intel 520 SSD:s are supposed to be the top class of SSD:s.

Trim Enabler report:

Trim enabler report

This looks a bit odd compared to screenshots from their site:

Trim enabler sample report

These is the defined S.M.A.R.T attributes (taken from Intel): enter image description here

And here are my S.M.A.R.T attributes read using smartctl tool from smartmontools: enter image description here

They don't seem very compatible. I'm going to try and look for a S.M.A.R.T attributes reader tool for OS X which might support Intel 520 series.

EDIT:

I've solved my problem by buying a MacBook Pro Retina which uses a PCIe2-2x SSD. Benchmarks below:

Benchmark for MacBook Pro Retina SSD

Willem

Posted 2012-06-07T22:45:28.307

Reputation: 544

What results you expected? What does the spec say? Does it say up to ...? – Robert Niestroj – 2012-06-07T23:24:57.103

Updated to show expected results. – Willem – 2012-06-07T23:29:59.563

Were all of the other results based on the same benchmark? Block size and sequential vs. random will make a difference. – rob – 2012-06-07T23:34:12.867

Yes, they were done using the same application test. – Willem – 2012-06-07T23:44:43.477

Windows user here, my Intel 520 180GB SSD works great with Windows 8. Maybe you need a more modern operating system? – ta.speot.is – 2012-06-08T01:16:35.853

@ta.speed.is Mac OS X Lion is very modern. You gave me the idea to try a speed test on my Windows 7 partition though. WHat speeds are you getting with your Intel 520 180GB SSD in Windows 8? – Willem – 2012-06-08T07:56:07.433

Answers

The drive you are testing (Intel 520) is based on a Sandforce controller, these controllers rely heavily on data compression to achieve the stated speeds. As a result you will happily saturate a SATA-III link when doing sequential tests on compressible data, however these speeds can drop by up to an order of magnitude (depending on the exact drive) when running tests with incompressible data.

From what I can gather from the attached screenshot, the test you are using appears to be writing image frames to disk to test its performance - images are not trivially compressible even when in uncompressed/lossless form. From my experience those numbers are in the correct ballpark for a SF-28xx controller doing sequential benchmarks on incompressible data.

The following comparison on AndandTech shows the difference between the Intel 520 (60GB) when doing tests with compressible vs incompressible data. This is a smaller drive capacity than yours meaning the effect will be less pronounced at higher capacities (240GB), but the I feel this illustrates the issue.

Other drives based on non-Sandforce controllers exist, such as the Crucial M4 (Marvell), Samsung 830 (Samsung) or Intel 510 (Marvell), these do not leverage compression and as such don't suffer from the same variation in write speed.

Turix

Posted 2012-06-07T22:45:28.307

Reputation: 691

6+1 This is the problem. The test uses already compressed data, which is a worst case scenario for the Intel 520 or any SandForce drive. For such data a Intel 510 or a Samsung 830 would be a much better choice. – Mr Alpha – 2012-06-08T10:20:31.867

Are you sure the test uses already compressed data? They had a benchmark for a the 240GB drive which has the same specs as my 180GB (60 is substantially less): http://www.anandtech.com/bench/Product/595?vs=529&i=82.272.86.306.307 This also illustrates a difference but it doesn't justify these extremely low write speeds I think? The reads aren't exactly top level either compared to other SSD:s doing the same test. Even SATA-2 disks seem to win this battle. I understood it as the Intel 520 is the Cadillac of consumer SSD:s?

– Willem – 2012-06-08T12:04:26.393

Also, does this mean that for recording captured video, a SandForce controller based SSD is poor choice? – Willem – 2012-06-08T12:07:07.777

Added another benchmark. – Willem – 2012-06-08T12:24:25.243

2@Willem Yes, for any video-related work any sort of SandForce is a bad idea. Not only does SandForce rely on compression to achieve high write performance (especially for smaller capacities), it also relies on the space left over for extra over-provisioning to maintain performance. Something that doesn't care that the data already is compressed would be a much better choice. As always, bigger would also be better. – Mr Alpha – 2012-06-08T22:09:58.217

I assume you are most concerned about the write performance, and that this test represents sequential write performance (520MB/s claimed), not random (which would be in the 250MB/s range). Basically, SSD write performance is significantly impacted by the availability of free, programmable blocks. You are ~90% utilized, so this may explain your issues. Have you enabled TRIM support on the drive? (note: this is not done automatically on OS X unless you are using the officially supported Apple SSDs).

If not, take a look here: http://www.groths.org/?page_id=322

You should also look to see what you can move off there once you enable TRIM and then re-run the benchmarks.

Edit: Thanks to David in the comments for this tip (please upvote his comment too) - you must enable TRIM before you delete the data or it won't work. If you delete the data first, you will need to re-fill the drive and re-delete for TRIM to work as intended.

Adam C

Posted 2012-06-07T22:45:28.307

Reputation: 2 475

I updated the post because I was able to free 80GB of space on the drive and yet I am getting exactly the same write-results. (Have not restarted computer or anything since freeing up space though, if that has any impact) – Willem – 2012-06-07T23:34:45.453

3Even when you free up the space, you need TRIM support to utilize it appropriately - enable TRIM, then reboot and give it another shot. – Adam C – 2012-06-07T23:39:02.467

Downloaded Trim Enabler and used it to enable TRIM (after freeing up 80GB) rebooted and I'm getting the same results still. :O – Willem – 2012-06-07T23:44:03.617

hmmm - since the reads are in range I think you are getting SATA III negotiated you are at the stage where I usually look to check cabling - not the easiest thing on a Macbook though - I would pop it into my desktop for some testing to eliminate cable and controller, see if it behaves itself outside of the laptop. My only other thought would be to try the old PRAM/SMC reset trick as a last resort. – Adam C – 2012-06-08T00:11:26.550

6@Willem: Trim has to be enabled when you delete the files. Deleting the files and then enabling trim later won't work. You can fix it by filling the drive up and then deleting the stuff you filled it with while trim is enabled. – David Schwartz – 2012-06-08T00:16:39.490

@David - I didn't know that - +1 for the tip - I'll add it to the answer, with credit of course, in case people don't read this far into the comments :) – Adam C – 2012-06-08T00:26:55.183

1@DavidSchwartz: I filled up the 80GB and then removed them while TRIM was enabled. When the disk was at <1GB free space my benchmark gave 50MB/s writes (expected). After removing until I had 80GB free again the benchmark returned to the ~170MB/s writes which is no difference from before basically. Maybe a little less even. – Willem – 2012-06-08T00:43:49.457