Seagate will without any doubt have a SF3700 drive. They didn't aquire SF to watch from the sidelines. There is a good chance that Seagate already had a Sandforce drive in the works.
>While I think compression definitely has its advantage
The problem though is that generally compression is best (and increasingly) handled in the filesystem itself. It's not just more modern ones like ZFS either, even ancient ones like HFS+ have had transparent compression hacked into them. More recent improvements to algorithms (like lz4) have made it more effective and much faster. And perhaps most importantly anything encrypted is going to be incompressible, and particularly in a notebook setting FDE should be the norm, not the exception. Even in many desktops I suspect there's a fair amount of FDE.
Controller-level compression probably will have some continuing use cases, particularly in servers, but it's rapidly become more and more of a niche case, a nice bonus on top of otherwise great performance but absolutely not something to be depended on to be competitive in general.
The problem with filesystem encryption is that it's still done by the CPU, which is not optimised for compression, so the power draw usually ends up being higher and it might bottleneck some CPU intensive tasks. Another problem is that none of the mainstream filesystems support it -- while ZFS is great, it's not something that the average user (or even an enthusiast) would use since it's not natively supported by the major OSs. It's much easier for an end-user to just have a drive that does it for them instead.
As for encryption, you are right that software encryption is fully incompressible but that is why TCG Opal 2.0 is such a big thing (and the SF-2000 series as well as the SF3700 support it). With that the controller itself will be doing the encryption, so there is no need for another software layer that consumes the CPU and hurts SSD performance in the first place.
>The problem with filesystem encryption is that it's still done by the CPU, which is not optimised for compression, so the power draw usually ends up being higher and it might bottleneck some CPU intensive tasks.
At least for user workloads, it'll take more then just assertions to back this up. In general in modern systems there is an abundance of CPU available, it's the cheapest and least used resource. Something like lz4 scales across any number of cores and can easily hit 400 MB/s or higher per core for compression and 1.8GB/s for decompression. While there may be some loads where that would be a limiting factor as opposed to other parts of the system, it seems pretty niche.
>Another problem is that none of the mainstream filesystems support it
This is just wrong. NTFS and HFS+ both have compression (and have for a while). Linux also has plenty of on-the-fly compression options, and of course FreeBSD now has full ZFS integration by default. Apple at least has been using it by default in many areas since at least 10.6, that was one of the major ways they've got down on install sizes. In Windows, NTFS Compression is right there in the GUI, "Advanced Attributes > Compress".
>As for encryption, you are right that software encryption is fully incompressible but that is why TCG Opal 2.0 is such a big thing (and the SF-2000 series as well as the SF3700 support it). With that the controller itself will be doing the encryption, so there is no need for another software layer that consumes the CPU and hurts SSD performance in the first place.
Yeah there is. Software encryption is far more flexible (will SSDs support smart cards, network authentication etc?), portable, and is fully auditable rather then being a black box. And with AES-NI and equivalents CPU benchmarks might see a miniscule decline, but it's again almost never a remotely limiting factor (users with those extreme niche cases can decide for themselves). In contrast as Anand's own tests show Sandforce sequential write performance takes a big hit.
The security advantages are well worth using FDE ubiquitously right now in any mobile situation and may have use cases even for enthusiast desktops. I stand by compression being a decent bonus to offer on top of competitive universal performance, but only that. If every other player in the game can offer zero compromises, particularly as solid stage storage costs continue to decline thus expanding usage to all media including pictures/songs/video, Sandforce would be at a massive disadvantage. I think they recognize too though that controller-level compression is now merely a niche bonus, not something to build their offering around. They need to be as good everywhere else too with that being icing on the cake.
What you are missing is that the CPU consumes a ton of power. It doesn't matter how scalable the algorithms are because the CPU is just not efficient for compression compared to a chip that is specifically optimised for that. Sure that's not a problem for desktops but bear in mind that the biggest market for SSDs is portable devices where battery life is a major concern.
The same applies to encryption. TCG Opal 2.0 is software encryption in the sense that it requires encryption software but the encryption itself is hardware-accelerated. In other words, you can get the same features as with standard software encryption (including features like network authentication) but there is no CPU overhead because the drive will be doing the encryption. Take a look at our Crucial M500 testing with Microsoft eDrive, which is TCG Opal 2.0 compliant.
Furthermore, SandForce is paying a lot of attention to making the performance better regardless of the data type. They do think they are better even with 100% incompressible data, which is pretty rare (only media files are that compressed) but of course we'll have to wait and see.
I think the compression idea is clever. If the sandforce team evolves it properly it could continue to work. Very little of my data is compressable maybe 64 to 128GB. So as long as they fix the incompressable issue on the next controller it should be decent. There are quite a few users still using HDD boot disks that would never notice the inconsistant performance. Only 1 of my 4 PCs has an SSD boot disk and it is painful using a PC with a mecanical disk now.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
9 Comments
Back to Article
blanarahul - Wednesday, June 4, 2014 - link
Nice. But I wonder. Will Seagate fight with Sandforce customers and release their own SF3700 SSD?hpglow - Wednesday, June 4, 2014 - link
Seagate will without any doubt have a SF3700 drive. They didn't aquire SF to watch from the sidelines. There is a good chance that Seagate already had a Sandforce drive in the works.jjj - Wednesday, June 4, 2014 - link
Hope they figure it out sooner rather than later, since it seems that they messed it up and it got a "little bit"delayed.isa - Wednesday, June 4, 2014 - link
Nice update. Just curious: how big is the firmware team working on the 3700 series within LSI?zanon - Wednesday, June 4, 2014 - link
>While I think compression definitely has its advantageThe problem though is that generally compression is best (and increasingly) handled in the filesystem itself. It's not just more modern ones like ZFS either, even ancient ones like HFS+ have had transparent compression hacked into them. More recent improvements to algorithms (like lz4) have made it more effective and much faster. And perhaps most importantly anything encrypted is going to be incompressible, and particularly in a notebook setting FDE should be the norm, not the exception. Even in many desktops I suspect there's a fair amount of FDE.
Controller-level compression probably will have some continuing use cases, particularly in servers, but it's rapidly become more and more of a niche case, a nice bonus on top of otherwise great performance but absolutely not something to be depended on to be competitive in general.
Kristian Vättö - Wednesday, June 4, 2014 - link
The problem with filesystem encryption is that it's still done by the CPU, which is not optimised for compression, so the power draw usually ends up being higher and it might bottleneck some CPU intensive tasks. Another problem is that none of the mainstream filesystems support it -- while ZFS is great, it's not something that the average user (or even an enthusiast) would use since it's not natively supported by the major OSs. It's much easier for an end-user to just have a drive that does it for them instead.As for encryption, you are right that software encryption is fully incompressible but that is why TCG Opal 2.0 is such a big thing (and the SF-2000 series as well as the SF3700 support it). With that the controller itself will be doing the encryption, so there is no need for another software layer that consumes the CPU and hurts SSD performance in the first place.
zanon - Wednesday, June 4, 2014 - link
>The problem with filesystem encryption is that it's still done by the CPU, which is not optimised for compression, so the power draw usually ends up being higher and it might bottleneck some CPU intensive tasks.At least for user workloads, it'll take more then just assertions to back this up. In general in modern systems there is an abundance of CPU available, it's the cheapest and least used resource. Something like lz4 scales across any number of cores and can easily hit 400 MB/s or higher per core for compression and 1.8GB/s for decompression. While there may be some loads where that would be a limiting factor as opposed to other parts of the system, it seems pretty niche.
>Another problem is that none of the mainstream filesystems support it
This is just wrong. NTFS and HFS+ both have compression (and have for a while). Linux also has plenty of on-the-fly compression options, and of course FreeBSD now has full ZFS integration by default. Apple at least has been using it by default in many areas since at least 10.6, that was one of the major ways they've got down on install sizes. In Windows, NTFS Compression is right there in the GUI, "Advanced Attributes > Compress".
>As for encryption, you are right that software encryption is fully incompressible but that is why TCG Opal 2.0 is such a big thing (and the SF-2000 series as well as the SF3700 support it). With that the controller itself will be doing the encryption, so there is no need for another software layer that consumes the CPU and hurts SSD performance in the first place.
Yeah there is. Software encryption is far more flexible (will SSDs support smart cards, network authentication etc?), portable, and is fully auditable rather then being a black box. And with AES-NI and equivalents CPU benchmarks might see a miniscule decline, but it's again almost never a remotely limiting factor (users with those extreme niche cases can decide for themselves). In contrast as Anand's own tests show Sandforce sequential write performance takes a big hit.
The security advantages are well worth using FDE ubiquitously right now in any mobile situation and may have use cases even for enthusiast desktops. I stand by compression being a decent bonus to offer on top of competitive universal performance, but only that. If every other player in the game can offer zero compromises, particularly as solid stage storage costs continue to decline thus expanding usage to all media including pictures/songs/video, Sandforce would be at a massive disadvantage. I think they recognize too though that controller-level compression is now merely a niche bonus, not something to build their offering around. They need to be as good everywhere else too with that being icing on the cake.
Kristian Vättö - Wednesday, June 4, 2014 - link
What you are missing is that the CPU consumes a ton of power. It doesn't matter how scalable the algorithms are because the CPU is just not efficient for compression compared to a chip that is specifically optimised for that. Sure that's not a problem for desktops but bear in mind that the biggest market for SSDs is portable devices where battery life is a major concern.The same applies to encryption. TCG Opal 2.0 is software encryption in the sense that it requires encryption software but the encryption itself is hardware-accelerated. In other words, you can get the same features as with standard software encryption (including features like network authentication) but there is no CPU overhead because the drive will be doing the encryption. Take a look at our Crucial M500 testing with Microsoft eDrive, which is TCG Opal 2.0 compliant.
Furthermore, SandForce is paying a lot of attention to making the performance better regardless of the data type. They do think they are better even with 100% incompressible data, which is pretty rare (only media files are that compressed) but of course we'll have to wait and see.
hpglow - Wednesday, June 4, 2014 - link
I think the compression idea is clever. If the sandforce team evolves it properly it could continue to work. Very little of my data is compressable maybe 64 to 128GB. So as long as they fix the incompressable issue on the next controller it should be decent. There are quite a few users still using HDD boot disks that would never notice the inconsistant performance. Only 1 of my 4 PCs has an SSD boot disk and it is painful using a PC with a mecanical disk now.