SandForce Announces Next-Gen SSDs, SF-2000 Capable of 500MB/s and 60K IOPS
by Anand Lal Shimpi on October 7, 2010 9:30 AM ESTSecurity: AES-256 and Double Encryption
The SF-1200/1500 controllers have a real time AES-128 encryption engine. Set a BIOS password and the drive should be locked unless you supply that password once again (note I haven’t actually tried this). The SF-2000 implements an AES-256 engine and supports double encryption. The former enables stronger encryption, while the latter allows you to set a different encryption key for multiple address ranges on the drive.
Enhanced ECC
As NAND densities go up, so will error rates and in response SandForce boosted the error correction engine on its controller. The SF-2000 error checks and corrects at a 512-byte granularity with a 55-bit BCH, up from 24-bits per 512-bytes.
The Family
SandForce is announcing three parts today: the SF-2300, SF-2500 and SF-2600. All three controllers have the same performance specs but differ in features.
The SF-2500 is the base enterprise drive. For industrial use there’s the SF-2300 that can operate at more ridiculous temperatures. The SF-2600 ships with the external SAS bridge and a special firmware revision to enable support for non-512B sectors.
Many enterprise storage systems use larger-than-512B sectors to store error correction information among other things. These sizes can be awkward like 520 bytes, 524 bytes, 528 bytes or even a 4K sector with an additional data integrity field. Currently the SF-1200/1500 controllers support these non-standard sector sizes, but you run into performance issues since writes aren’t aligned to how the drive is organized internally. With the SF-2600, there’s firmware support for any one of these sector types. The drive handles alignment issues in hardware, presumably without any performance overhead. SandForce indicated that you’d need to configure the drive for sector size in the firmware, meaning the adjustment isn’t dynamic.
Since this is a very particular type of enterprise SSD feature that’s usually seen in SAS devices, the SF-2600 is paired with a native SAS to SATA bridge. The controller is still SATA internally but the SF-2600 reference design will feature a SAS bridge on-board.
All of the enterprise SF-2000 controllers support TRIM. They also support performance throttling based on remaining program/erase cycles on the drive’s NAND (slow down the drive so the NAND lasts longer, as well as power based performance throttling (slow down the drive to reduce power consumption). SandForce hasn’t announced power specs for the SF-2000 drives, but given Intel’s drive power went up with the 3rd generation X25s I would expect something similar here.
The consumer member of the SF-2000 family will be announced sometime early next year. We will hopefully see a fairly high end version of the consumer part, missing only the enterprise specific features but retaining all of the performance.
Facebook
Twitter
RSS
84 Comments
View All Comments
jwilliams4200 - Thursday, October 7, 2010 - link
It is the Sandforce marketing department that is impressive. They have a lot of people drinking their Kool-aid. But Sandforce's actual technology does not live up to their hype.therealnickdanger - Thursday, October 7, 2010 - link
It doesn't?http://www.anandtech.com/Bench/SSD
jwilliams4200 - Thursday, October 7, 2010 - link
Note that the Sandforce drives got beat by the C300 and the X25-E on the benchmark you cited. Neither of those SSDs claims a write speed as high as 275 MB/s as Sandforce does.Also check out these benchmarks of copying real data files:
http://www.behardware.com/articles/794-11/ssd-2010...
The Sandforce drives do not even achieve 50% of their claimed write speed when faced with copying realistic data files. With real files, their write speeds are about 130 MB/s on a fresh SSD, and drop to about 83 MB/s on a well-used SSD.
This from a company that claims 275 MB/s write speeds. Sandforce is good at hype, not so much at delivering what they claim.
jwilliams4200 - Thursday, October 7, 2010 - link
Also check out these benchmarks of copying real data files:(couldn't include this in previous comment)
bit.ly/96HJIL
The Sandforce drives do not even achieve 50% of their claimed write speed when faced with copying realistic data files. With real files, their write speeds are about 130 MB/s on a fresh SSD, and drop to about 83 MB/s on a well-used SSD.
therealnickdanger - Friday, October 8, 2010 - link
Seriously, how often do you spend the majority of your time copying that many files to other drives?Those examples are pretty selective and also, it's hardly fair to pit SLC against MLC. Special use scenarios are all fine and good, but for your typical user, the current SF MLC drives beat Intel MLC in typical multi-tasking real-world scenarios (AT's benchmark, Vantage).
According to AT's reviews of SF-based drives, they all bounce back original speeds after TRIM... with "real" files. Intel degrades over time as well and then is restored after TRIM. It's the nature of the beast.
The evidence points strongly to SF beating out Intel overall by a substantial margin in real-world and synthetic tests, with Intel only winning in a handful of non-typical scenarios. I think you're just seeing what you want to see.
jwilliams4200 - Friday, October 8, 2010 - link
Copying files is a basic benchmark which gives an indication of how all other reads and writes will go. If a drive performs at less than half its claimed specification when copying files, you can be sure that it will perform similarly poorly on other tests.Yes, Anand's tests missed the Sandforce problem of performance degradation that cannot be recovered through TRIM, I'm not sure what your point is. Surely no one thinks Anand is perfect. The problem is real, and has been observed by bit-tech and by computerbase. I have also spoken with several people who have seen the problem themselves.
And the evidence is that Intel matches or beats Sandforce on most real world tests, when you are looking at a well-used drive. Sandforce's used performance degradation is really bad when you are writing data that its controller cannot compress.
'nar - Sunday, October 10, 2010 - link
Famously simple answer:"You're holding it wrong."
Copying files is not necessarily representative of normal workloads, you need a course in deductive reasoning. You cannot assume that large, contiguous, compressed files copied one at a time are at all representative of small, uncompressed, random files accessed concurrently.
Breit - Saturday, October 9, 2010 - link
This seems to be a bit unfair with SF. Since their Controllers (or lets say SSDs with their controllers) can achieve a fairly high IOps count, you should at least bench the aggregate bandwidth they achieve with multiple file transfers at once...If this is a realistic workload or not depends entirely on your needs of course, but you also should choose Hard Drives and especially SSDs depending on your application and what delivers the best performance for you. Maybe SF-SSDs aren't the best SSDs for your average workload if speedy large single-file data transfer is your main goal. :)
'nar - Sunday, October 10, 2010 - link
Anand has covered this already. Compression reduces write amplification, thus improves performance in most workloads, and extends Flash life by writing to NAND less."SandForce’s controller gets around the inherent problems with writing to NAND by simply writing less" - from this article.
Then here is the test with truly random data:
http://www.anandtech.com/show/3681/oczs-vertex-2-s...
No drive is perfect. Most large files, such as what you linked with 6.8 GB files, are compressed already. Highly compressed files like movies do not benefit from SF compression, but they also don't need to. How fast do you watch a movie? All of my movies are on hard drives.
This is not Kool-Aid, this is a choice. Use what is most appropriate for your workloads. Don't trash-talk the drive or mislead others due to one type of synthetic benchmark, or one supposed "real world scenario" that really is not what most people would use them for anyway.
Just accept that this drive has less performance with compressed, encrypted, or truly random files. I have, and I have moved on. I have purchased three sf drives while being fully aware of that fact, two OCZ LE's and a G.Skill Phoenix Pro. I do not use compressed data on them anyway, just windows and applications, all are compressible. Well, mostly compressible.
vol7ron - Thursday, October 7, 2010 - link
I imagine the added compression generates more heat for these components.Do you think that it will deteriorate the drive quicker?
I'm not up to speed on the cooling inside an SSD, but I'm curious what happens to performance when a few cells in the proc begin to go.