The key to good SSD performance is the controller. One SSD controller that has received good reviews is the SandForce SF-1200. However, a recent test of a SF-1200 SSD reveals some interesting things about what this controller does and just how it does it. Depending upon your point of view and, radically, your data, performance can be amazing.
Remember that SSDs have really great read performance due to the low latency of the SSD. So in the case of the SF-1200 controller, the data has to be read (which is quite fast), and then expanded (uncompressed). Logically, the time it takes the data to be uncompressed and other associated operations reduces the performance but the amount of data is potentially smaller than the true amount of data. Overall the impact of incompressible data relative to compressible data results in only about a 30% reduction in read throughput performance.
The ultimate driver of write throughput performance is the compressibility of the data. If the data is very compressible, then only a small part of the data actually has to be written to the storage media and the resulting throughput can be quite high. If the data is incompressible, then virtually all of it has to be written to the storage media within the drive but the resulting write throughput is reduced because of the time it has taken to examine the data and compress it with little or no resulting compression. In the case of the SandForce SF-1200 controller, if the data is almost incompressible, then we can see the write performance is greatly reduced (from about 260 MB/s to 65 MB/s – a factor of 4 reduction).
Data Capacity
An additional aspect of data compression to be considered is the space or data capacity of the SandForce based SSD. One would think that you could use data compression to improve the data capacity of the device. However, remember that the amount of space depends upon the compressibility of the data.
When you type “ls -lsa” on a file on your gleaming Linux box, you want it to report the correct information about the file including the number of bytes and/or the number of blocks. This is true regardless of the storage media including SSD devices using the SF-1200 controller. Therefore, SF-1200 based devices can’t really take advantage of data compressing to report a much larger capacity than they actually have.
Life of the SSD
Recall that the chips used in SSDs have a limited number of erase cycles. So you can only write to them a certain a number of times before they can no longer hold data correctly. There are a number of techniques that can be used to reduce the number of erase cycles overall (e.g. reducing write amplification) and reduce the chances of a “hot spot” developing in the chip somewhere. SandForce SSD controllers are likely to use all of these techniques but the data compression aspect gives them a leg up on the competition.
Since the data is compressed you can actually fit more data onto a given block possibly reducing the number of times the block has to be erased. For example, let’s assuming we a 64GB SandForce SSD and a 64GB SSD using a different controller. If we write the exact same amount of data to both drives, the SandForce based SSD will use fewer blocks than the conventional SSD. Effectively, it increases the size of the block pool which means that blocks will be written to less often as compared to the conventional SSD. A really interesting (and cool) thing about SandForce SSDs is that how much longer the drive will last relative to a conventional one, fully depends upon your data. If your data is highly compressible then you get better write performance (and to some degree read performance) and the drive will last longer since you are actually storing less data.
This features also means that SandForce based SSDs can use MLC chips that are denser resulting in inexpensive $/GB drives, while still providing a drive with a potentially longer life than conventional SSDs.
Let’s take a closer look at compressing data and how you can examine your data to estimate your data compressibility.
Data Compressibility and the Impact of SF-1200 Devices
The performance and longevity of SF-1200 based SSDs really depends upon your data. If your data is very compressible you will get good write performance (actually really good write performance). If your data isn’t compressible then you won’t get good write performance. So the fundamental question you need to answer is, “how compressible is my data?” Great question and I’m glad you asked.
There is an entire field of information theory and computer science devoted to compression techniques for data (and its partner data deduplication). You can simply Google “data compression” and you will see a massive number of hits (11,900,000 when I ran the search). But just a quick examination of the top hits indicates one thing – the amount of compression depends upon your specific data and the algorithm. There you go – the dreaded “it depends” answer.
As an example, a brief survey article describes several data compression methods as well as some compression ratios. For the sake of brevity here are some results:
- Using the “compact” technique:
- Text – 38% reduction in file size
- Pascal source code – 43% reduction in file size
- C source – 36% reduction in file size
- Binary – 19% reduction in file size
- Using “compress”:
- Text and English – 50-60% reduction in file size
- Arithmetic encoding:
- 12.1% to 73.5% reduction in file size
- Huffman encoding:corresponding
- 42.1% file size reduction of large student record database
- Data compression routines for specific applications:
- Up to 98% reduction in file size have been reported
But, in addition to compressing the file, each compression algorithm requires a certain amount of computational work. In general, the more a file is compressed, the more computational work that is required (this isn’t always true because it depends upon the details but this is directionally correct).
In the case of the SandForce SF-1200 controller it is going to need a compression algorithm that is fast but also takes a fairly fixed amount of time so that the write performance does not drop through the floor in the event of incompressible data. But at the same time, the more compression that can be achieved, the better the throughput performance, particularly the write throughput.
How can you tell the compressibility of your data? The answer is that it is not easy. One thing you can do is select certain representative files for the common data types you work with. Then try using “gzip” on the files using various levels of compression and observe how much you can compress the data. For example, you could try
laytonjb@laytonjb-laptop:~$ gzip -6 file
where “-6″ is the compression level with 6 being the default. The maximum compression is “-9″. Try several levels of compression to see much compression you can achieve with those files.
But, gzip examines all of the data in the file while the SF-1200 controller will only be able to examine much smaller chunks of data. So a second thing you can do is to examine your most common applications using strace to find out the average system write call size. Then you can use “dd” to extract portions of your sample data files corresponding to the average write function size and run various levels of compression using gzip on the files. For example, to extract a portion of your file corresponding to 4KB (4,096 bytes) you can use,
laytonjb@laytonjb-laptop:~$ dd if=file of=data_example_1 bs=4096 skip=13
This command assumes that your file is larger than 14*4KB because I skipped the first thirteen 4KB blocks (skip=13). It’s fairly simple to write a bash script that takes a file, breaks it into n chunks of a specific block size, runs various levels of gzip on each block, and records the amount of compression for each block and compression level. Then you could take an average of the compression levels over all blocks and you will have an idea of compressibility of your data files.
It seems like a lot of work, and it can be, but it will definitely help you determine the compressibility of your data. If it looks like your data is very compressible, then a SF-1200 based SSD might be a really great solution for you. If your data isn’t that compressible, then a SF-1200 based SSD might not be the best solution for you in its present form. Let’s define the file compression ratio as, (file size after compression) / (file size before compression). A compression ratio of 1 gives you the minimal performance (i.e. the data isn’t compressible) and that a very small compression ratio will get you near the top in terms of the performance (about 260 MB/s for read and write throughput). You can use this measure of compression ratio to determine the “compressibility” of your data.
Alternatively, you could also just buy a SandForce SF-1200 based device and run various tests against the drive using your data sets.
Summary
Joe Landman made a very nice discovery about SF-1200 based SSD devices – they use on-the-fly compression. This article talked about Joe’s blog post and made some conjecture of what SandForce is doing with the controller. It also talked about the implications of the design on data capacity and performance. The really, really cool result is that the compressibility of your data drives both performance and the “life” of the SSD.
That’s a pretty interesting concept if you ask me. Having a SSD drive that has performance and longevity based on your specific data is pretty unique. If you have data that is very difficult to compress then you get some level of performance and longevity in your drive. But if your data is very compressible, then you can get a boost in performance and longevity. This is an interesting design that could point to some future SSD controller designs. Imagine taking Intel’s or Pliant’s SSD controller and combining it with SandForce’s compression technology – you could get some very good performance for data that is incompressible but you also have the possibility of going well above that performance level if the data is compressible. I guess you could think of it as analogous to Intel’s and AMD’s “Turbo mode” for CPUs that allows cores to increase their clock speed if there is thermal capability left in the chip. Or you could draw an analogy with This is Spinal Tap where the SF-1200 based drive drive goes to 11 instead of the usual 10 for compressible data.
Somewhat recently, SandForce has announced a new controller that has even better performance than the SF-1200. The SF-2000 controllers promise even better performance. SandForce is stating that you can reach up to 500 MB/s for sequential reads and write performance and up to 60,000 random read and random write performance for 4KB transactions. These new controllers have a 6Gbps interface to help performance, but I can’t help assume that the controller has been improved as well.
Jeff Layton is an Enterprise Technologist for HPC at Dell. He can be found lounging around at a nearby Frys enjoying the coffee and waiting for sales (but never during working hours).
Comments on "On-the-fly Data Compression for SSDs"
Mr Layton,
Please I beg you, you must correct your rampant misuse of the innocent and worthy apostrophe. It is ssds, not ssd’s. The apostrophe means it is either a contraction, for example ssd is, or possessive, the ssd’s comic book collection. There is no apostrophe for the plural. We use ssd drives, not ssd drive’s. We have corn chips for a snack, not corn chip’s. You put on socks this morning, not sock’s. This article is several hundred words long, not word’s. I read several magazines, not magazine’s.
thank you, your high-performance article fan
It is ssds, not ssd’s.
Unfortunately, the rules for constructing the plural form of an acronym aren’t quite as straightforward as one would assume. In fact, they can nearly be summed up as “whatever looks most correct and causes the least confusion.”
While it may feel incorrect, CD’s is actually no less valid than CDs when constructing a plural. What matters is preference by the writer/editor and consistency.
Frankly, I dislike the idea that we would use case to denote a plural when we deal with so much CamelCasing in this industry. Even some of the acronyms are CamelCased; SaaS, as an example.
I can assure you we know the difference between plurals and possessives. If we used an apostrophe to denote a plural of SSD it was to reduce confusion. Not as a mistake or to incite a grammer riot. Clearly we failed at the latter.
While the world seems content to try and batter our language into the space of 140 characters or less (dashed off as an afterthought from a smartphone), we’re trying to be a bit more thoughtful than that.
Regardless, Jeff’s not really to blame for any of this. I am. Feel free to share your thoughts.
Hi
I’m not sure I agree.
“While it may feel incorrect, CD’s is actually no less valid than CDs when constructing a plural. What matters is preference by the writer/editor and consistency.”
Actually, the rules of English grammar (btw, it’s grammar, not grammer) state it clearly that apostrophes have nothing to do with marking the plural form of a noun. Hence, the form CD’s is unacceptable and it’s really nothing to do with a writer’s preferences.
Martin
My profuse apologies. I can explain why I do this but it’s a long and boring story confounded by English professors and technical marketing people getting confused in my mind (which can be an unusually busy place – at least in my mind).
Thanks for feedback – appreciated.
Jeff
P.S. I will update the article but updating posted articles takes some time and effort (i.e. it’s not easy).
So SanDisk should be taken to task for false claims. Once manufactures are permitted to make performance claims of “it go this fast (down hill with a following wind etc.)” then there is no level playing field.
Now I have some experience with SSDs (note to bugmenot3: SSD is capitalised because it is a TLA and not a word) having designed several over the last 3 years, and you are quite correct in your summation that you can gain performance by compressing your data because of the time taken to physically write blocks to NAND. Of cause any good performance tester knows this, which is why you always use large pseudo random datasets (pseudo-random data sets are used to allow repeatable tests, and large because the data set must be bigger than all of the possible cache on the system – typicly this means 2 or 3 times the total RAM installed in a machine because the OS may well still have the file hanging around without the need to go and pull it back from backing store).
Wouldn’t it be nice to have manufactures to agree on a standard performance benchmark? The SD card association (memory cards are nothing more than removable SSDs after all) has attempted to achieve this by instigating card Classes. The Class of card gives the minimum sustainable transfer speed for either direction.
However this doesn’t go far enough because we have to take into account shuffling data around for static and dynamic wear levelling, invariably this means that when writing data to a previously full drive (full minus enough space for our test write file that is), the SSD must actually perform a minimum of 2 block writes and 1 block read for every block of data in the test file.
I am yet to find an SSD that gets anywhere near advertised write speed in such tests. Most don’t come within 50% of the advertised figure.
Regards
Let me try to state things differently. There are literally thousands of applications that all have different IO patterns. Trying to develop an SSD that handles all of them well is impossible. So you have to select a target set of applications or perhaps a target market. Then you have to select representative applications and understand their IO pattern. Then you can tune the SSD firmware to perform well on those patterns.
You also couple this will the reality of running several applications at the same time which all may have different IO patterns.
The downside is that the performance may stink for other applications outside what is being targeted (as well as different loads).
So how do you market such a device? Do you tell the world that on these types of applications it will work fantastic? Do you tell the world that it will stink on other applications so don’t buy it?
My guess is that SandForce did the best they could and chose a representative set of applications that was part of their target market. Then they report the performance based on the IO patterns and applications they targeted. I don’t think there is anything wrong with that at all – in fact it was I would have done as well.
Benchmarks are a completely different subject. Do benchmarks represent real world applications? If so, which ones? Part of the difficulty is understanding the “compressibility” of the data for the applications versus the “compressibility” of the data in the benchmark. Are they comparable? Can you make any correlation between them? Is there a casual relationship?
Lots of details in designing and testing SSDs. Personally I think the technology behind SandForce is really great. You now have the opportunity to change your applications (I tend to work with applications that have source or that I write myself) to allow them to run better with SandForce based SSDs. Think of it as tuning your application for a particular chip architecture. We’ve never before had the opportunity to tune and application for storage hardware (it’s usually for memory, processor, or NICs). I personally think this is pretty cool and applaud SandForce for doing this.
Jeff
I use btrfs with lzo compression on my SSD drive, that, is the compression is done before data goes into the controller.
In the case of the Sandforce controller, if I leave the compression to it, I wouldn’t gain the storage space that gets freed due to the controller compression, whereas I increase my storage volume with the file system compression. I prefer file system compression solution.
Regards
But there is a tradeoff in your approach. Allowing btrfs to compress the data for you uses CPU time whereas SandForce uses the processor on the SSD. If CPU time is important (it is in HPC), then you might want to offload the compression to the SSD.
However if you do this you may not save any space since the SSD can’t report a variable capacity and btrfs allows you to save space before it hits the storage device. But at the very least, the SandForce controller also increases the “life” of the SSD depending upon your data.
One other observation – there aren’t many file systems that do compression. If you rely on the file system then you are stuck with that file system. But SandForce based SSDs allow you to use any file system.
It’s all a trade IMHO. The great thing that SandForce has done for us to give us some cool technology allowing us to do the things we like to do (more performance, more life in our SSD, etc). Pretty great idea IMHO.
Jeff
Alternatively it could be implementing the ‘TRIM’ SATA command, also know as ‘write same’. This is a new command that basically allows the O/S to tell the SSD that it’s writing the same block again and therefore the SSD can discard it. It’s a bit like deduplication. It’s also partly supports zero page reclaim in file systems that support it as a page of zero bytes is considered to be reclaimable and doesn’t need to be written.
What happens is that the SSD doesn’t have to do the read page/update block/write page cycle that it would normally have to do. It can simply mark a block as being empty.
Have a look at http://en.wikipedia.org/wiki/TRIM
nice discovery? Somebody has been living under a rock.
The fact that the sandforce controller compresses the data in the controller has been clearly explained since the earliest reviews of the drived.
@Leo
The question I was asking in the original work was, what sort of bandwidth should we expect … how far off the marketing numbers should we expect performance to be?
Remember, the marketing numbers call out very firm, very specific bandwidths. What we don’t see are the caveats that should go along with this. That is, we know that in a best case scenario, we should get “X”. So … how hard is it to get there?
Jeff did an excellent job of introducing the info and discussing the tradeoffs.
I have a drive with one of these controllers, this was one of the first things I checked (compressed vs uncompressed data performance).
I’m not sure his results are 100% valid. What he is describing sounds more like a fragmentation problem caused lack of TRIM/secure erase in his setup.
I’m betting that if he secure erases the drive, creates/mounts a FS, and reruns the test, the performance between compressed and uncompressed will be similar until he reaches the native capacity of the drive. Then he needs to run wiper.sh to restore it.
Basically, once the drive becomes full/fragmented the write performance goes to hell. This fact is masked by writing 100% compressible data. He should rerun the tests with 2:1 data. I’m betting his numbers are still going to be significantly less than the advertised drive speeds until he wipes the drive. Once he wipes the drive and runs wiper.sh (the linux TRIM workaround) on a frequent basis the performance will stay steady regardless of the compression ratio.
For me these discussions miss the boat almost entirely. The real breakthrough with SSDs is their low latency, two orders of magnitude lower than for hard drives. Also, in my tests with a Sandforce-based SSD and an Intel G2 SSD the latency was much more consistent and predictable than for my various 7200 rpm SATAII drives. All told, SSDs address the age old issue of slow disk vs. fast CPU and memory at the latency level, and as a result they universally speed up computational work regardless of the actual workload (except for very long running number crunching jobs). Everyone around me who has started to use an SSD won’t ever give it back, and it is not due to the overall read or write throughput- although we can quibble all day about nuances of such, it’s because of the much improved responsiveness of the system. We finally have a semblance of balanced systems back in our hands.
So if my controller gets ruined I would need to ensure I purchase the exact controller in order to ensure reliable access my data. Sounds like YAFOVLI Yet Another Form Of Vendor Lock-in. Hmmm, perhaps it might be even necessary to purchase a spare for the shelf from the get go.
jc2it
No not a lock in. SSDs use the same interface as their hard disk counterparts. The controllers we are talking about are on the SSD, just like there is a controller on every hard disk…
This is true, but of course the lack of real support is true of many of their products.ring die
I tried to like Openfiler but I couldn’t take the package manager. Conary. Why didn’t they use rpm or debian?biomass stove
Useful info. Lucky me I found your web site accidentally, and I am shocked why this accident did not came about earlier! I bookmarked it.
I like the valuable info you provide in your articles.
I’ll bookmark your blog and check again here frequently. I am quite sure I’ll learn lots of new
stuff right here! Best of luck for the next!
I’m more than happy to uncover this site. I wanted to thank you for ones time due to this wonderful read!! I definitely loved every part of it and I have you book-marked to look at new things in your site.
Have a look at my blog … Fatima
Amazing! I’m genuinely enjoying the design of your blog. Are you using a custom theme or is this readily available to all individuals? If you don’t want to say the
name of it out in the public, please be sure to e-mail me at:
rudy.parkinson@web.de. I’d love to get my hands on this template! Cheers.
Manganese ascorbate is introduced to improve the
achievement of glucosamine and aid in the healing of cartilage.
Veterinarians often recommend treating the pain of arthritis with an aspirin.
Nothing could be further from the truth.
Hello this is kinda of off topic but I was wondering if blogs use WYSIWYG editors or
if you have to manually code with HTML. I’m starting a blog soon but have no coding experience so I wanted to get advice from someone with experience. Any help would be enormously appreciated!
My homepage – wedding makeup
An intriguing discussion is definitely worth comment.
I do believe that you need to write more about
this issue, it may not be a taboo matter but typically people do not talk about such
subjects. To the next! Kind regards!!
Hi there, i read your blog occasionally and i own a similar one and
i was just wondering if you get a lot of spam remarks? If
so how do you protect against it, any plugin or anything you can recommend?
I get so much lately it’s driving me crazy so any help is very much appreciated.
You are so interesting! I do not suppose I’ve read through something like this before. So wonderful to find another person with a few original thoughts on this issue. Really.. thanks for starting this up. This web site is one thing that’s needed on
the web, someone with some originality!
Also visit my weblog – quickest way to learn spanish
Hi there just came upon your website from Bing
after I entered in, “On-the-fly Data Compression for SSDs | Linux Magazine” or perhaps something similar (can’t quite remember exactly). In any case, I’m grateful I found it because your subject material is exactly what
I’m searching for (writing a college paper) and I hope you don’t mind if I collect some information from here and I will of course credit you as the source.
Thanks.
I know this if off topic but I’m looking into starting my own blog and was curious
what all is needed to get setup? I’m assuming having a blog like
yours would cost a pretty penny? I’m not very web smart so I’m not 100% positive.
Any suggestions or advice would be greatly appreciated.
Thank you