SandForce TRIM Issue & Corsair Force Series GS (240GB) Review
by Kristian Vättö on November 22, 2012 1:00 PM ESTBut How About Incompressible Data and TRIM?
I mentioned earlier that TRIM has never functioned properly in SandForce SSDs when the drive is tortured with incompressible datam, which has never been a strength of SandForce. When it faces some, it's not exactly sure what to do with it. Your data will of course be written just like compressible data, but when your whole design is based on the assumption that the data will be compressed on the fly, there are some design trade-offs when it comes to performance with incompressible data. SandForce has said that third generation controllers should bring vast improvements to incompressible performance but we have no concrete numbers as of yet.
To test how TRIM behaves with incompressible data, I filled the Force GS with incompressible data and then tortured it with incompressible 4KB random writes (100% LBA space, QD=32) for 60 minutes:
| Corsair Force GS—Resiliency—AS SSD—6Gbps | ||||
| Read Speed | Write Speed | |||
| Firmware | 5.0.2 | 5.0.3 | 5.0.2 | 5.0.3 |
| Clean | 494.1MB/s | 507.6MB/s | 270.5MB/s | 266.8MB/s |
| After Torture | 372.3MB/s | 501.1MB/s | 74.9MB/s | 156.2MB/s |
| After TRIM | 479.8MB/s | 506.0MB/s | 220.2MB/s | 150.3MB/s |
With firmware 5.0.2, both read and write speed degrade when tortured. The read speed doesn't degrade as much as write speed, but there is still a clear drop in performance. Fortunately TRIM will mostly restore read performance so there doesn't seem to be a similar problem as with compressible data. Write performance, on the other hand, restores but not fully. After TRIM write performance is about 81% of clean state performance, which isn't bad but not ideal either.
Firmware 5.0.3 seems to bring some changes to how incompressible data is dealt with. TRIM still doesn't work properly but as I've said before, I believe it's the way how the controller and firmware were designed, meaning that there isn't really a way to fix it. The good news is that write speed doesn't degrade nearly as much after torture as it did with firmware 5.0.2. Read speed also stays on-par with clean state performance. On the other hand, TRIM doesn't restore performance at all. As a matter of fact TRIM actually degrades write speed slightly but the difference is small enough to not raise any real concern. We did experience similar behavior with HD Tach, though.
Conclusion
SSD performance is all about trade-offs. As you improve one area, you generally weaken another. For example, you can opt for a large logical block size and get super fast sequential write speeds. The flip side is that random write speed will be horrible. Another good example is SandForce. They have chosen to concentrate on performance with compressible data, which has resulted in a trade-off with incompressible data performance.
Since it's generally impossible to have everything in one package, creating a good firmware and SSD is all about finding the balance. SandForce's approach in firmware 5.0.3 is in the right direction but it's far from perfect. TRIM now restores read speed after torture but in exchange, write speed takes a hit. I'm more satisfied with this behavior because the degradation in write speed is smaller and it seems that sequential writes and idle time will help to restore performance back to clean state. With firmware 5.0.2, read speed degraded for good; TRIMing the drive again and running HD Tach for several times didn't show any improvement.
What I'm more worried about is the TRIM behavior with incompressible data. With 5.0.2, TRIM at least worked somewhat as performance was better after TRIM than after torture. Sure, write speed doesn't go as low as it did with 5.0.2 but since most SSDs are used in TRIM-supported environments, I would rather take worse worst-case performance and partially working TRIM.
Hopefully SandForce will be able to find the right balance in a future firmware, which would be working TRIM regardless of the nature of data. 5.0.3 is a good start, but I feel that it concentrates too much on fixing one problem and as a result creates a bunch of new ones.
Facebook
Twitter
RSS
56 Comments
View All Comments
Kristian Vättö - Friday, November 23, 2012 - link
That is correct, Storage bench tests are run on a drive without a partition.Running tests on a drive with a partition vs without a partition is something I've discussed with other storage editors quite a bit and there isn't really an optimal way to test things. We prefer to test without a partition because that is the only way we can ensure that the OS doesn't cause any additional anomalies but that means the drive may behave slightly differently with a file system than what you see in our tests.
JellyRoll - Friday, November 23, 2012 - link
Well personally I think that testing devices that are designed to operate in a certain environment is important. You are testing SSDs that are designed for a filesystem and TRIM, without a filesystem and TRIM. This means that the traces that you are running aren't indicative of real performance at all, the drives are functioning without the benefit of their most important aspect, TRIM. This explains why Anandtech is just now reporting the lack of TRIM support when other sites have been reporting this for months.Testing in an unrealistic environment with different datasets than those that are actually used when recording (your tools do not use the actual data, it uses substituted data that is highly compressible), in a TRIM free environment is like testing a Formula One car in a school zone.
This is the problem with proprietary traces. Readers have absolutely no idea if these results are valid, and surprise, they are not!
extide - Saturday, November 24, 2012 - link
The drive has NO IDEA id there is a partition on it or not. All the drive has to do is store data at a bunch of different addresses. That's it. Whether there is a partition or not has no difference, it's all just 0's and 1's to the drive.JellyRoll - Saturday, November 24, 2012 - link
it IS all ones and zeros my friend, but TRIM is a command issued by the Operating System. NOT the drive. This is why XP does not support TRIM for instance, and several older operating systems also do not support it. That is merely because they do not issue the TRIM command. The OS issues the TRIM commands, but only as a function of the file system that is managing it. :)No file system=no TRIM.
JellyRoll - Saturday, November 24, 2012 - link
exceprts from the defiition of TRIM from WIKI:Because of the way that file systems typically handle delete operations, storage media (SSDs, but also traditional hard drives) generally do not know which sectors/pages are truly in use and which can be considered free space.
Since a common SSD has no access to the file system structures, including the list of unused clusters, the storage medium remains unaware that the blocks have become available.
popej - Friday, November 23, 2012 - link
Different drives, different algorithms and different results. But since you are testing drive well outside normal use you should draw conclusion with care, not all could be relevant to standard application.R3dox - Friday, November 23, 2012 - link
I've read everything (afaik) on AT on SSDs the past few years and the powersaving features used to be disabled in reviews. They, at least at some point, significantly affect performance. Back then I bought an Intel 80GB postville SSD and all tests I ran confirmed that these settings have quite a big impact.I currently have an Intel 520 (though sadly limited by a 3Gbps SATA controller on my old core i7 920 platform) and I never thought of turning everything on again, so I wonder whether the problem is solved with newer drives. Did I miss something or why aren't these settings disabled anymore? Hopefully it's not a feature of newer platforms.
It would be nice if the next big SSD piece would cover this (or feel free to point me to an older one that does :)). I'd really like this to be clarified, if possible.
Bullwinkle J Moose - Friday, November 23, 2012 - link
I was kinda wondering something similarAHCI might give you a sleight performance boost, but does it affect the "Consistency" of the test results having NCQ enabled or the power saving features of AHCI or the O.S. itself
I always test my SSD's in the worst case scenario's to find bottom
XP
No Trim (Not even O&O Defrag Pro's manual Trim)
Heavy Defragging to test reliability while still under return policy
yank the drives power while running
Stuff like that
I predicted that my Vertex 2 would die if I ever updated the firmware as I have been tellyng people for the past few years and YES, it finally Died right after the firmware update
It was still under warranty but I seriously do not want another one
Time for me to thrash a Samsung 256GB 840 pro
I feel sorry for it already
Sniff
Bullwinkle J Moose - Friday, November 23, 2012 - link
I forgotMisaligned partitions and firmware updates during the return policy will also be used for testing any of my new drives during the return policy
I don't trust my data to a drive I haven't tested in a worst case scenario
Kristian Vättö - Friday, November 23, 2012 - link
EIST and Turbo were disabled when we ran our tests on a Nehalem based platform (that was before AnandTech Storage Bench 2011) but have been enabled since that. Some of our older SSD reviews have a typo in the table which shows that those would be disabled in our current setup as well, but that's because Anand forget to remove those lines when updating the spec table for our Sandy Bridge build.