Intel was rumored to be working on a SandForce based drive for several months now, but even the rumors couldn't encapsulate just how long Intel and SF has worked on this drive. According to Intel, the relationship began 1.5 years ago. Still lacking a 6Gbps controller of their own and wanting to remain competitive with the rest of the market, Intel approached SandForce about building a drive based on the (at the time) unreleased SF-2281 controller. Roughly six months later, initial testing and validation began on the drive. That's right, around the time that OCZ was previewing the first Vertex 3 Pro, Intel was just beginning its extensive validation process.

Codenamed Cherryville, Intel's SSD 520 would go through a full year of validation before Intel would sign off on the drive for release. In fact, it was some unresolved issues that cropped up during Intel's validation that pushed Cherryville back from the late 2011 release to today.

Intel's strenuous validation will eventually make SandForce's drives better for everyone, but for now the Cherryville firmware remains exclusive. Intel wouldn't go on record with details of its arrangement with SandForce, but from what I've managed to piece together the Intel Cherryville firmware is exclusive for a limited period of time. That exclusivity agreement likely expires sometime after the SF-2281 is replaced by a 3rd generation controller. There are some loopholes that allow SandForce to port bug fixes to general partner firmware but the specific terms aren't public information. The important takeaway is anything fixed in Intel's firmware isn't necessarily going to be fixed in other SF-2281 based drives in the near term. This is an important distinction because although Cherryville performs very similarly to other SF-2281 drives, it should be more reliable.

As Intel has been working on this firmware for quite a while, it's likely that the 520 uses an older branch of the SF-2281 firmware that has been updated over the past twelve months.

The BSOD is Back, but Not on Intel

Back in October SandForce announced that it had discovered a firmware issue that resulted in unexpected BSODs on SF-2281 drives on certain platforms. Why it took SandForce several months to discover the bug that its customers had been reporting for a while is a separate issue entirely. SandForce quickly pushed out the firmware to OCZ and other partners. Our own internal testing revealed that the updated firmware seemed to have cured the infamous BSOD.

Just as background, our SSD testing is rarely over once the review goes live. Any drive we recommend gets tossed into a primary use machine somewhere within the company. We keep track of drive behavior, including any bugs or performance issues over time. This long term testing process takes place over months. The results of these long term tests are folded into future reviews and recommendations.

The BSOD is caused by a bug in SandForce's power state logic that ultimately results in the drive disconnecting from the system while it's running. It turns out that Windows isn't a fan of you hot un-plugging the drive it's running on, which results in the BSOD. We had two systems that exhibited the BSOD, both of which were fixed by the update last October.

As luck would have it, our own Brian Klug happened to come across an unexpected crash with his 240GB non-Intel SF-2281 based SSD two weeks ago when he migrated it to another machine. The crash was an F4 BSOD, similar in nature to the infamous BSOD issue from last year. While two of the systems we reproduced the BSOD bug on were cured by last year's firmware update, Brian's system (an X58/Core i7 build) was BSODing regularly playing Battlefield 3. Games end up being a great way to trigger the SF-2281 BSOD issue as they frequently switch between periods of idle and load, which does a good job of stressing the power state logic in SandForce's firmware. I immediately sent Brian an Intel SSD 520 to see if the BSOD remained on Intel's drive. Switching to Cherryville caused Brian's BSODs to go away. Indeed most end user reports of SF-2281 BSODs went away with the fixed firmware, but we've still heard of isolated issues that remain unresolved. Whatever Intel has done with the 520's firmware seems to have fixed problems that still remain in the general SF-2281 firmware.

This is actually a dangerous precedent as it means one of two things. The first possibility is that SandForce has been made aware of flaws in its current firmware and chooses against (or is legally prevented from) disclosing it to its partners. The second possibility, and arguably even worse for SandForce, is that Intel was able to identify and fix a bug in the SF-2281 firmware without SandForce knowing it existed or was addressed. I suspect it's the former but as no one is willing to go on the record about the Intel/SandForce agreement I can't be certain.

Intel did go on record saying that the 520 is expected to have far fewer F4/F7 BSODs than any other SF-2281 drive. I asked Intel if I should read into the phrase "far fewer", but the answer was no - the 520 is expected to have similar reliability to the Intel SSD 510 and 320.

At the end of the day that's what Intel really brings to the table with the 520. As you'll soon see, performance isn't very different compared to other SF-2281 based drives. Intel's biggest advantage comes from the unique firmware that ships with the drive. Intel is also quick to point out that while other SF-2281 manufacturers can purchase the same Intel 25nm MLC NAND used on the 520, only Intel's drives get the absolute highest quality bins and only Intel knows how best to manage/interact with the NAND on a firmware level. While it's nearly impossible to prove most of this, the fact that we're still able to reproduce a BSOD on the latest publicly available SF-2281 firmware but not on the SF-2281 based Intel SSD 520 does say a lot about what you're paying for with this drive.

And you are paying a premium for the 520 compared to other SF-2281 based SSDs on the market today:

Intel SSD 520 Price Comparison
	60GB	120GB	180GB	240GB	480GB
Intel SSD 520 (SF-2281)	$149	$229	$369	$509	$999
Kingston HyperX (SF-2281)	N/A	$205	N/A	$420	N/A
OCZ Vertex 3 (SF-2281)	$95	$190	$240	$375	$850
Samsung SSD 830	$110	$220	N/A	$360	$800

Last year Intel hinted at a move from the consumer market to enterprise server and client markets. The 520's higher price likely won't matter there, but for consumers the higher price is noticeable - particularly with good options from companies like Samsung now available on the market.

The Intel SSD 520

Intel sent us a 240GB and 60GB SSD 520 for review, but the performance specs of the entire family are in the table below:

The Intel SSD 520 is available in both 9.5mm and 7mm versions, with the exception of the 480GB flavor that only comes in a 9.5mm chassis. The 520's uses Intel's standard 7mm chassis with a 2.5mm removable plastic adapter that we've seen since the X25-M G2. The plastic adapter allows the drive to fit in bays designed for 9.5mm drives. Note that Intel doesn't ship shorter screws with the 9.5mm drives so you can't just remove the plastic adapter and re-use the existing screws if your system only accepts a 7mm drive.

Inside the drive we see the oh-so-familiar SandForce SF-2281 controller and Intel 25nm MLC NAND. The controller revision appears unchanged from other SF drives we've seen over the past year. The PCB design is unique to the 520, making it and the custom Intel firmware the two noticeable differences between this and other SF-2281 drives.

Intel uses the metal drive chassis as a heatsink for the SF-2281 controller

The SF-2281 Controller

I've explained how the SF-2281 works in the past, but for those of you who aren't familiar with the technology I'll provide a quick recap. Tracking the location of data written to an SSD ends up being one of the most difficult things a controller has to do. There are a number of requirements that must be met. Data can't be written to the same NAND cells too frequently and it should be spread out across as many different NAND die as possible (to improve performance). For large sequential transfers, meeting these (and other) requirements isn't difficult. Problems arise when you've got short bursts of random data that can't be combined. The end result is leaving the drive in a highly fragmented state that is suboptimal for achieving good performance.

You can get around the issue of tracking tons of data by simply not allowing small groups of data to be written. Track data at the block level, always requiring large writes, and your controller has a much easier job. Unfortunately block mapping results in very poor small file random write performance as we've seen in earlier architectures so this approach isn't very useful for anything outside of CF/SD cards for use in cameras.

A controller can rise to the challenge by having large amounts of cache (on-die and externally) to help deal with managing huge NAND mapping tables. Combine tons of fast storage with a fast controller and intelligent firmware and you've got a good chance of building a high performance SSD.

SandForce's solution leverages the work smart not hard philosophy. SF controllers reduce the amount of data that has to be tracked on NAND by compressing any data the host asks to write to the drive. From the host's perspective, the drive wrote everything that was asked of it, but from the SSD's perspective only the simplest representation of the data is stored on the drive. Running real-time compression/de-duplication algorithms in hardware isn't very difficult and the result is great performance for a majority of workloads (you can't really write faster than a controller that doesn't actually write all of the data to NAND). The only limit to SandForce's technology is that any data that can't be compressed (highly random bits or data that's already compressed) isn't written nearly as quickly.

Intel does a great job of spelling out the differences in performance depending on the type of data you write to the SSD 520, but it's something that customers of previous Intel SSDs haven't had to worry about. Most client users stand to benefit from SandForce's technology and it's actually very exciting for a lot of enterprise workloads as well, but you do need to pay attention to what you're going to be doing with the drive before deciding on it.

The Intel SSD Toolbox

The Intel SSD 520 works flawlessly with the latest version of Intel's SSD Toolbox. The toolbox allows you to secure erase the drive from within Windows, and it also allows you to perform firmware updates and pull SMART info from the drive. Unlike other SandForce toolboxes, Intel's software works fine with Intel's RST drivers installed.

The Test

CPU	Intel Core i7 2600K running at 3.4GHz (Turbo & EIST Disabled) - for AT SB 2011, AS SSD & ATTO
Motherboard:	Intel DH67BL Motherboard
Chipset:	Intel H67
Chipset Drivers:	Intel 9.1.1.1015 + Intel RST 10.2
Memory:	Corsair Vengeance DDR3-1333 2 x 2GB (7-7-7-20)
Video Card:	eVGA GeForce GTX 285
Video Drivers:	NVIDIA ForceWare 190.38 64-bit
Desktop Resolution:	1920 x 1200
OS:	Windows 7 x64

Random Read/Write Speed

The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.

Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). I perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.

Random read performance seems to have topped out around 60MB/s for most drives and the 520 is no different here.

Random write performance, especially with highly compressible data sets the 520 performs beautifully - even outpacing the SF-2281 based Kingston HyperX.

Many of you have asked for random write performance at higher queue depths. What I have below is our 4KB random write test performed at a queue depth of 32 instead of 3. While the vast majority of desktop usage models experience queue depths of 0 - 5, higher depths are possible in heavy I/O (and multi-user) workloads:

At higher queue depths the HyperX catches up to and surpassed the 520, perhaps indicating that Intel has done some work to optimize low queue depth performance on the 520 (likely what most end users will encounter).

Sequential Read/Write Speed

To measure sequential performance I ran a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.

Sequential read performance is actually a bit lower than Intel's 510, but still higher than a standard SF-2281 drive.

It's important to note just how close the 520's peak random write performance is to its sequential write performance. A big part of this is obviously that the SF-2281 is throwing away a lot of the data it has to write, but even if we compare incompressible 4KB random write to highly compressible 128KB sequential write we see a good ratio. The closer those two values are the more optimal the controller/firmware design is as, in theory, smaller random writes should be grouped to effectively become large sequential writes from the perspective of the NAND.

AS-SSD Incompressible Sequential Performance

The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers.

Toss incompressible data at the 520 and its performance is more middle-of-the-road when it comes to write speed. There's no real difference between the 520 and the Kingston HyperX here.

AnandTech Storage Bench 2011

Last year we introduced our AnandTech Storage Bench, a suite of benchmarks that took traces of real OS/application usage and played them back in a repeatable manner. I assembled the traces myself out of frustration with the majority of what we have today in terms of SSD benchmarks.

Although the AnandTech Storage Bench tests did a good job of characterizing SSD performance, they weren't stressful enough. All of the tests performed less than 10GB of reads/writes and typically involved only 4GB of writes specifically. That's not even enough exceed the spare area on most SSDs. Most canned SSD benchmarks don't even come close to writing a single gigabyte of data, but that doesn't mean that simply writing 4GB is acceptable.

Originally I kept the benchmarks short enough that they wouldn't be a burden to run (~30 minutes) but long enough that they were representative of what a power user might do with their system.

Not too long ago I tweeted that I had created what I referred to as the Mother of All SSD Benchmarks (MOASB). Rather than only writing 4GB of data to the drive, this benchmark writes 106.32GB. It's the load you'd put on a drive after nearly two weeks of constant usage. And it takes a *long* time to run.

1) The MOASB, officially called AnandTech Storage Bench 2011 - Heavy Workload, mainly focuses on the times when your I/O activity is the highest. There is a lot of downloading and application installing that happens during the course of this test. My thinking was that it's during application installs, file copies, downloading and multitasking with all of this that you can really notice performance differences between drives.

2) I tried to cover as many bases as possible with the software I incorporated into this test. There's a lot of photo editing in Photoshop, HTML editing in Dreamweaver, web browsing, game playing/level loading (Starcraft II & WoW are both a part of the test) as well as general use stuff (application installing, virus scanning). I included a large amount of email downloading, document creation and editing as well. To top it all off I even use Visual Studio 2008 to build Chromium during the test.

The test has 2,168,893 read operations and 1,783,447 write operations. The IO breakdown is as follows:

AnandTech Storage Bench 2011 - Heavy Workload IO Breakdown
IO Size	% of Total
4KB	28%
16KB	10%
32KB	10%
64KB	4%

Only 42% of all operations are sequential, the rest range from pseudo to fully random (with most falling in the pseudo-random category). Average queue depth is 4.625 IOs, with 59% of operations taking place in an IO queue of 1.

Many of you have asked for a better way to really characterize performance. Simply looking at IOPS doesn't really say much. As a result I'm going to be presenting Storage Bench 2011 data in a slightly different way. We'll have performance represented as Average MB/s, with higher numbers being better. At the same time I'll be reporting how long the SSD was busy while running this test. These disk busy graphs will show you exactly how much time was shaved off by using a faster drive vs. a slower one during the course of this test. Finally, I will also break out performance into reads, writes and combined. The reason I do this is to help balance out the fact that this test is unusually write intensive, which can often hide the benefits of a drive with good read performance.

There's also a new light workload for 2011. This is a far more reasonable, typical every day use case benchmark. Lots of web browsing, photo editing (but with a greater focus on photo consumption), video playback as well as some application installs and gaming. This test isn't nearly as write intensive as the MOASB but it's still multiple times more write intensive than what we were running last year.

As always I don't believe that these two benchmarks alone are enough to characterize the performance of a drive, but hopefully along with the rest of our tests they will help provide a better idea.

The testbed for Storage Bench 2011 has changed as well. We're now using a Sandy Bridge platform with full 6Gbps support for these tests.

AnandTech Storage Bench 2011 - Heavy Workload

We'll start out by looking at average data rate throughout our new heavy workload test:

SandForce has always done well in our Heavy Workload test, and the 520 is no different. For heavy multitasking workloads, the 520 is the fastest SSD money can buy. Note that its only hindrance is incompressible write speed, which we do get a hint of in our breakdown of read/write performance below.

The next three charts just represent the same data, but in a different manner. Instead of looking at average data rate, we're looking at how long the disk was busy for during this entire test. Note that disk busy time excludes any and all idles, this is just how long the SSD was busy doing something:

AnandTech Storage Bench 2011 - Light Workload

Our new light workload actually has more write operations than read operations. The split is as follows: 372,630 reads and 459,709 writes. The relatively close read/write ratio does better mimic a typical light workload (although even lighter workloads would be far more read centric).

The I/O breakdown is similar to the heavy workload at small IOs, however you'll notice that there are far fewer large IO transfers:

AnandTech Storage Bench 2011 - Light Workload IO Breakdown
IO Size	% of Total
4KB	27%
16KB	8%
32KB	6%
64KB	5%

The stock SF-2281 firmware gives Kingston the edge in our light workoad test, but Intel's SSD 520 is close behind.

Performance Over Time & TRIM

SandForce's controllers have always behaved poorly if you pushed them into their worst case scenario. Should you fill a SF-2281 based drive completely with incompressible data then continue to write to the drive with more incompressible data (overwriting some of what you've already written) to fill up the spare area you'll back the controller into a corner that it can't get out of, even with TRIM. It's not a terribly realistic situation since anyone using an SF-2281 SSD as a boot drive will at least have Windows (or some other easily compressible OS) installed, and it's fairly likely that you'll have other things stored on your SSD in addition to large movies/photos. Regardless, it's a corner case that we do have to pay attention to.

I was curious to see if Intel's firmware did anything differently than the standard SandForce build used by other partners. To find out I took an Intel SSD 520 (240GB) and a Kingston HyperX (SF-2281 240GB) and filled both drives with incompressible data. I then ran a 60 minute 4KB random write torture test (QD32), once again, with incompressible data. Normally I'd use HDTach to chart performance over time however HDTach measures performance with highly compressible data so we wouldn't get a good representation of performance here. Instead I ran AS-SSD to get a good idea for incompressible sequential performance in this worst case state. Afterwards, I TRIMed the drives and ran AS-SSD again to see if TRIM could recover the drive's performance.

Intel SSD 520 - Resiliency - AS SSD Sequential Write Speed - 6Gbps
	Clean	After Torture	After TRIM
Intel SSD 520 240GB	284.5 MB/s	162.9 MB/s	162.9 MB/s
Kingston HyperX 240GB	289.3 MB/s	162.5 MB/s	162.5 MB/s

Surprisingly enough, Cherryville doesn't actually perform any differently than the stock SandForce firmware in this case. SandForce definitely improved the worst case scenario performance with the SF-2281 compared to the first generation controller, and it also improved performance compared to earlier builds of the 2281 firmware, but Intel appears to have not done anything above and beyond here. Based on these results I'd be willing to bet that Intel doesn't have source code access to the SF-2281 firmware otherwise it would've worked on a solution to this corner case. Performance in this worst case scenario isn't terrible but the fact that it's irrecoverable even after a TRIM is what's most troubling. Again, I don't see most end users backing themselves into this corner but it's worth pointing out.

Power Consumption

The 520 uses measurably more power than Kingston's HyperX at idle, however it's otherwise in-line with what we'd expect from an SF-2281 based drive.

Final Words

I've been a fan of SandForce's technology since it first showed up in OCZ's Vertex 2 Pro in late 2009. Performance has never been an issue with SandForce and because of the fact that the controller writes less than its competitors, the controller and drives based on it are well behaved over months of use. The biggest issue with SandForce has always been a lack of validation compared to other, bigger players like Intel and Samsung. SandForce relies on its partners to do a lot of the validation and testing that would normally be internalized at its competitors. Until now, SandForce hasn't really had a partner large enough to really throw a ton of resources at drive validation. Now that SandForce is under the LSI umbrella things may change, but until then we finally have a well validated SF-2281 drive: the Intel SSD 520.

I'm still curious to see if other bugs crop up but if Intel hasn't found anything else after twelve months of testing I'm willing to bet that either the SF-2281 is irreparably broken or the 520 is going to be a reliable SSD.

I only have one data point where the 520 behaves better than other SF-2281 based drives, but that alone is a perfect example of what you pay for with Intel. This is exactly what we've been waiting for. If you want the absolute fastest SSD on the market today, the Intel SSD 520 is the only drive to get. If you're put off by the price, Samsung's SSD 830 is an excellent alternative.

I'm going to save this next bit for a future article, but have a look at the 520's performance in our enterprise workloads compared to the Intel SSD 320:

Enterprise SSD Performance
	Oracle Swingbench	MS SQL DailyUpdates	MS SQL WeeklyMaint
Intel SSD 320 300GB	56.5 MB/s	207.3 MB/s	230.4 MB/s
Intel SSD 520 240GB	67.2 MB/s	376.7 MB/s	418.1 MB/s

The 320 is actually widely used in servers as it's very reliable and can last a good amount of time with the right amount of over-provisioning. The 520 just destroys it. The bigger benefit is that if you're dealing with a workload that's not already compressed, the 520 will guarantee you much better drive longevity than the 320 thanks to the fact that it's simply not writing as much data to NAND. If you're looking for an affordable way to get a ton of IOPS for your enterprise workloads, Cherryville may be your ticket...