SandForce 1222 SSD Testing – Part 2: Initial IOPS Results

Introduction and Review of Initial Throughput Performance

I’ve been spending some time covering SandForce SSD controllers. They are very interesting because one of the techniques used to improve performance is real-time data compression. The SSD takes the incoming data and compresses it before storing it. The intent of the compression is not to improve capacity but rather to improve performance and increase longevity. What makes it even more interesting is that performance and longevity of the SSD depend upon your data (very unique and exciting concept). If your data is very compressible then you get a performance boost and a longer lasting SSD. If your data is very incompressible, then you don’t get any performance boost and the SSD will last as long as any other with the same type of cells.

In the previous article, the throughput performance of a consumer class SSD that uses the SandForce 1222 controller (the first consumer SSD controller from SandForce) was examined. More precisely, the article tested a 64GB Micro Center SSD that can be found for just under $100. The throughput performance was tested using IOzone and the good benchmarking techniques adopted a long time ago. IOzone is a particularly useful tool for testing a SandForce controller because it allows the compressibility (or dedupability) of the data to be defined allowing precise control over the data used in the testing. Four block sizes were used in the testing: (1) 1MB, (2) 4MB, (3) 8MB, and (4) 16MB. Also three levels of data compression were examined: (1) 98%, (2) 50%, and (2) 2%. When the data is 98% compressible then it means that the data can be compressed to a very small size and when the data is 2% compressible it means that data cannot be compressed very much.

The key observation resulting from the testing is that the performance varies with the level of data compression. If the data is very compressible then you will get pretty amazing performance from an inexpensive SSD and if you data is compressible as granite, then you may not get the best performance from a SandForce controlled SSD. Moreover all of the write tests with the exception of the record rewrite test, exhibited the same general behavior. More specifically:

• As the level of compressibility decreases, the performance drops off fairly quickly
  
• As the level of compressibility decreases, there is little variation in performance as the record size changes (over the record sizes tested).
  

The absolute values of the performance varied for each test, but for the general write test, the performance went from about 260 MB/s (close to the rated performance) at 98% data compression to about 97 MB/s at 2% data compression for a record size of 1 MB.

In the case of record rewrite,the average performance actually improved as the compressibility decreased but the standard deviations for a record size of 1MB were quite large. In addition, the throughput was smaller than for the write or re-write tests. And finally, the performance drops off fairly significantly when going from a record size of 1MB to 4MB.

All of the read tests exhibited the same general behavior. Specifically,

• The performance drops only slightly with decreasing compressibility (dedupability)
  
• As the level of compressibility decreases, the performance for larger record sizes actually increases
  
• As the level of compressibility decreases, there is little performance variation between record sizes
  

Again, the absolute performance varies for each test, but the trends are the same. But basically, the real-time data compression does not affect the read performance as much as it does the write performance.

Now that the throughput has been examined, the “performance twin”, IOPS is examine in this article. The same SandForce 1222 drive is tested using IOzone for the same three levels of data compressibility. Since it’s been a while since I’ve posted testing data with IOzone and IOPS, let’s start by reviewing.

IOzone and IOPS

IOzone is one of the most popular throughput benchmarks. It’s open-source and is written in very plain ANSI C (not an insult but a compliment). It is capable of single thread, multi-threaded, and multi-client testing. The basic concept of IOzone is to break up a file of a given size into records. Records are written or read, in some fashion until the file size is reached. While it is more commonly used for measuring throughput performance, it can also measure operations per second (IOPS – IO Operations Per Second). More specifically, it can be used to measure sequential read and write IOPS as well as random read and random write IOPS.

For this article, IOzone runs four specific tests and computes IOPS for each. The four tests are:

• Write
  This is a fairly simple test that simulates writing to a new file. Because of the need to create new metadata for the file, many times the writing of a new file can be slower than rewriting to an existing file. The file is written using records of a specific length (either specified by the user or chosen automatically by IOzone) until the total file length has been reached.

  
  

• Read
  This test reads an existing file. It reads the entire file, one record at a time.




• Random Read
  This test reads a file with the accesses being made to random locations within the file. The reads are done in record units until the total reads are the size of the file. The performance of this test is impacted by many factors including the OS cache(s), the number of disks and their configuration, disk seek latency, and disk cache among others.




• Random Write
  The random write test measures the performance when writing a file with the accesses being made to random locations with the file. The file is opened to the total file size and then the data is written in record sizes to random locations within the file.

For IOzone the system specifications are fairly important. In particular, the amount of system memory is important because this can have a large impact on the caching effects. If the problem sizes are small enough to fit into the system or file system cache (or at least partially), it can skew results, even for IOPS testing. Comparing the results of one system where the cache effects are fairly large to a system where cache effects are not large, is comparing the proverbial apples to oranges. For example, if you run the same problem size on a system with 1GB of memory versus a system with 8GB you will get much different results.

As with the throughput tests, the IOPS tests used a file size that is twice the size of memory. The goal is to push the file size out of what could be cached by Linux. However, the actual record size within the file is under control of the user so we can effectively prescribe the size of each IO operation when performing the IOPS testing.

For this article a total file size of 16GB was used. Within this 16GB file size, only one record size was used corresponding to the most common size used for testing IOPS – 4KB. The command line for this record size is,

./iozone -Rb spreadsheet_output_4K.wks -O -i 0 -i 1 -i 2 -e -+n -+w 98 -+y 98 -+C 98 -r 4K -s 16G > output_4K.txt

The options “-+w”, “-+y” and “-+C” define the how much “dedupability” there is in the data and buffers. In the above command lines “98″ means that the data can be deduplicated (compressed) 98%. Note that these options are only available with a later version of IOzone.

For this article I examine three levels of compression: (1) 98%, (2) 50%, and (3) 2%. The first level corresponds to data that is very compressible (98%). The last level corresponds to the data that is not very compressible (2%).

Test System

The tests were run on the same system as previous tests. The system highlights of the system are:

• CentOS 5.4 with a 2.6.32 kernel
  
• GigaByte MAA78GM-US2H motherboard
  
• An AMD Phenom II X4 920 CPU
  
• 8GB of memory (DDR2-800)
  
• The OS and boot drive are on an IBM DTLA-307020 (20GB drive at Ultra ATA/100)
  
• /home is on a Seagate ST1360827AS
  
• Micro Center SandForce 1222, 64GB SSD. This is mounted as /dev/sdd
  
• ext4 is used as the file system with the default options
  

Building ext4

For the tests in this article I used CentOS 5.4 but I used my own kernel – 2.6.32. I was using this kernel for other testing, so I decided to stick with it for these tests. Following my own advice from a previous article, I did not partition the drive and used the whole thing for the test. I used the default options when building and mounting the ext4 file system.

[root@test64 ~]# mke2fs -t ext4 /dev/sdd

Please note that building ext4 in this fashion puts the journal on the SSD as well.

Results

The results are plotted using bar charts to make them easier to compare. However, carefully examine the y-axis since the major and minor divisions are not the same for every graph. The plots are of the average values with error bars representing the standard deviation based on 10 runs of the same test. Each plot has three bars, one each corresponding to the level of data dedupability (compression) with a 4KB record size.

Figure 1 below is the Write IOPS test for the three levels of data compression with a 4KB record size. Please note that these are Sequential Write IOPS results.

Figure 1: Average Sequential Write IOPS (IO Operations Per Second) for the Three Data Compression Levels (Dedupability) for a 4KB Record Size

The first obvious trend that is noticed is that the Write IOPS performance drops off as the data compressibility decreases. At 98% compressibility the performance is about 50K Write IOPS but at 50% compressibility it is 24K Write IOPS, and at 2% compressibility it is about 18.4K Write IOPS. However, the drop in performance is much greater going from 98% compressibility to 50% compressibility than going from 50% compressibility to 2% compressibility.

Figure 2 below is the Read IOPS test for the three levels of data compression with a 4KB record size. Please note that these are Sequential Read IOPS results.

Figure 2: Average Sequential Read IOPS (IO Operations Per Second) for the Three Data Compression Levels (Dedupability) for a 4KB Record Size

As with the Write IOPS performance, the Read IOPS performance does decrease with decreasing compressibility, but the relative change in performance isn’t nearly as much as it is with Write IOPS. At 98% data compressibility, the Read IOPS performance is about 58.8K Read IOPS, at 50% data compressibility, the Read IOPS performance is about 52.4K Read IOPS, and at 2% data compressibility, the Read IOPS performance is about 47.1K Read IOPS. There is only about a 19.9% reduction in performance going from 98% data compressibility to 2% data compressibility.

Figure 3 below is the Random Write IOPS test for the three levels of data compression with a 4KB record size. Please note that these are Random Write IOPS results.

Figure 3: Average Random Write IOPS (IO Operations Per Second) for the Three Data Compression Levels (Dedupability) for a 4KB Record Size

As with the Write IOPS performance, the Random Write performance does decrease with decreasing compressibility but the overall performance Random Write IOPS performance is very good. At 98% data compressibility, the Random Write IOPS performance is about 36K IOPS, at 50% data compressibility, the Random Write IOPS performance is about 24.6K IOPS, and at 2% data compressibility, the Random Write IOPS performance is about 19.4K IOPS. From 98% to 2% there is a 46% decrease in Random Write performance.

Figure 4 below is the Random Read IOPS test for the three levels of data compression with a 4KB record size. Please note that these are Random Read IOPS results.

Figure 4: Average Random Read IOPS (IO Operations Per Second) for the Three Data Compression Levels (Dedupability) for a 4KB Record Size

As with the Read IOPS performance, the performance does decrease with decreasing compressibility, but the relative change in performance isn’t too much. At 98% data compressibility, the Random Read IOPS performance is about 7.1K IOPS, at 50% data compressibility, the Random Read IOPS performance is about 6.65K IOPS, and at 2% data compressibility, the Random Read IOPS performance is about 6.47K IOPS. There is only about a 8.9% reduction in performance going from 98% data compressibility to 2% data compressibility.

What is also interesting is to contrast Figures 4 and Figure 2. When going from sequential Read IOPS to Random Read IOPS, the performance decreases by almost an order of magnitude.

Summary

SandForce SSD controllers are very interesting because of their real-time data compression capability. This capability can improve performance and longevity but the key to the level of improvement is your data. If your data is compressible then you can get a performance boost as well as a longevity boost. But the question is how much is performance affected by the compressibility of the data.

In this article an initial examination of the IOPS performance of a consumer SSD with a SandForce 1222 controller was performed. In particular the write, read, random write, and random read IOPS performance was measured using IOzone which also allows the the data compressibility level to be defined.

Both the Write IOPS and Random Write IOPS results showed a fairly reasonable decrease in performance as the data became less compressible. The Write IOPS performance decreased by about 63% and the Random Write IOPS performance decreased by about 46% when going from 98% compressible data to 2% compressible data.

The Read IOPS and Random Read IOPS performance also decreases with decreasing data compressibility but the magnitude of the decreases is not nearly what is for write IOPS. The Read IOPS performance drops by about 19.9% and the Random Read IOPS performance drops by about 8.9% when going from 98% data compressibility to 2% data compressibility.

If you compare the Write IOPS performance (Figure 1) to the Random Write IOPS (Figure 3), you can see that the Sequential Write IOPS performance is better at 98% data compressibility and 50% data compressibility, but at 2% data compressibility, the random write performance is actually better than the sequential write. This is very interesting because usually random performance is worse than sequential performance.

The same examination of Read IOPS performance (Figure 2) and Random Read IOPS (Figure 4) is also interesting because the random performance is almost an order of magnitude smaller than the sequential performance.

As with the initial throughput results, the key observation you should take from these results is that the IOPS performance varies with the level of data compression. If the data is compressible then you will get pretty amazing performance from an inexpensive SSD and if your data is compressible as granite, then you may not get the best performance from a SandForce based SSD. The key question for you is how compressible is your data? This is very unique and interesting because this is the only storage media I know of, where the performance depends upon your data and how much it can be compressed.

In the next article I’ll compare the throughput performance of this SSD to and the Intel X-25E which is arguably one of the fastest enterprise level SSDs. It should be interesting, so stay tuned.

Appendix

This section contains the data from the plots in tabular form in case you need or want exact values from the figures.

The first table lists the results for the Sequential Write IOPS test. Table 1 below presents the Sequential Write IOPS (in IO Operations Per Second) for the three compressibility levels for the 4KB record size.

Table 1 – IOzone Write IOPS Performance Results with a File Size of 16GB, for all three levels of data compressibility for a record size of 4KB

Table 2 below presents the Sequential Read IOPS for the file systems for the three compressibility levels for the 4KB record size.

Table 2 – IOzone Sequential Read IOPS Performance Results for a File Size of 16GB, for all three levels of data compressibility for a record size of 4KB.

Table 3 below presents the Random Write IOPS for the file systems for the three compressibility levels for the 4KB record size.

Table 3 – IOzone Random Write IOPS Performance Results for a File Size of 16GB, for all three levels of data compressibility for a record size of 4KB.

Table 4 below presents the Random Read IOPS for the file systems for the three compressibility levels for the 4KB record size.

Table 4 – IOzone Random Read IOPS Performance Results for a File Size of 16GB, for all three levels of data compressibility for a record size of 4KB.