SandForce TRIM Issue & Corsair Force Series GS (240GB) Review
by Kristian Vättö on November 22, 2012 1:00 PM ESTFirmware 5.0.3 to the Rescue
As SandForce was well aware of the issue with TRIM, it allowed them to work on a new firmware with working TRIM before the issue gained much visibility. The new firmware carries a version number 5.0.3, although manufacturers may rename the update to correspond with their one firmware naming schemes. Availability of the update depends totally on the manufacturer as all have their own validation processes, but so far I've seen at least Corsair, Kingston and SanDisk offering the updated firmware for their drives. Again, I would like to point out that not all SF-2281 based SSDs are affected; there are plenty still using the older 3.x.x firmware with working TRIM.
To test if TRIM finally works, I'm using the same methods as in the previous page. Here's what performance looks like after 20 minutes of torturing:
.PNG)
There are no essential differences from the 5.0.2 firmware. Read speed still degrades but like I said, this is most likely how the controller and firmware were designed, meaning that there isn't really a way to fix it.
Next I TRIM'ed the drive:
Read speed is mostly restored, though not fully, but TRIM is definitely working better than it was in 5.0.2 and earlier. It's actually normal that performance after TRIM is a few percent shy of clean performance, so the behavior we are seeing here is fairly common. However, we now have a new quirk: Write speed degradation. As you can see in the first graph, write speed after torture was 398MB/s. After TRIMing the drive, the average write speeds drops to ~382MB/s. Generally the write speed is around 400MB/s but there are at least two dozen peaks where performance drops to as low as ~175MB/s.
I TRIMed the drive again to see if there would be any improvement:
.PNG)
And there is ~9MB/s improvement in average write speed. Write speeds still drops below 200MB/s on several occasions but in total the amount of negative peaks is a lot smaller. With more sequential writes and idle time, write speed should restore to close to clean state performance.
I also ran ATTO to see if it would replicate our HD Tach results:
Read speed is restored after TRIM, which is what our HD Tach tests showed as well.
When tested with ATTO, write speed doesn't actually degrade aside from the transfer size of 32KB, though similar behavior happens with the 5.0.2 firmware. The above graph can be a bit hard to read because the lines are crossing each other, so I double-checked the results by looking at the raw numbers reported by ATTO and there were no major differences. Again, keep in mind that ATTO doesn't write anywhere near as much data as HD Tach does. Aside from the peaks, performance with HD Tach was similar to clean-state, so it's possible that ATTO doesn't write enough to show the peaks as well.
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.