This Just In: OCZ Agility 2 SandForce-1200 SSD
by Anand Lal Shimpi on April 17, 2010 12:09 PM EST- Posted in
- This Just In
- Storage
- SSDs
- OCZ
Things move in real time around here. Just yesterday we published an article detailing the differences between SandForce's SF-1200 and SF-1500 controller. We also pointed out that the mass production firmware for the SF-1200 controller (v3.0.5) caps 4K random write performance on all drives except for OCZ's upcoming Vertex 2. The only problem (aside from the obvious) is I had no way of determining how much of a real world impact the lower 4K random writes would have on a SF-1200 drive. Until today that is.
The Agility 2 is OCZ's standard SF-1200 SSD, using the same firmware that's been made available to all of SandForce's partners. The performance of this drive should tell us what we can expect from all other SF-1200 drives on the market. My Vertex 2 sample won't be here until next week. I also received a reference SF-1200 drive from SandForce to verify the performance results.
The drive just arrived this morning and I snapped some shots of (and took it apart) for a quick This Just In post before I got to testing. As a reminder, these posts are designed to give you all a glimpse into what is dropped off at our doorstep on a regular basis. The full review will follow.
Observations? OCZ bundles the 3.5" drive tray we've seen with a few SSDs now. The Agility 2 PCB has a silkscreened location for a super cap, which indicates that the layout/routing differences between the SF-1200 and SF-1500 are negligible. You can catch these details and more in the Gallery.
Update: Our full review is up!
Facebook
Twitter
RSS
36 Comments
View All Comments
shawkie - Saturday, April 17, 2010 - link
Anand,I think you should also seriously reconsider your use of IOMeter on these drives.
jimhsu - Saturday, April 17, 2010 - link
Is there a reason for this particularly? Reproducibility? What alternative multi-threaded benchmark would you suggest?synt4x - Saturday, April 17, 2010 - link
I too have been wondering if IOmeter is making these SF controllers look better than they are. How does the actual data that the random writes look like? If they all look similar the SF controller might easily compress them hence increasing speed dramatically. But if the data being written is just really all random bytes then I suppose there's no cause to worry about it.Though I think it's worth to look into.
TGressus - Sunday, April 18, 2010 - link
As much as I want to stay clear of the conspiracy theories, a quick glance at the Iometer SCM shows revision 28 dated 2010-03-26 05:41:08 UTC by allenwa:"Implemented improved random data algorithm and changed default MBps to be in decimal to align to industry standards."
http://iometer.svn.sourceforge.net/viewvc/iometer?...
I can understand that AT would prefer at least a release candidate for a full review. Perhaps an additional run of just 4K random writes compiled with patch revision 28 or newer might provide a useful comparison to build 2008-06-22-rc2.
That being said, the Iometer project is open source. If anyone doubts the validity of the test then they could simply review the code and back up the speculation with proof.
shawkie - Sunday, April 18, 2010 - link
I have checked the 2008 RC2 and its random data generation is terrible. Each write consists of a single byte repeated. The only randomness is between one write and the next. I haven't checked the new patch.shawkie - Sunday, April 18, 2010 - link
The new patch does produce properly random data (although it looks like it requires an option to be set somewhere):http://iometer.svn.sourceforge.net/viewvc/iometer/...
The problem I forsee with this version is that SandForce will argue that it puts their controller at a disadvantage because typical user data will be at least somewhat compressible. Perhaps there should be an option where half of each write is completely random and the other half is a single byte repeated. That should give a compression ratio of about 2:1.
bhassel - Sunday, April 18, 2010 - link
I would question the assertion that most user data is compressible. I would think it's fairly common for a drive to be filled with photos, videos, music, or game data files. All of those are typically already compressed. (Even the newer Office file formats are compressed.)shawkie - Sunday, April 18, 2010 - link
Actually I think I would tend to agree with you. I know that most of the data on my hard disk is compressed music, video or images. Either that or its video game installations which, as far as I know, are mostly compressed music, video and images.gfody - Tuesday, April 20, 2010 - link
+1The majority of user files are going to be in formats that naturally reduce entropy and will not compress well if at all. Whatever encoding they use is likely to run into its worst case scenario some percentage of the time leading to an expansion of data to write. This is easy to explain to the layperson - zip a zip and it gets bigger not smaller! There are many other reasons why data compression under the filesystem is a bad idea and has failed in the past.
Files aside, what about constant OLTP load? I find it hard to believe that low level disk activity from any properly normalized database is going to respond well to entropy encoding. Especially if leaf-node-level compression is already being leveraged by the RDBMS.
Data compression at this level will do little more than exploit an assumption made by virtually all synthetic benchmarks - that it's the volume of data that's important and not the content.
vol7ron - Tuesday, April 20, 2010 - link
It depends on the algorithm used.Another user posted "zip a zip" and it gets bigger. This happens, but it depends on what's being zipped and what level of zipping has occurred. Most likely the zip engine is using the same algorithm, thus the compression has already reached its maximum potential, leaving the size to increase due to overhead.
There are different levels of encryption/compression to consider. Generally, the higher the level, the more processing is involved, but the smaller the resulting file/storage size. On the other hand, lower levels are faster to process, but leave the file larger.
Compression engines use the combination of pattern recognition and math. My guess is that HDs would look for different patterns than applications, thus an HD could further compress an already compressed file.
I'd like to know more about the SSD compression engine that is being used before saying it doesn't do anything on already compressed data.