Firmware 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:

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:

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.

Introduction to the TRIM Issue But How About Incompressible Data and TRIM?
Comments Locked

56 Comments

View All Comments

  • JellyRoll - Saturday, November 24, 2012 - link

    Entertaining that you would link to thessdreview, which is pretty much unanimously known as the home of misinformation. Here is a link to the actual slide deck from that presentation, which does not ever mention deduplication.
    http://www.flashmemorysummit.com/English/Collatera...
  • CeriseCogburn - Saturday, December 29, 2012 - link

    LOL - good job, I will continue to read and see if all the "smart" people have finally shut the H up.
    I was hoping one would come by, apologize, and thank you.
    Of course I know better.
    *Happy the consensus is NOT the final word.*
  • dishayu - Friday, November 23, 2012 - link

    Get Kristian on to the next episode of the podcast and make him talk!!
  • popej - Friday, November 23, 2012 - link

    What exactly does it mean: "I TRIM'ed the drive after our 20 minute torture"?

    Shouldn't TRIM function be executed by OS all the time during torture test?
  • Kristian Vättö - Friday, November 23, 2012 - link

    Most of our tests are run without a partition, meaning that the OS has no access to the drive. After the torture, I created a partition which formats the drive and then deleted it. Formatting the drive is the same as TRIMing all user-accessible LBAs since it basically tells the controller to get rid of all data in the drive.
  • popej - Friday, November 23, 2012 - link

    Does it mean, that there was no TRIM command executed at all?

    Not when torturing drive, because it wasn't TRIM supported partition. Not when you "TRIM'ed" drive, because it was a format.

    While I agree that you can notice some weird effects, why do you describe them as TRIM problems? Sorry, but I don't know how your test could be relevant to standard use of SDD, when TRIM is active all the time.
  • Kristian Vättö - Friday, November 23, 2012 - link

    Formatting is the same as issuing a TRIM command to the whole drive. If I disable TRIM and format the drive, its performance won't restore since the drive still thinks the data is in use and hence you'll have to do read-modify-write when writing to the drive.

    They are problems in the sense that the performance should fully restore after formatting. If it doesn't, then TRIM does not function properly. Using an extreme scenario like we do it the best for checking if there is a problem; how that affects real world usage is another question. With light usage there shouldn't be a problem but you may notice the degradation in performance if your usage is write intensive.
  • popej - Friday, November 23, 2012 - link

    Basing on you test I would say, that format is not enough to restore drive performance after using it without TRIM. Quite possible that the state of the drive after torture without TRIM is very different to anything you can get when TRIM is active.

    It would be interesting to compare your test to real life scenario, with NTFS partition and working TRIM.
  • Kristian Vättö - Friday, November 23, 2012 - link

    With most SSDs, formatting the drive will fully restore it's performance, so the behavior we're seeing here is not completely normal.

    Remember that even if TRIM is active at all times, sending a TRIM command to the controller does not mean the data will be erased immediately. If you're constantly writing to the SSD, the controller may not have time to do garbage collection in real time and hence the SSD may be pushed to a very fragmented state as in our test where, as we can see, TRIM doesn't work perfectly.

    I know that our test may not translate to real world in most cases, but it's still a possible scenario if the drive is hammered enough.
  • JellyRoll - Friday, November 23, 2012 - link

    If the majority of your tests are conducted without a partition that means none of the storage bench results are with TRIM?

Log in

Don't have an account? Sign up now