Original Link: https://www.anandtech.com/show/3661/understanding-sandforces-sf1200-sf1500-not-all-drives-are-equal
Understanding SandForce's SF-1200 & SF-1500, Not All Drives are Equal
by Anand Lal Shimpi on April 16, 2010 11:30 AM ESTLess than 24 hours ago I was called into a meeting with SandForce, the SSD controller manufacturer that has been on fire lately. The company makes two controllers: the SF-1200 and SF-1500. The meeting was initiated by SandForce to clear up any misconceptions I might have about the differences between the two controllers. No good deed goes unpunished, and the quick meeting turned into an hour long debate about responsibility and ethics. It turns out that while I finally know the difference between the SF-1200 and the more expensive SF-1500, not all drives based on the SF-1200 will offer the same performance. In fact, some drives that are currently on the market will actually drop in performance (in one metric) if you upgrade them to SF’s mass production firmware. Yep.
SF-1200 vs. SF-1500
On SandForce’s site are two controller options: the SF-1500 intended for enterprise (server) customers, and the SF-1200 for client (desktop/notebook) SSDs. The first silicon ready was SF-1500, and a derivative version of that was used in the earliest drives (e.g. OCZ’s Vertex Limited Edition). More recently however we’ve seen SF-1200 based SSDs crop up, such as Corsair’s Force drive. In our recent review we found no performance difference between the Force drive and the Vertex LE, leading me to believe that there’s no tangible performance difference between the SF-1200 and SF-1500. However since then I’ve finally got a good handle on the differences directly from SandForce.
The SF-1500 controller from the original Vertex LE.
Let’s start with the obvious and what I suspected: there is no physical difference between the SF-1200 and SF-1500. It’s the same die. The difference between the two amounts to firmware, validation and settings on the chips themselves. It’s akin to Intel disabling Hyper Threading on the Core i5 750 but leaving it enabled on the Core i7 860; same die, different features.
The SF-1200 controller on Corsair's Force SSD. The chips are the same, it's all about firmware and settings.
As an enterprise class solution, the SF-1500 is designed to complete any writes in progress in the event of sudden power loss. The SF-1500 firmware is configured expecting the presence of the super cap we saw in the Vertex 2 Pro. As such it expects that it can write at full speed without any worries about power loss. In other words, it assumes you have power failure protection at the drive level.
The SF-1200 firmware on the other hand doesn’t assume the presence of a large capacitor to keep the controller/NAND powered long enough to complete all writes in the event of a power failure. As such it does more frequent check pointing and doesn’t guarantee the write in progress will complete before it’s acknowledged. It’s a subtle difference, but the SF-1500 with super cap may be necessary for some of SandForce’s enterprise customers.
The SF-1500's super cap, necessary because SandForce's controller keeps a couple of MBs of data buffered
Continuing the enterprise focus, the SF-1500 supports more SMART attributes and logging/debug/diagnostic features. SandForce wasn’t willing to elaborate on this point but said that it shares the SMART feature list with its customers under NDA. If this sort of thing might matter to you, sign a NDA with SandForce and they’ll apparently tell all.
As I pointed out in the Corsair Force review, SandForce rates the SF-1500 for a longer mean time to failure than the SF-1200. This is a basic binning/testing advantage. The SF-1500 goes through more tests and qualification than the SF-1200 allowing SandForce to guarantee higher reliability. That’s not to say that the SF-1200 won’t last as long as or longer than the SF-1500, it’s just that SandForce is willing to guarantee a longer lifespan on the SF-1500 than it is willing to do for the SF-1200. I poked fun at SF’s mean time to failure ratings in the Force review, however SandForce explained the MTTF is calculated across the entire population of controllers - not the lifespan of a single controller.
In a population of 10,000,000 controllers, with a rating of 10,000,000 hours, the probability is that 1 unit would fail in an hour. The SF-1200 would have 5 units fail in the same time. The failure probability drops as the number of controllers drops (SF won’t be shipping anywhere near 10M of these things).
While both the SF-1200 and SF-1500 support MLC NAND, the SF-1500 also supports SLC. This once again is more of an enterprise class feature as most desktop users aren’t willing to pay the 2x price premium of SLC vs. MLC NAND flash.
SandForce Controller Comparison | ||||
SF-1200 | SF-1500 | |||
Flash Memory Support | MLC | MLC or SLC | ||
Power Consumption | 550 mW (typical) | 950 mW (typical) | ||
Sequential Read/Write Performance (128KB) | 260 MB/s | 260 MB/s | ||
Random Read/Write Performance (4K) | 30K/10K IOPS | 30K/30K IOPS | ||
Security | 128-bit AES Data Encryption, Optional Disk Password | 128-bit AES Data Encryption, User Selectable Encryption Key | ||
Unrecoverable Read Errors | Less than 1 sector per 1016 bits read | Less than 1 sector per 1017 bits read | ||
MTTF | 2,000,000 operating hours | 10,000,000 operating hours | ||
Reliability | 5 year customer life cycle | 5 year enterprise life cycle |
So far none of these differences matter to a client user, but the last item on the list does. There’s a performance difference between the SF-1200 and SF-1500. The SF-1500 is capable of higher sustained small file random write speed. The SF-1200 is rated at 10,000 4K random write IOPS (sustained), while the SF-1500 is rated at 30K (sustained). This is purely a firmware limitation, but SandForce believes the 10K number is high enough for client PCs (Intel rates its X25-M G2 at 6.6K for the 80GB model and 8.6K for the 160GB model).
The controllers should otherwise perform the same, it’s only in small file random writes that there’s a difference (realistically speaking we’re talking random writes smaller than 16KB in size). SandForce notes the difference on its website, however in our testing of Corsair’s Force drive we showed absolutely no difference. So what’s going on?
It’s a Mad World: Not All SF-1200s Perform Alike
OCZ was the first from our community to really embrace SandForce. It’s my understanding that the two companies have a very close relationship, and OCZ has committed a lot of resources to SandForce and its products. OCZ took the early risk that others would not. While other companies are working with SF today, OCZ appears to have been the first from the SSD makers we cover on the site.
In exchange for their cooperation and support, SandForce gave OCZ a couple of things. First was the unique SF-1500 used in the Vertex LE at competitive prices (and minus some of the enterprise features). This gave OCZ a huge head start on the competition. The second thing SandForce gave OCZ was the rights to an exclusive firmware for the SF-1200. This firmware would give OCZ the small file random write performance of the SF-1500, but with the rest of the feature set of the SF-1200. This special firmware is going to be used in the upcoming Vertex 2 SSD.
The rest of SandForce’s customers would get the standard SF-1200 firmware, which allows the drive to run at 10,000 sustained 4K random IOPS. Other SF-1200 drives from OCZ, such as the upcoming Agility 2, would also use this standard SF-1200 firmware. The special firmware is only for the Vertex 2 at this point.
SandForce’s firmware has been in release candidate (RC) stage for the past couple of months. Internally SandForce calls this version 3.0.1 and has communicated to all of its partners what RC vs. MP (mass production) firmware entails:
This slide is shared with all SF partners.
Two things are true about this RC firmware: 1) it doesn’t limit small file random write speed on the SF-1200, and 2) there is a known reliability issue that could result in a dead drive (similar to what happened to my Vertex 2 Pro earlier this year).
And here’s where things get messy. SandForce distributed 3.0.1 to all of its partners (so much for that exclusivity agreement), and some of its partners have decided to sample reviewers or even ship based on 3.0.1. Note that even OCZ’s Vertex LE shipped using the SF-1500 version of this firmware. If SandForce indeed distributed the above slide to all of its partners, no drive should've shipped with RC firmware. That's a separate issue entirely and I've been working with both SandForce and the companies involved to see what we can do about curbing this (or at least get me the information so that I can make it clear when a product is using non-MP firmware).
The Corsair Force drive that has been sent out for reviews and that’s currently shipping today uses SandForce’s 3.0.1 firmware.
Naturally, I called up Corsair to figure out what’s going on. Corsair explained to me that the reliability problem was related to a power saving feature on the controller that Corsair simply disabled and thus avoided the issue entirely. I have yet to find a repeatable way to reproduce the bug, but the power data from our testing corroborates what Corsair is saying:
Corsair’s drive uses more power than OCZ’s Vertex LE. While it could be for a number of reasons, it’s apparently due to this power saving feature being disabled. Unless I’m wrong, Corsair appears to have circumvented the known reliability issue and is shipping product it feels is safe into the market.
Now we get to the other problem. The performance of 3.0.1 is the same as OCZ’s exclusive SF-1200 firmware, because the firmwares are the same. However SandForce has recently released its first MP firmware: 3.0.5. This firmware, as you’d expect, caps small file random write performance on all SF-1200 drives except for the Vertex 2 in accordance with SandForce’s agreement with OCZ. The SF-1500 version of this firmware doesn’t change performance, but it does supposedly fix the reliability problems and is available for Vertex LE owners here.
Corsair is currently testing the 3.0.5 revision for its drive but hasn’t shared it with me yet. Corsair wasn’t aware that performance dropped with this revision until I called yesterday. The release notes don’t indicate anything of the sort, Corsair was kept completely in the dark on this. Why didn’t SandForce tell Corsair? Because although it drops performance, the new firmware still runs the SF-1200 at its intended spec. The chip will continue to perform as advertised, just slower than with the RC firmware and slower than OCZ’s Vertex 2.
Where Do We Go From Here?
Corsair is under no obligation to ship drives with the 3.0.5 firmware. Assuming there are no other problems with the 3.0.1 firmware, Corsair could presumably keep shipping the higher performing OCZ-like firmware. The problem is that if you ever need to upgrade your firmware, you could lose performance.
As I've mentioned in the past, customers of whatever company or companies work closest with the controller manufacturer will undoubtedly get access to firmware quicker than anyone else. We've seen this work both in favor of and against the best interests of the consumer. Sometimes you get features/performance early (e.g. TRIM support for Indilinx drives) and other times you get early, untested firmware. Your best bet at this point is to hold off on any SF-1200 purchases unless you're willing to accept the risks that comes with.
The case isn’t closed on this issue however, not by a long shot. It’s my understanding that the SandForce/OCZ exclusivity agreement is currently only a short term agreement. While the companies are in the process of negotiating a long term agreement, nothing is final yet.
There are some measures in place to ensure that you can’t flash an OCZ firmware on a non-OCZ drive (and vice versa) but there’s nothing saying that at some point this won’t change either.
We also don’t know what the real world impact of the standard SF-1200 firmware will be. I’m hoping to have a standard SF-1200 drive with production firmware very soon and I will report my findings as soon as possible.
I’ve also communicated to SandForce that this should have never happened. It was well aware that there would be a performance difference between the Vertex 2 and all other SF-1200 drives, and there’s absolutely no reason any company other than OCZ should have had 3.0.1 with that exclusivity agreement in place. It’s simply not right to give your partners performance that you know for a fact will later be taken away. SandForce indicated to me that everyone was aware that performance could change between firmware revisions, but in my opinion this is still not being totally transparent. The moment a review based on Corsair’s Force drive went live, SandForce should’ve had a discussion with Corsair and the reviewer. We weren’t the first to review the Force drive, but it wasn’t until after our review went live that SandForce contacted us.
SandForce is a very young company and this just sounds like a bad case of partner mismanagement. Thankfully there haven’t been that many SF-1200 drives sold, but if you’re considering one you have to keep in mind that you could see performance drop in one metric with a firmware update. Note that the drive will still perform as specified, the SF-1200 controller is only rated for 10,000 sustained 4K random write IOPS.
There’s also the issue of SSD makers shipping drives based on firmware that’s not MP ready. I’ve established a more direct line with SandForce so I’ll at least be made aware of what firmware is ready for shipping and what isn’t. I’ll also be putting more pressure on manufacturers to only ship MP ready firmware. Let this serve as a warning to SSD manufacturers. I haven't been keeping close tabs on shipping firmware revisions since I never recommend any brand new, unproven SSD controller. But clearly I'm going to have to start docking points for not following controller manufacturer guidance. This stuff is serious guys, you're playing with our data here - I can't stress that enough.
As I keep mentioning in my coverage of SandForce and any other new SSDs, if you jump on board you’re assuming a risk. These drives and controllers are largely unproven. While I’m doing my best to put them through their paces, I can’t test every system combination. On top of that, many of these companies are newcomers to the industry and as an early adopter, you might find yourself in the middle of a situation like this.
This is unfolding in real time so I’ll keep you posted as I come across any new developments.