Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

share|improve this question
    
What results you expected? What does the spec say? Does it say up to ...? –  Robert Niestroj Jun 7 '12 at 23:24
    
Updated to show expected results. –  Willem Jun 7 '12 at 23:29
    
Were all of the other results based on the same benchmark? Block size and sequential vs. random will make a difference. –  rob Jun 7 '12 at 23:34
    
Yes, they were done using the same application test. –  Willem Jun 7 '12 at 23:44
1  
+1 pretty pictures –  Bigbio2002 Jun 13 '12 at 16:48

2 Answers 2

up vote 10 down vote accepted

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.

share|improve this answer
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 Jun 8 '12 at 10:20
    
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): 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 Jun 8 '12 at 12:04
    
Also, does this mean that for recording captured video, a SandForce controller based SSD is poor choice? –  Willem Jun 8 '12 at 12:07
    
Added another benchmark. –  Willem Jun 8 '12 at 12:24
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 Jun 8 '12 at 22:09

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.

share|improve this answer
    
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 Jun 7 '12 at 23:34
3  
Even 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 Jun 7 '12 at 23:39
    
Downloaded Trim Enabler and used it to enable TRIM (after freeing up 80GB) rebooted and I'm getting the same results still. :O –  Willem Jun 7 '12 at 23:44
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 Jun 8 '12 at 0:16
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 Jun 8 '12 at 0:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.