Table of Contents
Introduction
Solid state discs are amazingly fast compared to their more traditional platter counterparts, but historically have stayed out of mainstream use due to the steep pricing of the drives. However, over the last few years pricing has dropped to the point where even budget-oriented customers are considering purchasing smaller SSDs for their OS and programs. While SSDs are great, we keep hearing over and over on the web that people are getting lower performance than they expected based on the manufacturer's advertised performance numbers.
If you have ever used anything that has an advertised speed (from wireless to USB to even cars), you know that you will almost never attain that advertised speed in the real world. We have touched on the difference between advertised and actual performance in regards to wireless in our Introduction to PC Wireless article, but SSDs also have this issue. The advertised read performance is generally pretty close to what you will see in the real world, but for write performance there are two major factors that will likely prevent you from seeing the advertised write speeds. The first is the type of data that the manufacturers use to benchmark their drives and the second is the fact that SSD performance degrades somewhat over time. Additionally, your system also needs to support the features that help improve performance such as SATA 6Gb/s ports (if the SSD is capable of SATA 6Gb/s speeds) and TRIM if you want to achieve the best possible speeds. The one thing you do not need to worry about, however, is using a so-called SATA 6Gb/s cable. These cables are all marketing, and we have shown that they have no performance benefit over so-called SATA 3Gb/s cables as long as you are using high quality cables.
So before we go through our benchmark results, let's first go through why data type and the age of the drive affects write performance.
Compressible vs. Incompressible Data
One of the biggest reasons why a user will not see an SSD's advertised speed when copying files or running their own benchmarks is that the data they are using is typically what is called incompressible data. There is nothing wrong with this type of data, but most manufacturers use highly compressible data for their benchmarks since most modern SSDs are better at writing highly compressible data than incompressible data. This is due to the fact that the controllers found on most modern SSDs use lossless compression to speed up write performance. Basically, it makes compressible data write much faster, but provides little benefit for incompressible data.
What does this mean in terms of real-world performance? The answer is a bit complex since it depends entirely on the data you are working with. If the SSD is being used to store compressible data (i.e. an OS and programs) you will see write performance pretty close to the advertised speeds. If it is being used for incompressible data (i.e. movies, pictures or music) you will likely see much lower write performance than what is advertised. Note that the data type will affect write performance, but should only slightly affect the read performance. So if you are just reading data (loading a program, opening a document, etc.) the data type should not matter as much as if you are writing data (copying a file, saving a document, etc.)
If you are unsure whether the data you are working with is compressible or incompressible, an easy way to find out is to send a sample of that data to a zip file and compare the size of the original data to the size of the zip file. If the file size does not change much, you have incompressible data. If the file size is much lower, then you have compressible data. As an example, here are some common data types both before and after being sent to a zip file:
Out of all these data types, the only one that is highly compressible is the application which compresses to roughly a third of its original size. The others only compress a small amount so they would be considered incompressible data. So, if you are writing directly to an application, you will likely see performance close to the advertised speeds, but if you are writing a common data file you will likely see lower performance. This is just an example using random data taken from our test machine, so we recommend doing this test on your own data to see for yourself what type of data you are working with.
We will be testing to see exactly how big a difference this makes in a later section, but let's first go over why the write performance of an SSD will typically go down a bit after you have used the drive for a while.
Performance Degradation Over Time
Another major factor that determines your drive's write performance stems from how solid state disks actually write new data. Contrary to what many people believe, when you delete a file on a SSD it does not actually get removed from the drive. It simply gets marked as being OK to write over, and the next time data needs to be written to that section of the SSD the controller will simply write over the old data.
The issue is that if there is not enough space where the controller wants to write the new data, the controller has to shuffle around the existing data on the drive to make space. So the SSD controller has to do additional work (both reading the existing data, and writing both the new and existing data back to the drive) which results in lower performance. SSDs have some technology to help combat this (most notably TRIM) but this only alleviates the problem and does not entirely resolve it.
This is a vastly simplified version of what is actually happening and we recommend reading either the How does an SSD write? article from Future Storage or AnandTech's Understanding SSDs Performance Degradation Problem article if you want a more detailed picture. Again, this applies mostly to write performance, and should have no effect on read performance.
Testing Hardware
For our test hardware, we will be using the following components:
|
|
||||||||||||||||
We will be using an Intel 520 120GB SSD which has an advertised sequential read speed of 550 MB/s and a sequential write speed of 500 MB/s. We are only going to be testing a single Intel SSD, so keep in mind that our results are meant to be more of an example and not an exact indication of what performance you will see in your own system. The SSD was configured as a secondary storage drive and we installed both the Intel RST and the Intel SSD Toolbox software. Lastly, between benchmark sets we performed a secure erase on the drive so that previous benchmark runs would not affect the results.
To benchmark the SSD, we used CrystalDiskMark which is our go-to hard drive benchmark here at Puget Systems. It is consistent, reliable, and allows us to customize many different settings from the size and type of data used to the number of passes for each benchmark run. Each time CrystalDiskMark runs, it writes about 9.2GB of data to the drive, so by looping the benchmark and recording the results for each run we can plot the speed of the drive compared to how much total data has been written to the drive.
We left the benchmark to loop until it had written a total of approximately 1.8TB worth of data, which essentially filled the drive about 15 times. We also ran our benchmarks multiple times with the data type set to both Random (incompressible) data and All 0x00 (compressible) data to see how much of an effect data type actually has on performance.
Read Performance
| Over Time Performance Graphs | |
|
|
|
| Maximum/Average Performance Charts | |
|
|
|
Intel advertises a sequential read performance of 550 MB/s, which is close to our compressible data results. The 35 MB/s (or roughly 7%) difference is small enough to be attributed to the slight variations between CrystalDiskMark and the benchmark program that Intel uses.
What is interesting is that both the peak and average read performance for incompressible data is slightly lower than the compressible data. It isn't much, but we expected there to be virtually no difference at all so it was a bit of a surprise. Also, the difference between the maximum and average performance is very minimal which indicates that the read performance of this drive is very consistent. And finally, the performance did not drop much even after a ton of data had been written to the drive.
So for read performance, the data type makes a small difference (around 5%) and there is little to no loss in performance over time.
Write Performance
| Over Time Performance Graphs | |
|
|
|
| Maximum/Average Performance Charts | |
|
|
|
While the read benchmarks were pretty boring, we get some really interesting data with the write benchmarks. Intel advertises a sequential write performance of 500 MB/s, which we saw almost exactly with the compressible data. With incompressible data, however, we only saw a maximum of 193.3 MB/s, or about 38% of the advertised speed. This is a huge difference and likely the biggest reasons why users sometimes think that their drive is not performing at full speed.
We can also clearly see the difference in compressible and incompressible data over time. Compressible data only has a minor performance loss, but – with the exception of the random write 2KB (QD=1) test – incompressible data has a very large change in performance at two key points. The first is after about 40GB of data had been written to the drive which is when the random 512KB and random 4KB (QD=32) performance drops to about 160MB/s. Oddly, sequential write performance goes a bit crazy at this point, jumping between 100 and 160 MB/s.
The second point is after about 380GB of data (roughly 4x the total drive size) had been written to the drive which is when things started to level off and become consistent. Because of this, this point is where we started to calculate our average write performance numbers in the chart above.
So, compressible data gives you great performance and even achieves the manufacturer's advertised speed without any major performance degradation over time. Incompressible data (which again is things like music, movies, pictures and most data files) doesn't get anywhere close to the advertised speed and has a significant drop in performance over time. At the fastest, we saw speeds that were only about 38% of the advertised speed which dropped to about 32% of the advertised speed after the drive had been heavily used.
TRIM vs. No TRIM
All of our benchmarks so far have been performed with TRIM enabled, but since not all systems have automatic TRIM support (most commonly those running Windows XP) we thought we would show exactly how much of a benefit TRIM provides. Note that on a system that supports TRIM, the process should be automatic so there is nothing you need to do to enable it. If you want to double check that TRIM is running, however, simply type "fsutil behavior query disabledeletenotify" into an elevated command prompt. If it comes back with 0, then TRIM is enabled. If it comes back with 1, then TRIM is disabled.
If you want to manually enable/disable TRIM, the command is very similar. Just type "fsutil behavior set disabledeletenotify X" into an elevated command prompt where X is either 0 to enable TRIM or 1 to disable TRIM.
We decided to benchmark with incompressible data only since that is the type of data that showed the biggest fluctuations in our previous benchmarks and is also the most likely type of data that the average user will write to an SSD. To analyze our results, we decided to separate each test into its own graph and turn up the scale a bit to get a closer look at the differences.
| Over Time Performance Graphs | |
|
|
|
|
|
|
| Maximum/Average Performance Charts | |
|
|
|
Frankly, we expected TRIM to do a bit more than what our results show. It definitely makes a difference, but only by about 2-4%. We see no reason to turn it off, but at the same time it doesn't appear to be critically important; at least on the model of SSD we used for testing. Solid state drives have come a long way since TRIM was introduced, so we wouldn't be surprised if there was some other unknown type of garbage collecting going on with this drive that was based solely on the controller. Unfortunately, that type of information is usually very confidential and is not something we are likely to be able to test anytime soon.
Conclusion
From our testing, we can come to a few conclusions. First, while the read performance of an SSD is not nearly as volatile as the write performance, the type of data you are using makes a huge difference in the write performance of a SSD. This may not be as important for older drives or those that do not use lossless compression, but it makes a big difference in drives that do. Next, if you are using incompressible data, expect to see a 20-30% decrease in write performance after you have written a little bit of data to the drive, and another decrease in performance after you have written roughly four times the drive's total capacity worth of data. Lastly, TRIM helps, but not by as much as we expected.
As for the question of whether you should expect to see the advertised speed on an SSD when using it in a real world situation, the answer is mostly no. Read performance should be pretty close to the advertised speed no matter that type of data you are using, but write performance will likely be much, much lower than advertised. Especially when you consider that most of the data that is written to a drive (though either saving or copying files) is incompressible data, the actual performance you should expect to see is only about 32-28% of the advertised write speed depending on how much the drive has been used. This is still very, very fast and a huge improvement over traditional platter drives, but not quite as fast as manufacturers advertise.
If you are at the point where your SSD's write performance is starting to degrade and you want to get it back to peak performance, the one surefire way to do so is to perform a secure erase on the drive which is available through the Intel SSD Toolbox. This wipes the drive so make sure you backup your data first! Simply remove the drive's partition, load the SSD Toolbox, click the Secure Erase button and follow the instructions. Think of this as a reset button that reverts the drive back to its original state.
While we would love to see manufacturer specifications that include speeds for both compressible and incompressible data, the problem is that even if a manufacturer wanted to do so, it would likely only result in confusing for the majority of consumers. Also, most consumers simply equate bigger numbers to better performance so no manufacturer wants to advertise smaller performance numbers, even if they are more realistic. However, advertising only compressible data performance (without even a caveat about the type of data being used) often results in unhappy customers which is also something that no company wants. Some manufacturers (such as OCZ) do show how they benchmark their drives, but this information is usually incomplete or buried in whitepapers.
For us at Puget Systems, The biggest thing we can do is educate our customers so they better understands the variances in SSD performance. However, we do have relationships with a few SSD manufactures that allows us to give them feedback about their products – including their marketing tactics. Unfortunately, we do not know what the solution is, so we are going to put the question to you, the reader. If you were suddenly in charge of Intel/OCZ/Kingston/Samsung/etc, and had the ability to change how SSD performance is advertised, how would you do so? Let us know in the comments below.