But 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.

Firmware 5.0.3 to the Rescue The Corsair Force GS
Comments Locked

56 Comments

View All Comments

  • R3dox - Friday, November 23, 2012 - link

    I see, but that doesn't really answer my question :P.

    Is there still a performance hit and do you just choose to test under normal rather than optimal conditions or is this a thing of the past?
  • Kristian Vättö - Friday, November 23, 2012 - link

    I tested this quickly a while back but there was no significant difference in performance (small variation always occurs anyway):

    http://forums.anandtech.com/showthread.php?t=22721...
  • R3dox - Friday, November 23, 2012 - link

    Thanks for the replies :).

    You say "AFAIK it affected performance with some older SandForce SSDs but when I started testing SSD and asked Anand for all the settings, he just told me to leave it on since it doesn't matter anymore".

    But it's a clear difference on my old postville. Granted, the SSD is my boot disc during those tests, but isn't that their most likely use anyway? TBH I'd be interested to know why enabling those powersaving features apparently impact performance only when used as boot disc. When I say 'impact", I mean based on multiple runs, of course.

    Lastly, it seems that C-states are the most impactful setting and that one isn't mentioned in the reviews. I suppose you've left those on as well?
  • JellyRoll - Wednesday, December 5, 2012 - link

    that wasnt testing.
  • Schugy - Tuesday, November 27, 2012 - link

    Don/t buy MLC rubbish. SLC is really worth it.
  • FunnyTrace - Wednesday, November 28, 2012 - link

    Nice going SandForce.

    1) BSOD problem
    2) AES-256 hardware doesn't work (seriously??? hardware doesn't work???)
    3) TRIM has not been working properly (what, you failed to GC blocks properly?)

    As a lot of people mention, these SSD makers want to use early adopters and PC building enthusiasts as guinea pigs.

Log in

Don't have an account? Sign up now