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?

If you lost 1/3 of write performance, it's not the end of the world. You still have a random write performance no hard drive can get close to and a decent sequential write performance.

You have a Sandforce drive which uses compression internally. Testing and benchmarking programs which do not use the kind of data you want to test performance for (be it random data, text or whatever) will not show you a true picture of performance. How fast a program can write zeroes to your drive is utterly irrelevant. No testing program will show you what your user experience will be of course but at least it should dump some objective numbers... but that's not so easy with SandForce drives.

TRIM isn't supposed to be 100% effective in all cases. Some drives need it badly and some don't but I would generally not expect as-new performance from a used SSD, especially if a lot of the space is used.
One of the reasons I do not care for SandForce drives is that I fear performance could degrade badly if the drive was filled with random data. But I have no idea if that's actually the case. The idiosyncrasies of SSD controllers are poorly understood.

If TRIM doesn't work for some reason (it may be that your drivers do not support the instructions as you suspect), I would think overwriting the empty space should improve the performance of a SandForce drive due to the compression. But prehaps the controller is not using compression like I expect it to. Our resident SSD expert dhanson865 may know the actual facts of the matter. If not, she should at least be able to let you know if there is a utility available for your drive that's supposed to improve performance regardless of your drivers.

For your Firefox problems, try Opera. I have no problems with having many tabs open on puny hardware. Opening the program is slow if you want it to open dozens of tabs automatically and you only need a good amount of RAM (like 400M or so just for the browser) but otherwise it runs fairly well (I noticed an odd performance problem with the full-screen mode when you have a lot of tabs open). Caveat: I don't use Flash so I don't know if Flash is a source of performance issues.

For starters, thanks a lot for your answer...


I have, it's actually quite good...firefox 4 beta also seems to be modeling itself according to Opera 11.
However, Opera might just be the browser with the worst performance of the bunch pertaining to the display of webpages...since I have taken up building and maintaining joomla site recently, I have come to greatly value performance in that field...Opera is even behind IE in that respect...
The extensions available for Opera are also quite few...of course this is not a problem per se, since I will only be needing/using half a dozen of them, but their performance is also suffering, AdBlock effectiveness being an example.
In WinXP at least, Opera can become quite heavy when many tabs are open, in contrast to Firefox which seems to consume increasing resources and respond slowly when the browser is left open for some time...pages with flash also seem to burden Opera significantly...
I do like the fact that Opera can copy non-latin URLs as they display instead of turning them into that endless line of characters, but there is also a problem there...mainly, forum software like phpbb3 does not like that and does not recognize the full path as a url when non-latin characters are included.

Also, Firefox runs much, much better in Win7 than in WinXP...with dozens of tabs open for about two days, memory consumption has not risen above 380mb...in WinXP I would easily get about 1gb of memory consumption...so it's not that much of a problem now...
Also, because Firefox caches so much, it can be painful when the drive on which cache is stored is a HDD - severely impacting the performance of multiple tasks - but with SSD, I don't get either the delay or the noise...this is probably one of my reasons for getting an SSD...as far as this is concerned, the purchase was not a mistaken one.


Well I wasn't expecting 100% effectiveness...the matter is, right now there is 0% effectiveness..literally...
To be more precise, I have no "general" worries about general degradation of performance...I knew the limits before I purchased the drive...
...my concerns are specific to the degradation noticed within the specified period, a very short one of just two days and less, and considering the quite light usage of the drive in the meantime...
...that's why I am particularly concerned, and that's why I believe that valid general references to the software/hardware technology do not adequately answer these particular and specific concerns...
If the drive was running on IDE with the built-in GC, then I might not consider it that much...but the thing is the degradation has been very swift and much too great and TRIM restoration (or GC restoration for that matter, since the system was logged off for 8hours) has been at a measured 0%...

Some controllers do seem to have preferences and at the Corsair forum they seem to be pushing for intel chipsets...don't really have the luxury to built the ideal set of hardware just to make the SSD look good, though...


I have indications that TRIM might not work (even that it might not have been designed to work for my chipset) with AMD Ahci, but it's not even working with MS Ahci...and these drivers should actually work...Why they don't, I really have no idea...
I don't think there is a tool for the drive...I know OCZ has their own for a similar SSD...


Well 1/3 of performance decrease is not that easy to "swallow" given the specificities of the case...
But I have considered that performance can still be much higher than HDDs, that synthetic benchmarks might actually be more confusing and disorienting than useful (one does have to pick the ones to ignore, however) and I could enjoy the advantages of the technology that are in fact experienced...
This is a valid argument both generally and specifically...I just need to sort out what practical improvements are possible with regard to the advantages that I should be enjoying...

OK, let's look at specifics. This is how the performance of a modern premium SSD can degrade:
http://www.anandtech.com/show/3812/the- ... ssd-c300/8
20 minutes of random writes and sequential write performance drops by over 85%! Obviously that's a problem with that controller. But that's the context in which I say that a performance loss of 33% isn't that big of a deal. Sure, if it keeps dropping at this rate, you have a problem. But we don't know that.

It's not clear you actually have a 33% performance loss. How does your test work? Does it apply to actual performance? I don't know. Some tests do not show any performance degradation and some do. That tells us that compression interacts with performance degradation and that we need to make sure we're not comparing apples and oranges before jumping to conclusions. In the link above, a SandForce drive's performance appears solid under use but I suspect the result might be bogus (like your "0Fill" test).
And it's not clear that TRIM doesn't work. Why do you say the effectiveness is 0%? What you have noticed is that idle garbage collection over 8 hours doesn't change the picture. But we don't know that it's supposed to: garbage collection might be supposed to recover from states in which performance is worse.
Specifically: can someone confirm that their used SandForce drive has a better performance than yours when performing the same tests? Or could you run the same tests as someone else and compare? It's pointless to worry about your chipset, drivers, whether TRIM works and so on if the performance degradation you get is normal. Even then, the difference might come down to the firmware or the version of the controller. I understand OCZ has distributed different SandForce firmwares or something.

Finally, there's the possibility that your write tests and not your normal use of the SSD degraded the performance. Writing is what degrades performance and you can't test for the performance degradation you suspect without writing which is a bit of a conundrum.
Then again I suspect filling much of the drive and then using it for heavy browsing cache could also degrade the performance somewhat.

That test, I believe, is much more hard a task than what I have given the drive to work with...I did run another CrystalDiskMark bench and the performance did drop a little more on some tests, while others showed a little better results...I'm not arguing that this is a work in progressive degradation...it was run minutes after another test, so that could have affected it...but it does seem like it is getting worse, albeit not in that pace, i.e. 1/3 decrease with regard to the initially measured performance every couple of days...
Actually, As SSD benchmark did measure a 60mb/s drop compared to the initial results in the sequential write test the third time round...that's 2/3 degradation...it was not confirmed by CrystalDiskMark


This is in fact one of my stated questions in the first message...how should I value these results? Do these tests measure performance in a way that other tests don't, is it actual performance drop or not? I can't answer these questions...certain remarks about CrystalDiskMark's reliability have caught my eye, but I haven't really read anything negative about As SSD Benchmark.


Well, I did try closing all programs and triggering the TRIM command by deleting a folder/files on the SSD just in case it did not kick in by itself (I read that in a bit-tech.net article), the pc was left hours idling and yet no increase in performance was measured.
After that, assuming that TRIM might not be actually working, I logged off for 8 hours and then tested again, assuming that GC will take TRIM's place instead, but had absolutely no performance increase.
Given that the tasks that might be causing the write speed decrease were closed, TRIM or GC should be able to make up for a certain, minimum amount of performance drop...
I have never read, anywhere, that GC has a level of SSD performance set, above which it will not kick in...so, even if this is a heuristically clever observation, it seems unfounded...unless you have come across any such reference, of course.
I have also read of differing level of performance restoration, but I have not read of total lack of any kind of compensation...


I have read threads at local forums about SSD performance overtime, but I have not come across any reference to such a drop in such short time with a TRIM enabled SSD (if not related to alignment problems or reformats etc) if time for restoration was given...I still haven't found an example on this same drive, though, and many comparable details are missing...I have posted in the Corsair forums, no real answer yet...there is at least one similar case, not much input on that either...
...even if the performance degradation I get is normal (which I doubt it is, since other people who work with large excel, powerpoint files, that do image editing etc have not testified to consistent and persistent performance drops with their TRIM enabled drives) absolute lack of any kind of performance increase in idle or during log off might point to a problem...
As I said above, the issue at hand is the level of performance degradation (if this actually occurs outside benches) with regard to the time-length in which it was measured and to SSD usage during this time + lack of performance improvement after logoff or idling...
If other external factors might be relevant, I would look to SB chipset and mb bios...but still haven't found an identical or greatly similar example.


Valid concerns, but if I had to make an assumption based on my experience, these would not be my top guesses.
First of all, if these same tests were at fault, then we would have to assume that after the first two days since the install, running the benches accounted for much of the measured 1/3 drop...
Furthermore, I have run two CrystalDiskMark tests close to one another with some small differences...if these played any substantial role in reducing performance, this would be clearly measurable between any two runs of these programs.
I have tried to minimize the number of benchmarks tests, exactly because I could be producing the issue I am trying to identify and overcome...but these benches have been few and generally scattered, so I would not count them as main factors here.

The heavy browsing is one of my concerns...still, since Firefox has been left with its given number of open tabs during an extended period of time (during night-time), so that some data would remain in the SSD but there would be no more writes running, one would expect TRIM to do its thing and give even a little, but measurable performance increase. This has not occurred, and although I am not at all willing to exclude it from the list of determining factors - after all this is the application I have been using consistently - I am more suspicious about the functioning of TRIM itself.

Are you comparing the results of two different tests? That may not be valid.


Actually, you're the only one who can answer that since the performance is going to vary depending on what you do with the drives.

Sorry if I'm restating the obvious but the most likely explanation for the difference between your benchmarking tools is that one test writes compressible data and the other does not. Apparently performance is dropping for sequential writes of random data. Do you care? You might or you might not. That would affect the time it takes to copy a DVD rip to your SSD over eSATA for instance, something a laptop user might care about. But that should not affect Firefox performance much (unless Firefox does something particularly wasteful of course).

If you want to know if the performance degradation affects real-world performance, the best thing you could do in my opinion would be to devise tests based on real-world operations. If you care about the performance of a particular operation, measure it many times and average the results. That would be guaranteed to be meaningful unlike benchmarks. Then you could compare your result with another SandForce user or run your test again after reformating your drive (with whatever correct procedure you're supposed to follow).


In other parts of your posts as well, it sounded like you were confusing TRIM and idle GC.
My understanding is that TRIM is supposed to let the controller know that data has been deleted. So it's not supposed to kick in by itself. Unless you delete enough stuff to get rid of a lot of fragmentation, deleting stuff with TRIM only allows the controller to do a better job of reordering the data on the drive. The controller still needs to do a lot of work if you've been doing a lot of random writes and you've not deleted all that random data.
Keep in mind that TRIM is not only about performance: it's supposed to allow the controller to do more wear-levelling.


There are tradeoffs. I have no idea what were the goals of the people who designed your controller but it stands to reason they're not going to attempt to get the absolute best sequential write performance out of a used drive. They'd have to completely defragment the drive as soon as they get a chance. That would wear out the flash faster, consume excessive amounts of power and possibly even degrade other performance metrics. Take a look at Anand's V+100 review for a probale case of excessive performance restoration.
Check my link above for an example of ineffective idle GC.


TRIM by itself does not guarantee any level of performance (unless you erase practically everything).
Keep in mind SandForce controllers work fundamentally differently than others. Are their design goals, algorithms or abilities publically documented? How long have they been on the market? What resources have been spent to test them thoroughly for the benefit of the public? SandForce has been hyped for a long time and I assume that's becuase their controllers are pretty sophisticated...
We don't even know for sure why the performance changed. It's reasonable to assume writes are slowed down because the drive is used and the controller needs to do more work. But the controller might actually operate differently once an arbitrary threshold (like the percentage of allocated flash, something which could be affected by compression) is reached. It could be designed to give you a higher performance initially. Then it could decide to work harder to preserve the amount of unallocated flash, future performance or something.


Do we know how fast the performance degrades? If it happened early, they might not have done a lot of work before it kicked in.
Would they even see a difference? Probably not with Excel or Powerpoint (unless they have insane documents). And you'd probably need seriously huge images to see a difference. If you're saving compressed images, the bottleneck might not be the drive to begin with and if you're saving uncompressed images, the drive might perform well thanks to its compression. You're most likely talking about fractions of a seconds for a 12MP image in any case.
My experience is that most people are unable to accurately assess the performance of their computers by using them. At best they can tell the difference between "good enough" and "annoying". But who can tell 2x faster than "good enough" apart from 3x faster for instance?

Not comparing, just bringing in the discussion a bench result that qualifies the statement 33% isn't that big a deal, since if this bench is taken into account, the degradation is actually greater...


I don't know how much I should care about the performance in those specific tests, since I don't have enough knowledge about how different programs work with data...I'm trying to determine with the help of others whether something is actually wrong based on clues, so as not to run into problems in the future if I can avoid them, or get the best performance possible from the drive.

Since you seem to know more, what kind of tasks would be affected by that drop in performance in sequential writes? What programs do those random writes? What data is compressible and what is not? Why would compressed data be slower to write than compressable ones?

Right now I'm off base and the one thing I keep doing of the stuff that I usually do with the pc is browsing...apart from that I often record from tv cards and encode to x264, I do some limited image editing and of course I use word processing software a lot. I used to do a lot of ripping, not anymore, but periodically I do a lot of video cam > hdd transfers. Also I've recently taken up website building which involves doing many local install -wamp/xamp- tests and local/website transfers...no gaming...


I used that expression, "kick in" for the TRIM function, because I read in a bit-tech.net article that one can manually trigger it by deleting files or emptying the recycle bin...I was trying to get some practical results and practical indications of functioning TRIM so I did that when I wanted to test for performance degradation/improvement after closing FF and deleting all its cached content.

To my mind, TRIM is directly related to performance - if I have understood what I've read correctly - since it scrubs junk data off NAND cells allowing further data to be written faster and in a less fragmented way on the drive.


My knowledge is severely limited on the above questions...

This is probably an idiotic question, but I can't see it mentioned in the thread.
Have you checked BIOS settings to ensure AHCI is enabled?

Sure, such basic settings have been taken care of and have been doubled checked...

How much free space do you actually have on that drive? I have an original 128gb gskill falcon from release, with updates, and it slows down alot when I have less than 20gb free, but goes right back to near new speed once I free up space. Trim only happens when you delete stuff.

If you haven't already, look into disabling hibernation and restricting the page file to 1gb or so, you can gain probably 6gb of space if you have 4gb ram installed. I think its "powercfg -h off" in an admin command prompt to disable hibernation and remove hiberfile.sys which will be the size of the amount of ram installed.

Looking back at your tests results, I see why you're concerned about that "AS SSD" benchmark. I kind of take it for granted that cheap SSDs will have slow sequential writes but 35MB/s is real slow.
Do you know what the software does? What's the difference between the two runs of the software? Do you consistently get such slow sequential speeds or was that a fluke? What happens is you simply copy a compressed video from your HDD to your SSD: how fast is that?


I get that but that's really Corsair's job. Unfortunately it's not their controllers.


Sorry, I assumed you knew that SandForce drives boost their performance by compressing your data internally. Non-compressible data would be data that's already been compressed (encrypted files, archives, videos, compressed images and so on). SandForce drives do not perform as well with that kind of files. Encryption also makes data non-compressible so whole-drive encryption might not work well with SandForce drives.

You can get sequential writes of random data by copying large video files or archives to your SSD or by using a program that's able to encrypt or compress fast, perhaps because it's assisted by dedicated hardware (for video encoding or encryption). Copying many pictures to your SSD or installing large programs and especially games to it would also involve a lot of sequential writes of random data. Using your SSD for cache/swap/scratch might involve such writes as well.
If you have a hard drive and a small SSD, I would think most of your sequential writes will be to the hard drive and not the SSD. I guess you'd be recording video to your HDD, not your SSD. So it's laptop users who only have the SSD that would be most impacted.
Using snapshots instead of copies for keeping old versions of any large files you're working on would reduce the amount of sequential writes.
In my opinion, what most people are looking for in a SSD is a random read speed that's much higher than a hard drive. And it looks like that your SSD delivers in that respect.


Some drives get good performance without TRIM. Others don't.
Regardless, TRIM can help with wear-leveling which is a concern as well. Even if the performance impact was small to non-existent, you'd better make sure TRIM works if you want your drive to last as long as possible.
But if you have mainly compressible data, the SandForce controller might do a good job without TRIM. I don't know how they really work but I guess they're making good use of the compression. Else why bother?

Right now free space is about 34,4GB out of 55,7GB total


I don't know if the following qualifies as a way to disable hibernation other than run a command, but I have chosen the "high performance" power plan and disabled any setting relating to hibernation. I also have the hard disk to turn off after 20 minutes of inactivity...sleep mode is also disabled.
Indexing, windows search, system protection are disabled.
I have set the page file to a stable 3GB size, since I have "only" 2x1GB of memory which is aggressively used by Win7. I haven't made tests with the page file size for a looong time now, but unless it is for the purposes of saving drive space, I set to to 2,5-3GB stable size. I think it's supposed to be x1.5 times the size of the RAM...whether this was dictated by previous drive technology or not, I am not sure



Between the two runs of the software, the only thing that mediated was an extra day and a night during which I had logged off account, hoping to see GC operating.
I copied two video files of 880mb and 1,96GB size to the SSD and looking at the reported average speed in HD Sentinel, it did not go above 36-7mb/s...I rerun the AS SSD bench this morning and the result was 40mb/s


I knew that as a bit of information, did not know about the trade-offs


Sorry, I did not get what you meant there...


Thanks for the information...
So it seems that the installation of the programs, the use of the page file on the SSD and FF browsing has impacted the performance in my case.
What seems weird, though, is that apart from MS Word, which is a large program, all the other software that was installed, were both small in number and small in size....antivirus software, K-lite codec pack, CCleaner, FF, Opera, keyboard/mouse software, an Uninstallation program, a registry fix program, Notepad++, Filezilla, HDD sentinel (yesterday in order to test the transfer speed) and two very small dictionaries...that's all I have installed...
I can't really believe that the installation of those programs - after the OS + drivers were installed - and the relaxed use of Firefox for even less than 2 days has impacted the performance by such a degree...
That's not easy to accept, unless maybe TRIM is not working...


Another reason why I believe TRIM is not working, is that I got the same results with the AMD ahci drivers within the first two days of installation/use...and people at the Corsair forums have quoted support questions/answers to AMD in which it was said that TRIM was supported only for the newer 800 series chipsets...
- So, if MS ahci drivers are giving me results that show the same level and rate of degradation (or worse) as the AMD ahci drivers, which by all accounts don't seem to support TRIM for my chipset, then doesn't that mean that TRIM is probably not functioning in my case?

Assuming that FF has played a part in performance deterioration, last night I deleted all history, cache etc closed the program + I deleted the video files I had copied to the SSD and left the pc idling overnight...I rerun the benches this morning and did not get any improvement measured (2-3mb/s can be a difference between different runs of the bench test)...shouldn't that give me some practical indication of functioning TRIM?
I understand this is not some large volume of data, but then again this very small volume of data seemed to cause the performance deterioration...

Wow, wall o text. I haven't read it all but I'll chime in with a couple of points (one minor a some major)

First I'm a he not a she. Minor detail but I thought I'd cover it.

Now on to tech:

If I could say one and only one thing about using a SSD it would be

Avoid any and all unnecessary writes to the drive.

lets try this thought experiment. Take a Hard Drive with no physical errors and a SSD with no physical errors. Setup the OS of your choice and test for performance. Take an image of the drive data so you don't have to setup the OS from scratch again.

Now take both drives and write data to the entire usable area (doesn't matter if it's all 0s all 1s, random data, real files, just write to the drive)

Restore the OS to the drives and test performance again.

On the Hard drive the test results will come back essentially identical between the before and after tests (within margin of error)

On the SSD the after test results will be anywhere from marginally worse to completely unusable depending on the drive controller/firmware, the data written, and the time allowed for recovery.

So the short version of the test is

Put OS on drive
test
write data
Put OS back on drive
test

To get better results out of the SSD you have to add a step

Put OS on drive
test
write data
Perform Secure Erase procedure
Put OS back on drive
test

You could optionally test again between the write data and secure erase steps to show the benefit of the secure erase but for the purposes of the thought experiment that isn't needed.

Hard drives have sectors and blocks but the performance difference when you cross a boundary is minor. SSDs have tremendous penalties for writes that cross boundaries.

So what does this have to do with benchmarking SSDs you might ask.

1. You can do read tests all you want and it won't affect the SSD

2. Doing Write tests with your benchmark software or by copying files to the drive changes the performance of the drive. Heisenberg's principle doesn't technically apply in a literal sense but it sure seems an appropriate analogy because in the case of SSDs testing write performance changes write performance.

Unless you are a reviewer or are experienced enough and have the time to secure erase and re setup your OS you should seriously avoid write benchmarks on your SSD. Using Acronis/Ghost/etc adds in the possibility of misaligned partitions or could theoretically be used to fix a misaligned partition but it's not a user friendly issue.

Test your drive all you want while booting from another drive but secure erase after benchmarking and don't test writes any more once you put the drive into day to day use.

@dhanson:
It matters to SandForce drives whether you're writing zeroes or random data. We don't know how much it matters but it's got to matter or their compression is just a gimmick to beat the competition at meaningless benchmarks. If the controller does a good job, it'll have unallocated flash to write your OS to after you filled the drive with zeros but not after you filled it with random data.


That's useless.
I shouldn't affect the performance of the drive unless Windows actually writes data allo over the swap file (to prevent people from analysing it to find confidential data or something in there perhaps). If you have software that overwrites the swap with random data (that's how you're suppose to erase confidential data from hard drives), definitely downsize it!


Ouch!
Get a SandForce user with your OS, an Intel chipset and a heavily used drive to to run the same test (a stopwatch would be better than "HD Sentinel" actually) and you'll know the answer to your question.


Copy a large file to a backup file in order to have an old version to fall back on before you start working on the file: sequential writes.
Use snapshots instead: no sequential writes... unless your file system does COW.
Now that I think about it, COW could cause lots of sequential writes when you edit large files. And some software emulates COW. I didn't think about that either.


Only if SandForce designed their drive to perform better with TRIM. You keep assuming they have the same design goals you've got in mind. But there are many reasons why they could have chosen to give you relatively poor performance...
If you (or someone else) did controlled tests, you'd know the answer. All we have now is speculation.

Ah, I think I understand now better what you said earlier.


I guess this is a HDD habit more so than anything else, to prevent further fragmentation and performance loss...
...I have read threads that suggested to do so also for a SSD, but maybe it is indeed useless.
I don't use any such program


Hmmm, if only I had all of those waiting around...damn, troubleshooting demands resources...


How else could they have configured the drive to work best unless with TRIM? (reiterating the assumption)
Do you mean they could have configured it to work better with GC or is it something else you're referring to?
If it is GC functionality you're alluding to, I believe this is probably not the case. Their suggestion for optimal performance is in AHCI and their drives cannot even get their firmware updated unless they are connected in AHCI mode. IDE is not recommended...which means that their SSDs should be more optimized to work with TRIM and GC is more of a deviant path...


@dhanson
Thank you for your input...however, you seem to be suggesting a test that circumvents every specific issue posed in this thread:
- if TRIM is working at all
- if it is working, why is performance degrading day by day, even when the programs that probably cause this are closed and their written data cleared and adequate time for recovery given.
- if it is working, how effective it is, and if its effectiveness-limitation is set by its implementation or by my hardware.
- if it is not working, why it is not working since it should be
- If such a performance drop is/can be justified by the use of the programs and within the given period
- To what degree the benches themselves can degrade performance and to what degree they might have (well this has been tested, and between any two benches the difference is rather small, so it's not probably a determining factor in the degradation)
- whether the combination of the SB700 chipset and the AMD ahci drivers supports TRIM

One version of your tests could answer the TRIM question:

By giving TRIM a great load of work to do, instead of some GB of data, I could actually tell whether if it really has any effect...



I am missing the point of this test... Is it relative to the particular questions to test the performance gap between a clean first formatted SSD and an erased reformatted SSD?




This is good advice when questions have been answered and a good way to maintain performance or rather hinder performance as less as possible by avoiding unnecessary writes.


Since I do not see how I could draw a conclusion for the particular case out of the above test, I am more worried about the impact to the lifetime of the drive if I were to write tens of GBs of data to it

Am I missing something?

you seem to be assuming I'm talking about actually physically doing anything I posted in this thread as a though experiment. The whole point of that was to suggest that you NOT do that sort of experiment nor any benchmarking of writes on your drive unless you are willing to do a secure erase before using the drive for day to day use.

I'm saying don't do it or any other benchmarks, just use the drive. If you really want to be darn sure you set it up right you can do a secure erase and start over but other than that don't run so many benchmarks on your drive if you are truly wanting it to perform well in day to day use.

- if TRIM is working at all

This should be reported by Win7. Have you tried "fsutil behavior query DisableDeleteNotify" at the command prompt (run with Admin rights)?

- if it is working, why is performance degrading day by day, even when the programs that probably cause this are closed and their written data cleared and adequate time for recovery given.

TRIM isn't magic, there are things other than TRIM working or not that would affect your drives performance changing day to day.

- if it is working, how effective it is, and if its effectiveness-limitation is set by its implementation or by my hardware.

Assuming TRIM is working I would think it would work the same no matter what hardware you have. TRIM either happens or doesn't. I don't think there is an in between quality.

- if it is not working, why it is not working since it should be

Redudant, go back to question 1 and figure out if its working or not.


- If such a performance drop is/can be justified by the use of the programs and within the given period

Performance of SSDs varies wildly from second to second, minute to minute. I wouldn't worry about a single benchmark run.


- whether the combination of the SB700 chipset and the AMD ahci drivers supports TRIM

Dunno, I haven't heard anything about specific driver interaction with TRIM. I haven't used a SSD on Win7 yet. All my SSD experience is with XP and Server 2003/2008 all 3 of which don't support TRIM natively.

I mean it's useless to make it so huge. Check how much you're actually using!


Some controllers don't make much use of TRIM (for performance). TRIM or not, the drive probably has some GC going. It's not one or the other.

What I meant is that they may not care to give you much better performance than you're experiencing. Maybe you have TRIM and it could be even worse. And maybe you don't but it wouldn't make a huge improvement unless you deleted most of the data on the drive (at which point TRIM definitely should be having an obvious effect).
For "optimal performance" I bet they want you to pay more!

I understood what you said, I just tried to adapt it to my current concerns and maybe extract a more relevant and helpful answer...(as the one I see you have made since your first message)

The drive has been setup correctly, but it is not responding as it should, or so I think...this was my first experience with a SSD so I did the minimum testing needed to verify it is working properly...the first time round, when I installed the AMD ahci drivers, I witnessed a degradation which I related to existing references to unsupported chipset by the drivers for that TRIM functionality....So I secured erased and reinstalled (as you would suggest) confident that everything is fine. I felt, however, that I should verify again...and the tests revealed an existing problem, which could be a replication of the previous problem, i.e. not functioning TRIM.


Yes, and I get a positive result, but that does not mean it is actually working...it means it is properly supported so as to work.


Such as?


I hope so, but HFat posted a link to a review before, where a Sandforce drive kept its performance high nevermind the writes...that would probably count as differing effectiveness...or not?


Not redundant really..I mean there are two issues
-if it is working
-if it is not, why...furthermore, the response is different if it was not designed to work for the configuration or if there is a necessary setting one must change or if it should be working but it isn't.
If the function is supported and the proper settings have been applied, then the "why isn't it working?" question acquires different significance...in the former case the answer would be "because you have not enabled it in the registry"...if that setting is correct,and we are dealing with the latter case, the answer requires different thinking.

Ok, I've mumbled a lot..moving on...


The thing is, more than one has been run to test at different occasions, and not just synthetic benchmarks, but actual tests by copying large data to the drive, and the low speed/bench result/performance degradation has been verified.
When I run a test, I can see some ups and downs, but the average may be or less consistent (even taking into account the degradation).
If you meant something more than that, please inform me...


Aha! Now I have pinpointed the source of "just use it" attitude
You don't have to worry about it!


Is it? with win7 taking up so much RAM isn't it advisable to have the recommended page file size (1,5 times the size of your RAM, given that you don't have too much of it) ?
That said, I have never really measured average use. It has happened to me however that physical memory has been exhausted (the embedded video chip eats up some also), so I figured I might need the recommended amount.


I have no knowledge on this and judging from review you've referred to, that could be true...or it could be that TRIM is effective at different degrees with different controllers? (is that even different practically from what you said?)
What I mean is that if TRIM scrubs off junk data, shouldn't its operation have performance improvement as a consequence?
Moreover, I have the impression that GC might be more likely to differentiate itself between controllers and manufacturers since this is the built-in feature...whereas TRIM is more OS dependent and should work more consistently between SSD drives..
Am I wrong?


With different hardware configurations I have seen some crazy numbers with this drive...that's why I would tend to say that there might be more performance prospective than the one I'm witnessing...
If more free data is needed, then that is actually bad news for the consumers...because it means that one would have to get a 120GB SSD to have good performance with 30GB data on the drive...
Shouldn't 34GB of free space be enough?

True, and if you figure out a way to make your system work better with that drive/OS combination I'm all ears. I'd love to learn something I don't know.

Keep in mind I had the Intel toolbox running trim once a day on the boot drive in my work PC. But I never saw a slowdown that a manual TRIM fixed.

The "don't worry about it just use it" attitude I'm suggesting is because you can actually use a SSD in a way that causes the firmware to react defensively and slow down the drive. Too much writing in a short period can trigger odd behaviors in a MLC SSD. The firmware/controllers are new/young/unproven and you can torture the drive into behaving badly.

Intel has documented how their controller slows down an SSD defensively but my googlefu isn't strong (I'm tired after watching a double overtime bowl game). Maybe I can search some other day.

The question is how does sandforce react? Does it get defensive or wait until it's too late?

7 as such does not take up so much RAM. I assume it would not run well on 128M like XP used to (I'm not going to try!) but it runs fine much less RAM than you've got.
The "recommended" size was always nonsense but I recall when people were saying it was 2.5 times.
There is no such thing as "too mcuh" RAM from a performance perspective if you run decent software. Using all the physical RAM is a good thing and it doesn't mean you're going to swap heavily.


Do we know if random data was written in that test? Do you have the same firmware and controller?
Interpreting tests of SandForce controllers is trickier than usual.


There's no direct relationship between TRIM working and performance. Many drives may show a dramatic improvement but others won't.


Your own numbers are crazy in "0Fill" mode. And you initially had good numbers. Mind the differences between uncontrolled tests!


A 120G SSD will be faster at sequential writes (of random data for drives wihch compress) than its 60G small brother irrespective of the data on it. More flash chips typically mean that the controller is able to dump data to flash faster. Random writes are not necessarily affected so much by the price of the drive because there are more potential bottlenecks.

If you wanted fast sequential writes you should have gotten a V+100. Of course they're more expensive than SandForce drives and may not be as durable...

It's not the free space which matters but how much flash "blocks" the controllers can write to without care for the data currently on them.
Some drives seem to aggressively create such "free blocks" in order to boost future performance. But there are tradeoffs, especially with regards to longevity. With TRIM, you could get more performance for the same longevity. Controller designers might prefer to take advantage of TRIM for longevity and target some mind of minimum performance level or something. A controller who wants its chips to last a long time may allow (sequential) write performance to degrade. It might even deliberately cripple in some cases.

Very informative HFat...I think I'm slowly starting to get the gist...


Maybe because I did not go through Vista, 7 to me seems to be eating a lot of RAM...but of course that is not necessarily bad, RAM is not supposed to be empty...
But because it caches so much to boost performance, programs that may take up a lot of RAM when run, might have to make use of the page file...of course that's not an argument for the specific size I've selected. It is out of ignorance that I keep this as a rule of thumb, although it might not be useful...

I'm pretty sure the recommended page file size is 1,5 times the physical RAM...the default set by the OS usually is just a little short of that...
My reference to too much RAM only meant that if one has 4GB or more, it would be a big waste of space to create a page file based on the RAM x 1,5 rule...


Another question...what kind of write tasks are not sequentially writing random data?

I may have some good news...
...today, after having cleaned all cache from browsers and closed them down and removed all temp files with CCleaner, the benches showed improvement, climbing back to 60mb/sec area for sequential write...
However, real world performance, as displayed through Hdd Sentinel's disk activity tab, did not reach that high, although it did improve from the previous 36-40mb/s, reaching 48-53mb/sec...
This is the first indication I've had of improvement in write tests...(it was bound to happen on new year's eve! )

So, HFat you could be right in your estimation of the TRIM finetuning/configuration for the drive...

Does anyone know of software for manually TRIMming the Corsair SSD? I want to trust the manufacturers settings for the drive, but if such software exists, it might be nice to have it around...

Nothing but "0Fill" is truely non-random but stuff with limited randomess includes text (including HTML, code and so on), most databases, emails, uncompressed digital content, uncompressed programs and so on.
As to non-sequential stuff, again it's not black and white but web caches, databases, anything that creates small files (decompressing a code archive, compilation, mirroring a web site and so on), logging and so on tends to involve largely random access. Modifying large files could involve sequential writes or not depending on whether some form of COW is used.


You only need to manually TRIM is your drivers or hardware don't support it. If that's the case only tools which have their own drivers (if you must boot a read-only OS to use them instance) could work. And nothing will work if the hardware is the issue.
Unless you want to run the software on a computer with a chipset that's known to be compatible, I suggest you follow dhanson865's reimaging suggestion above. Whether the test shows that TRIM is working for you or not, you'll get close to the fastest possible performance after the conclusion of the second test. TRIM alone can't guarantee that.
I assume you already have imaging software. But you may not have software for the so-called "secure erase procedure". In that case, dhanson865 should be able to tell you what software is most likely to do the job.

I will probably do that as soon as I have most things figured out...however, it does not solve anything and the restoration is quite shortlived, very temporary...in my case it does not take more than two days of very relaxed usage for the numbers to reach the present condition...
It's just a way to reset, to start over...from one perspective it really only makes sense if one does that periodically in order to restore performance...but in that case, I would be writing tens of GBs of data to my SSD...not something I would want to do...


I've got the programs, I've already used Parted Magic once (much simpler process than HDDErase), after trying the AMD ahci drivers...really easy to do and pretty much idiot proof...

Ok, I did a little bit more research today and it seems the issue is much complicated...

- Firstly, Sandforce SSDs do not play well even with default MS ahci driver...this may be the fault of both of them, MS's working for a universal driver and SF not doing optimizations...testing for TRIM support with Sandforce SSDs seems to yield confusing results.
- Secondly, Sandforce TRIM and GC are very, very mild, and allow much, much degradation to happen before kicking in, and they are slow at it also.
- Support for TRIM seems to depend on many factors: OS > Os_driver > Chipset_Controller > SSD_Firmware > SSD_Controller...
- There is no evidence or proof (or real indication) that 780G/SB700 chipsets don't support TRIM, but on the AMD side driver-support is the main issue...a TRIM supporting driver was released on November, but it was withdrawn...even on that case it is unclear if SB700 sb was supported by the driver to implement TRIM
- Corsair might be pushing for Intel for this Sandforce Force 60GB drive (e.g. I had asked about getting an addon PCIe controller I was advised to get a specific chipset Intel-based one), because the intel released driver really makes the drive look good, overcoming the shortcomings of the Sandforce-MS match...


HFAt, you were right in your hypothesis that SF1200 is mainly targeting at longevity...
dhanson865, you were right in telling me to "just use" the drive...at least until a supporting-optimized AHCI driver is also released by AMD...

Some useful links
AMD and TRIM
780G + Sandforce
AMD AHCI 10.9 and Trim?
Trim Test
AMD AHCI Driver SSD TRIM Support

The posts by "QB the Slayer" starting on 10/27/2010 are full of win. I love it when someone documents a complex scenario that well.

and the HD Tune screenshots to go with his documented process.

Interesting result though if you follow the thread is the catalyst 10.9 (Sept 2010) driver passed the TRIM command and catalyst 10.10 (Oct 2010) driver didn't. Also the MS AHCI drivers passed the TRIM command and worked slightly faster than the catalyst AHCI driver.

The tests are of course valuable but "QB" is also spreading confusion. She writes: "One thing you should know about NAND is that it only has a limited amount of writes... so why would a drive actually write a zero? It is just deleteing the block from it's lists (i.e. turning it off)."
That would make sense but her illustrations (and Anandtech's) show overwriting. I suspect most drives will overwrite but they don't have to do it in real-time or in such a simple operation (they may defragment free space while they're at it).


I'm not suggesting you do that periodically but after hammering your drive with write benchmarks, as dhanson865 suggested. You have lots of free space. If you have TRIM this may not be important but, if you don't, your drive may work to preserve fragmented deleted test data for a long time...


TRIM is merely an instruction.
Many things get called GC. Your drive is quite fast at some of them (look at its random write speed!). I suspect that what it's not doing aggressively is to defragement free space into unallocated blocks in order to allow fast dumping of data to flash. It seems that often gets called idle GC which makes little sense. Whatever.

.....

No, that's if you overwrite those 504K! And TRIM makes no difference in that case of course.
If you delete a file occupying 504K, the writes happen elsewhere (with or without TRIM) and the data is untouched on the drive. The controller may overwrite the data as well if you have TRIM but, so far as I know, it doesn't have to. The reason the drive would overwrite unneeded data is to allow faster writes on this "block" next time around. But it won't do this if TRIM doesn't tell it the data has been deleted! So, if the controller behaves as you describe with TRIM, deleting a file would probably be slower and not faster with TRIM.
This overwriting would be unnecessary if the "data" was all zeroes (or perhaps ones - I don't know which actually) by the way but the controller might not be aware of that and overwrite anyway.

.....