Got an SSD for performance and silence, but what about TRIM?
Posted: Wed Dec 29, 2010 6:07 am
Well, the holidays brought some better prices for SSDs, users seemed to multiply and so did my anticipation for a drive that would load applications faster and would not growl when navigating through consistently opening/closing 60+ Firefox tabs day in and day out, so I got myself a Corsair Force 60GB SSD to run on 780G/SB700 AMD platform...
These are my system specs (all relevant software is up to date: bios, firmware) :
Asrock A780GXE/128M, AM2 Athlon64 X2 5400+, 2x1GB DDR800 Geil, onboard ATI 3200, Corsair Force 60GB, WD1200JS-00MHB0, Enermax 485W, Win 7 Ultimate x64
User experience has gotten a lot better, partly because of Win7 x64 which also seems to handle FF memory leaks better.
However, I have been utterly disappointed by the performance degradation of the drive, within a couple of days of quite relaxed use and the ineffective or totally missing performance restoration by TRIM function.
In tests I've seen TRIM seems to be doing a great job getting the SSD back to shape...not in my case
I initially witnessed this with AMD AHCI driver, which remains a mystery - even taking into account AMD support responses - whether TRIM is supported by their drivers at all or supported only for the SB8** chipsets...
So I updated to firmware 2.0, secure erased the drive and did a clean Win7 installation while keeping the MS AHCI driver...after installing windows and a some applications I ran some bench tests (CrystalDiskMark in default setting is the only screenshot I've kept)
A couple of days later with some 8-9 small applications and MS Word installed, as well as browsing with many tabs open, I reran the tests...the performance had considerably degraded, 1/3 of the previous benchmark results in some write tests.
However, with ATTO and CrystalDiskMark run in 0x0 0Fill configuration, the decrease was not obvious (almost identical bench results comparing with the ones I had after first installing, no screenshots kept of those) :
So, I was/am puzzled...
...It seems the AMD drivers themselves were not at fault, as degradation was the same across the tests...but this degradation is visible only in CrystalDiskMark and As SSD Benchmark...
Although I had read that TRIM does not need the user to log off in order for it to work, I also did that...I logged off my user account for 8 hours and then I retested...the bench results actually got worse...this further complicates things, because if TRIM was not functioning, the drive's GC certainly should...but it didn't... Again, ATTO and CrystalDiskMark run in 0x00 0Fill setting do not exhibit performance degradation...
...So the question is complicated:
- Is this a bench unreliability thing and which benches are unreliable if they are in fact such? It would be simple if the benches of these same programs run in similar configuration were giving me such decreased results from the beginning...but performance has measured a drop between different runs of the same programs....so, is it, instead, that the particular benches measure performance in the way the others don't? Are the other benches or bench configurations "optimized", and so preferred by the manufacturing company as standards?
- Is TRIM functioning at all? It looks like it isn't...but then GC should be functioning...no results there either...
I must stress that all the relevant registry setting point to an enabled TRIM function...actually they point to a supported TRIM function, but actual functioning, it seems, can only be determined by use...and usage results are discouraging in that respect...
- Supposing that either TRIM or GC is in fact functioning, is such performance drop justified on the basis of 1) time elapsed between the secure erase/install and the point where the bench tools were rerun 2) the use of the computer during that time??
As far as I'm concerned, the facts concerning the above two questions are quite discouraging...two days passed, three series of benchmarks run (9 benches total), 10-12 programs installed (with Office being the only major one) plus all the windows updates, casual internet browsing (this for me includes lots of tabs, however)...and the result is 1/3 decrease in the performance in some write tests...
So what's your take on this?
These are my system specs (all relevant software is up to date: bios, firmware) :
Asrock A780GXE/128M, AM2 Athlon64 X2 5400+, 2x1GB DDR800 Geil, onboard ATI 3200, Corsair Force 60GB, WD1200JS-00MHB0, Enermax 485W, Win 7 Ultimate x64
User experience has gotten a lot better, partly because of Win7 x64 which also seems to handle FF memory leaks better.
However, I have been utterly disappointed by the performance degradation of the drive, within a couple of days of quite relaxed use and the ineffective or totally missing performance restoration by TRIM function.
In tests I've seen TRIM seems to be doing a great job getting the SSD back to shape...not in my case
I initially witnessed this with AMD AHCI driver, which remains a mystery - even taking into account AMD support responses - whether TRIM is supported by their drivers at all or supported only for the SB8** chipsets...
So I updated to firmware 2.0, secure erased the drive and did a clean Win7 installation while keeping the MS AHCI driver...after installing windows and a some applications I ran some bench tests (CrystalDiskMark in default setting is the only screenshot I've kept)
A couple of days later with some 8-9 small applications and MS Word installed, as well as browsing with many tabs open, I reran the tests...the performance had considerably degraded, 1/3 of the previous benchmark results in some write tests.
However, with ATTO and CrystalDiskMark run in 0x0 0Fill configuration, the decrease was not obvious (almost identical bench results comparing with the ones I had after first installing, no screenshots kept of those) :
So, I was/am puzzled...
...It seems the AMD drivers themselves were not at fault, as degradation was the same across the tests...but this degradation is visible only in CrystalDiskMark and As SSD Benchmark...
Although I had read that TRIM does not need the user to log off in order for it to work, I also did that...I logged off my user account for 8 hours and then I retested...the bench results actually got worse...this further complicates things, because if TRIM was not functioning, the drive's GC certainly should...but it didn't... Again, ATTO and CrystalDiskMark run in 0x00 0Fill setting do not exhibit performance degradation...
...So the question is complicated:
- Is this a bench unreliability thing and which benches are unreliable if they are in fact such? It would be simple if the benches of these same programs run in similar configuration were giving me such decreased results from the beginning...but performance has measured a drop between different runs of the same programs....so, is it, instead, that the particular benches measure performance in the way the others don't? Are the other benches or bench configurations "optimized", and so preferred by the manufacturing company as standards?
- Is TRIM functioning at all? It looks like it isn't...but then GC should be functioning...no results there either...
I must stress that all the relevant registry setting point to an enabled TRIM function...actually they point to a supported TRIM function, but actual functioning, it seems, can only be determined by use...and usage results are discouraging in that respect...
- Supposing that either TRIM or GC is in fact functioning, is such performance drop justified on the basis of 1) time elapsed between the secure erase/install and the point where the bench tools were rerun 2) the use of the computer during that time??
As far as I'm concerned, the facts concerning the above two questions are quite discouraging...two days passed, three series of benchmarks run (9 benches total), 10-12 programs installed (with Office being the only major one) plus all the windows updates, casual internet browsing (this for me includes lots of tabs, however)...and the result is 1/3 decrease in the performance in some write tests...
So what's your take on this?