Slow read/write speeds on Agility 3

Hey guys

I have an OCZ Agility 3 installed in my White Mid 2010 MacBook.

I am only able to run the drive with a SATA II controller, as that's all I have. The write speeds are 130MB/s, and read 195MB/s, and I thought these were a little low for this drive, considering it would usually be SATA III, I thought it would be able to handle SATA II no problem.

Any ideas why?

 

It's handling SATA2 as well as it can considering OS/x doesn't support TRIM.

 

Depends on which version of OS X. OS X Lion (10.7) added TRIM for SSDs.

 

No, afaik, only TRIM for Apple approved/sold SSD's.

 

I'm surprised nobody has put together a 3rd party TRIM driver/kext/whatever for OS X yet. If people can get OS X running on PC hardware, how hard could it be to enable TRIM for aftermarket SSDs?

 

Someone has released Trim Enabler which will work on Lion (well, the new version will) but already works on Snow Leopard.

Someone has also released a command line version you can do in terminal. All it does is modifies the kernal extension to stop Mac OS X looking for the term 'APPLE SSD' when deciding whether or not to enable TRIM. Now it just enables TRIM all the time (this is the method I've used)

It should be noted that it's a brand new SSD, and I've even left it idling for a few hours on a couple of days to allow garbage collection to do it's thing.

Anyone got any other ideas what it could be?

 

How did you come up with your original bench numbers? With different benches on Windows, different test yield different results. Is it possible the numbers are just particularly low for the particular test you ran? Does the Agility 3 do the same as other OCZ drives by compressing data in order to gain performance? If so, did your test use compressed files?

Yes, OS X Lion will enable TRIM for Apple ordered configurations, but also (as pointed out above) TRIM Enabler is available for "non-Apple" SSDs starting w/ OS X 10.6.8.

The quote from your post, "considering OS/x doesn't support TRIM", is incorrect.

 

It is possible, I was using Blackmagic Disk Speed Test. I'm not really sure of any other benchmarking tests for mac, but a lot of people seem to use this.

 

The more incompressible the data is the slower it will be. Also if the media is fragmented it will be slower. If you write a lot to the disk you might get LTT Life Time Throttling where writes are throttled by firmware so as not to wear out the drive before the warranty expires.

Some of the speeds published for Agility are unrealistic as they are based on highly compressible data such as 0-fill which IMO is not the average sort of data you are likely to be using with the drive.

 

When you talk about incompressible data, what do you mean?

Is it correct that Asynchronous NAND suffers more from incompressible data?

 

Dunno if this is true of the Agility 3, but other OCZ drives would compress data on-the-fly while writing to the NAND pages (and decompress data upon read). This was an attribute of some of the SandForce controllers. So, it's not just OCZ drives, but all SSDs which use the SandForce controller that compresses data stored in the NAND pages within the disk.

This produced crazy fast benchmarks where a utility would write a file of nothing but zeros (or ones) to disk, and then read it back measuring throughput - since the physical read of every byte from the NAND cells never took place - just a read of compressed data, and then on-the-fly expansion.

With that said, when it comes to actual disk use, a file can contain data which is not as "compressible" as other data. Compressed data files (7zip, gzip, zip, rar, etc.) as well as other formats like JPEG, MP3 and Quick Time are already compressed, so there is no real benefit of running a compression algorithm on data that is already compressed. In fact, it might even slow things down.

Does that make sense so far?

So, in the case of a benchmark of these SandForce based drives, it all depends on the type of file being used in the bench, and the "compressibility" of the test file.

In regards to Asynchronous vs. Synchronous NAND Flash, the answer is no. That technology determines "when" the data can be read from the NAND pages found on the disk. It has nothing to do about compressing the data stored there.

 

Thanks for the explanation that's great

Just a couple more questions if you wouldn't mind...

I know that synchronous, and Toggle NAND are faster than asynchronous, but can you tell me the differences between them all? Is Toggle faster than Synchronous?

Do the different size NAND cells matter? I see SSDs have 32nm, 34nm, 24nm NAND, does this matter?

Thanks

 

Feel free to add reputation points the post.

I'm not all that familiar with these types of memory as I tend to stay away from SandForce based products. My guess is the Synchronous / Toggle NAND performs better. These links should help explain things -

SSD Components and Make Up - An SSD Primer - The SSD Review

HARDOCP - Introduction - NAND Flash Faces Off - Synchronous vs. Asynchronous

I believe the smaller sized die will have SHORTER lifetimes in regards to number of writes than the large one, and it appears to also be slower. Not 100% on this, so someone please correct me if I'm wrong.

In any case, here's another link for some issues w/ other OCZ drives (Vertex 2) - OCZ Vertex 2 25nm Review (OCZSSD2-2VTXE60G) | StorageReview.com - Storage Reviews

 

Thanks for the links. Are synchronous and Toggle NAND the same things?

 

From the SSD Components link, it sure looks that way.

 

No, all nand is not the same:

See:
60/64 GB SSD Shootout: Crucial, Samsung, And SandForce : Which 64 GB SSD Is The Best?