Mac SSD performance and TRIM in OSX

Comments 26 to 50 of 58

StoneyMahoney 2nd July 2010, 00:29 Quote
Originally Posted by aron311
So what is the answer if I want to put an SSD in my MacBook? :)
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.
ryall 2nd July 2010, 03:02 Quote
Originally Posted by aron311
So what is the answer if I want to put an SSD in my MacBook? :)

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.

fcol 2nd July 2010, 07:03 Quote
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.
crazyceo 2nd July 2010, 08:29 Quote
Originally Posted by ryall
Originally Posted by aron311
So what is the answer if I want to put an SSD in my MacBook? :)

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.


+ 1
aron311 2nd July 2010, 10:28 Quote
Originally Posted by ryall
Originally Posted by aron311
So what is the answer if I want to put an SSD in my MacBook? :)

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 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.
phuzz 2nd July 2010, 11:07 Quote
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?
StoneyMahoney 2nd July 2010, 11:48 Quote
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.
StoneyMahoney 2nd July 2010, 12:39 Quote
@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.
leexgx 2nd July 2010, 17:25 Quote
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
aron311 2nd July 2010, 17:30 Quote
..So a 64GB C300 looks like a good bet?
Gradius 2nd July 2010, 21:26 Quote
Mac sucks big time!
aron311 3rd July 2010, 00:31 Quote
Originally Posted by Gradius
Mac sucks big time!

Seriously if you have nothing helpful to say...
davros 5th July 2010, 01:09 Quote
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.
spinron 5th July 2010, 02:36 Quote
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).
fprefect 5th July 2010, 02:54 Quote
I'm not sure that zeroing the drive in Disk Tools effectively resets the cells like the TRIM command would. I expect you'd get the same results if you wrote 0xFF or random data to every sector and then performed your tests.
Metatron 5th July 2010, 03:18 Quote
Ditto on the post from davros. Flash erase state is all 1's eg a hex dump will show byte values of 'ff'. I think you are testing the clean case with a dirty drive.

Also, his comment about doubting that writing all 1's will work is probably correct. In all likelyhood, the drive will keep a list of the blocks as have being written or not. It will use that table to decide whether to write or erase and write. Otherwise, it would need some logic to examine all the bits before deciding - which would be slow. Your strategy of writing the disk without the TRIM hardware/software will not touch the table so you are pretty much hooped.

If you want to do a proper test, get a suitable TRIM equipped drive and use it on both the Windows and Mac platforms. That would be a valid test. What you have done is not.
idontwannaknow 5th July 2010, 03:40 Quote
Here's what I'd like to see.

Run above tests.
Swap drives.
Repeat tests.
XKR 5th July 2010, 04:19 Quote
Your methodology is as good as you could. However, there are a great many steps between executing code an bits on disk, on a modern computer. Trying to compare two systems from “outside the box” is a bit like trying to compare to race cars, each of which has been optimized for body, chassis, suspension, engine, transmission, gas, tires, and track and driver by different people who did not talk to each other. They various parts, such as the file system and the SSD internal disk controller, could be working in harmony or working at complete cross purposes.

Journaling will significantly affect performance. Are the MAC OS and the Windows 7 systems both journaled? As another commenter says, two disk drives that APPEAR the same may in fact have different firmware revisions that would make a BIG difference on aggressive performance tests. Another huge unknown are the two different benchmarks. As an engineer who used to design benchmarks, how the code is organized and compiled can make a HUGE difference in performance. Are operations pipelined? How many threads are used? The disk may not support command queueing, but the driver might. If the driver doesn’t, the file system might. If the file system doesn’t, the benchmark might.

How about dynamic block re-assignment? This could be done, as with command queuing, at three different levels in the disk interface hierarchy.

What are the native block sizes in the two OS’s?

Running VMware Fusion on the Mac, then installing Windows 7 on the MAC would be an interesting comparison. You would then have the same SSD and same hardware interface. The main difference would be the file systems and the benchmark. You might have to ask vmware at what level they interface to the disk subsystem in the Mac.

phics 5th July 2010, 04:19 Quote
As others have suggested, you can't write data through the SSD controller to properly wipe NAND chips. Rather, you need to 'secure erase' the drive through hardware. Pull the drive and do it from another machine if necessary.

Your 'wiped' drive is probably behaving as if it's completely full, thus nullifying any tests after the fact.

There should be some understanding of how SSD's work here... writing zeros to a 'disk' is not the same as wiping NAND chips in a Solid State Drive to make that space available for writing - which is ultimately what you need to accomplish.
bofthew 5th July 2010, 05:36 Quote
You guy's really compare the performance of an operating System that supports TRIM (Windows/Linux) with an OS that currently doesn't (OSX) on a SSD that _DOESN'T_SUPPORT_ TRIM in the first place ?
Why did you actually publish this article ? How it is surprising that you measured no big differences in performance ?
Do a valid test ! Don't just measure baseless values and publish them for the sake of it.
makomk 5th July 2010, 11:06 Quote
Originally Posted by Sifter3000
It's possible, but we did reformat the Air using an option in the OS X installer that sets all the bytes in the disk to zero - it's effectively the same low level format we do for SSDs when testing them under Win 7.

Wrong: it's not the same thing at all. The program you used for the Windows 7 sends a command to the SSD telling it to erase all its data. As several people have pointed out, writing all zeroes to the disk has the opposite effect: it makes the SSD think the entire disk is in use. You're not going to get much performance degradation after that because the SSD will be close to maximum degradation already.
frojoe 6th July 2010, 00:30 Quote
This was a really interesting article, but it seems like one of those things that raised more questions then it answered. If you have the time to go back and do a more in depth look at this I think it would be a great read. I think using a macbook pro with an off the shelf ssd(with trim) would be best, and you could use bootcamp with win 7 to set the drive to a clean state, then go back to osx to do tests. Doing the tests on the same macbook pro in 7 and osx would be the best way to compare performance degradation between the two as the drive is written to and as the drive fills up. The exact speeds wouldn't be as important as the percentage of performance lost over time. I think the most important thing however is to use windows 7 to clear the drive to ensure the drive knows the space is free.

edit: then again it seems apple may be getting ready to enable trim in osx, so pretty soon we may be asking for a comparison between the windows implementation of trim, and that of osx.

oceanwaves7 6th July 2010, 08:43 Quote
I liked your first article that this one refers to. And this is nice, but the statement, "an OS that doesn't appear to be affected by SSD performance degradation" - I see this as sort of a flaw in this article, and is misleading, but saved by the fact that the last few paragraphs say that it will be looked into further. So I hope you do. But in saying that, your article is already being quoted as gospel in other articles that are proud of the misinformation. In fact, that's how I found this.

But It's the hardware and the speed of that hardware that matter, not the OS. The slow down happens at the SSD cell level, not the OS level. Also file fragmentation doesn't result in noticeable slow downs on SSD because there is no physical head that has to move around anyway. At least not a 47% drop. that drop has far more to do with the SSD and how it handles it's data blocks.

There's no doubt that SSD helps all types of computers, but you did tests on a slow macbook air... And while the good news is that those mac book air users may not need TRIM, however, the reason is because it doesn't have fast enough throughput to realize the peak potential of ab SSD's peak rate!! Especially a newer SSD. I'm sure if I get a 10 year old slow PC and hook it up to that SSD, that it will also have slow performance to begin with. Then after it gets "dirty", it will have the same results because the old machine can't get even close to peak performance anyway. So no wonder..

In the PC you used, an intel i7 920 at 2.8ghz on X58 motherboard with appropriate memory, the SSD was the bottleneck after becoming dirty because the PC could easily keep up with the throughput. In the macbook air, I'm pretty sure the macbook became the bottleneck due to the fact that it's slow, outdated, core2duo tech, with a slower bus and other things.. I know we've been taught that a faster computer doesn't help hard drive transfers because they are slow to begin with, but SSD is changing all that. Throughput can be improved with faster, newer hardware. And every drive I've ever bought has been improved some when put in faster computers at least some, so an SSD even more so.

But to complicate things, the SSD also wasn't a very fast one as you said. So maybe the mac could reach the potential of THAT SSD at 90MB/sec, but it still proved nothing since we don't know what happens on other faster SSD's. Or faster Macs for that matter. I think the right way to test it is to test it on a very fast mac. And because those are expensive, the cheapest way to do that might be to hackintosh. But from other suggestions here, running windows from boot camp is NOT a good idea because it's not truly running the way it would run if you formatted the HD and installed windows 7.

And running windows 7 from vmware isnt' really the same as a normal pc either. The os won't run as fast. I also don't think you can run windows 7 from vmware and get it to TRIM the drive. Simply because then 7 is running from vmware on some simulated ntfs, under perhaps a journaled drive. And that's another problem. What file system you pick can have an effect too. But assuming 7 is running normally as it would on a PC, another problem pops up with whether or not the drive has trim, and if under 7 it will auto trim or not, and then knowing when it is "dirty" or not. But whatever you do, I think the correct way to test it is when you have a FAST SSD running on a FAST, modern motherboard. That way the computer can "out run" the SSD and has plenty of juice to show what it could have done.
oceanwaves7 6th July 2010, 11:44 Quote
Whew, major power failure here. Glad ot have power back.. But I wanted to add that where I say it's not the os that matters, I really meant for the most part, in this case, it's probably about the SSD at cell level. And also slow verses faster hardware will play more into it, but I also know that almost any little thing can make some small differences here or there. And other things I mention are trying to make good guesses as to what happened, but it's not easy to pinpoint anything exactly without having all the gear and time to test. Still I figure there's a logical explanation. It's one of those tests that look like a very easy thing to do, but then it always gets complicated after wards as you said, LOL. Again, your 1st article really drove home the point that shopping for an SSD with trim is a good idea. thanks.
Yonzie 29th July 2010, 01:41 Quote
There's one very, very easy way to test this issue:
Plug in an USB harddrive, install OS X on it, install Windows 7 in Boot Camp on the same drive.
Then test the internal harddrive through both windows and OS X. Make sure you use TRIM on it between OS's.
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.

Discuss in the forums