Hardware Mac SSD performance and TRIM in OSX

Word from a Mac engineer: even swapping an off-the-shelf SSD into any form of Mac won't give you decent results. Because Mac OS X and it's file system treat the actual hardware so differently (as you discovered) Apple supply all their hard drives and SSDs with custom firmware, optimised for the specific differences in cache usage patterns between OS X and Windows, the OS pretty much all hardware is primarily designed and supplied to to perform best on.

I've personally seem some quite startling differences in performance differences between Apple-supplied hard drives and seemingly identical 3rd-party units. I replaced 2 failing drives in an X-Raid, sourcing drives identical to the originals before Apple rebadged (and reflashed) them, placed them in the original Apple caddies and rebuilt the entire raid structure from scratch. Performance writing large contiguous files to the raid dropped around 20%.

 

Nice You can always drop me an email (editor [at] bit-tech.net) if you have any more info to share...

 

So what is the answer if I want to put an SSD in my MacBook?

 

if it's using different firmware, i would be very interested in what happens if you partition the test Macbook Air and install Windows onto the SSD. this should tell if it's running self-TRIM firmware or just plain Samsung.

very interesting read, it appears i have got exact same Samsung drive in my desktop. but don't have TRIM support

 

Didn't one of the Samsungs you tested have a sort of manual TRIM? It could just be doing that...

edit: ah yes, Garbage Collection. So what everyone else said. Ignore me!

 

It would be interesting to see an off the shelf SSD in a MacBook Pro. Drive Genius does some sort of performance testing though I've never looked deeply into it.

I'm not sure about the SSD's specifics, but Apple named/branded drives have custom firmware on them, which may effect abilities or performance. I know in the case of server/raid drives, Apple's engineers have worked with the drive manufacturers to optimize the firmware for the way OS X and HFS+ accesses and caches data.

 

With a standard SSD in place, the OS and the SSD wouldn't quite be as smoothly synced when it comes to data transfers and buffer sizes. The result would be a slight reduction in transfer speed. However, I don't see any way you'd get an increase in seek latency and as that's the main advantage of an SSD anyway, I'd totally do the upgrade if I were you. And I could afford it.

 

Wait for Apple to release a MB that includes a "revolutionary new game-changing" SSD. Then pay the ridiculously huge markup and thankfully kiss Steve's ass for allowing you to purchase it.

Then rabidly defend your purchase/apple/steve to anyone that dares question the mighty Apple.

 

I've had a Corsair P128 installed in my Macbook 3.1 (late 2008) since July 2009. It has pre-TRIM/garbage collection firmware VBM1801Q but from everything I've read, newer firmware with garbage collection and TRIM would not work on Mac anyway.

I've been stunned that my P128 has suffered no significant slowdown based on Quickbench and my own subjective perception. It's been near full (about 20GB free) since Day 1 and I use it daily in ways that should have killed its performance. For example, I have an XP virtual machine (VMware Fusion) where I leave indexing on and use it/suspend it daily (i.e. it writes 1GB page files daily). The VM grows from 15GB to ~25GB every 6-8 wks, at which point I consolidate the snapshots and shrink the VM.

Based on my usage pattern, I was planning to yank the drive out, stuff it in a PC, reformat it, then re-clone my OSX partition every 3-6 months to restore performance. But I have had no reason to do so and have been completely boggled as to why. I'll be interested to read your follow-up investigations. I've been casually searching around over the past year on Mac-SSD experiences but there isn't much out there.

 

+ 1

 

I feel the same way, I had to buy it to be able to support some websites I'd previously made on a Mac only program. I figured rather than buy a Mac Mini, I'd spend a little more and get something that is actually useful. I can take it to customers sites and not really have to worry about getting viruses, it can still run Windows 7 and the battery life is pretty damn good, plus it will last 5 years worth of charging cycles (supposedly). I got it through my universities Higher Educational purchase program so got a nice discount and when I come to sell it I'm not taking much of a hit because of all the fanbois who each this **** up.. I sell laptops every few weeks I've seen what you can get for the same price, the unfortunate truth is that MacBook machines are still worth more a year or two down the line. I HATE Steve Jobs though, tosser.

 

I'm wondering how low level the wipe you did was. If the OS is literally writing 0's (or 1s) to all of the SSD, could the SSD be interpreting this as actual data, rather than a wipe? Then it would be assuming that all of the cells contained data, so it would do a read-modify-write all the time.

I'm just thinking out loud here, this is obviously something that needs more investigation, perhaps trying the SSD on a windows machine, or vice-versa?

 

Apple sell 3 different SSDs as BTO options in Macbook Pro machines - 128, 256 and 512 gig. Taking into account the price of the HDD they replace and prices of off the shelf SSDs from Scan, the 128gig and 512gb SSDs are priced pretty much spot on, but the 256gb model gets you gouged to the tune of around £120. Not cool these days.

 

@phuzz - the zero-fill routine in Disk Utility is designed for secure data deletion, not any form of low-level formatting, so I doubt it would make any difference. Without an SSD myself to verify this, I can only speculate, but an SSD would have to assume this was all data to avoid any possible corruption. Also, low-level formatting is so out of date, actually trying to do it to a hard drive would actually break it. Look it up on Wikipedia, it's fascinating.

However, you do raise a valid point. I assume you can solve this cell fragmentation problem by formatting or repartitioning an SSD somehow, but a cell can only be set to a virgin state by the SSD internally. I can therefore also only assume that part of the abstracted formatting procedure involves letting a drive know it's being formatted, allowing it to perform built-in procedures to reset itself to a clean state, entirely or just for a single partition. An SSD must interpret this as an opportunity to set it's cell state table to recognise that cells are unused, causing any writes to cells to ignore the read-modify-write procedure that causes the slowdown problem.

 

90mb/s read and 70mb Write is an corsair s128 or first gen samsung SSD i have one on my desk now as i used to use it in my system apart from lots of small Writesand reads at the same time was quite fast, got an M225 now i no longer have any issues with Write lag now (going to put that in my dads laptop once i got the data off it and low level formatted it as Ccleaner Free space wipe messed the drives performance up)

the S128 would slow down if i did read and Write same time {steam or unpacking} it would cida stall for it short time if that happened {Steam unlocking an pre release game did it} m225 is just fast

as long as you do not fill an samsung based ssd to full it norm works normaly (fill it to full and it may not work correctly to spec Garbage Collection {GC} also fails to work as well, once the drive has been filled only an low level format can fix that)

anandtech is better at doing SSD related stuff like this be interesting if they would do an apple review

 

..So a 64GB C300 looks like a good bet?

 

Mac sucks big time!

 

Seriously if you have nothing helpful to say...

 

To clear up some misconceptions: You might be doing it wrong. As far as I know, for that matter.

First: The unwritten state of a flash page is all 1s. So if everything is cleared with zeroes, the controller thinks everything is used. Therefore, after the "cleaning" with 0, the drive is effectively used completely.

The same thing happens when a file is overwritten with 0s. The disk has to remember that, as it does not know that this is a file deletion. If such a sector is rewritten, the page/block has to be reset to 1, and then written to.

However, I doubt writing all 1s will work. The driver would have to check whether a write to a block is all 1s, and then mark that block as directly writable. I doubt they do that.

 

I have a 2009 MacBook that was upgraded with an 80GB Intel G2 SSD a few months back. My disk usage pattern involves massive disk re-writes, well over 1TB worth of data per month (most of which are large files). My original plan was to low-level format and restore the drive every month, but since I haven't noticed any palpable degradation in write performance over time I never actually went through the hassle.

The system profiler (in 10.6.4) identifies the drive as having no TRIM support. It's wrong (I verified this on a PC when I got the drive). Either there's something wrong with it, or the hardware doesn't permit the OS to see TRIM support (which is very unlikely given what TRIM is and how it's implemented as an ATA command extension).

I used xbench to test the drive's performance, as I wasn't aware of Quickbench. So far, the degradation from my use is less then 5% compared to when the drive was new.

The only explanation I have for this surprising behavior is that the OS X implementation of HFS+ is just not amenable to the degradation issue of Windows., maybe it does block allocation differently then NTFS. I'm so happy with the way the Intel drive works I am actually thinking about retrofitting my Hackintosh with an SSD (possibly a Corsair Nova).