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:
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):
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:
This looks a bit odd compared to screenshots from their site:
These is the defined S.M.A.R.T attributes (taken from Intel):
And here are my S.M.A.R.T attributes read using smartctl tool from smartmontools:
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:
Solution 1:
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.
Solution 2:
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.