Here is the thing, if you hammer the driver with say enough writes that the drive would under normal use/see in 7 days within a few hrs, the drive will slow down for 7 days, maybe longer. It does this to protect the nand life. So your guys seeing a 50% drop may actually see 30% which is the normal drop, then a further 20% because at some stage they have hammered the drive and then not realised its going to take 5 days or longer for the speed to creep back up. Also remember this write quantity slowdown is further impacted by how you use the drive after you have hammered it.
So take this as an example:
1 you run a few benches and fill the drive with incompressible data,...you do this a few times
2 you run As-SSD a few times and on each run the performance drops lower and lower.
3 you panic thinking the drive is broke
4 you then note its just slowed down quite a bit so continue benching to see if it has started to speed up
5 this benching is actually delaying the drive recovering
6 you note the drive has stayed dog slow....so continue with 4 to 6 AS-SSd runs per day hoping or looking for a drive speed increase
7 the drive stays dog slow
8 you post on the forum that the drive is somehow broken
What you see here is an end user actually inducing the slowdown and not allowing the drive to recover...and its really very easy for this to happen.
SF have told me a drive with incompressible data will bench sequentially a LOT SLOWER than a drive with a mix or more compressible data...so just by using AS-SSD you are actually limiting the drives speed.Also speed is directly linked to what has been written to the drive and what is being written. This seem linked to TRIM speed also where GC reallocates blocks that have had compressible data written to them faster than blocks with incompressible data.
Moving on:
TRIMs do not happen the way they do on indilinx, a TRIM on the SF drives happens in a much more controlled way and is far more accurate to keep WA as low as possible, this means selected blocks in order are pushed thru for erase and made available...This also slows the drive down a little.
The short of it is this, under normal usage patterns these drives perform well, as soon as you hit them with AS-SSD or CDM a few times you are infact inducing problems to the drives and I am now strongly thinking OCZ should not support their use due to the side effects they have on the performance there after.
These benchmarks are pushing Duraclass to work VERY hard, and as such they are slowing the drives down massively, as does calculated compressed large volume writes which people do when looking for an issue. I know you guys like to play and test, and yes you have found something BUT you are inducing the problem then asking SF and OCZ to cure it....i feel by not inducing the problem and forgetting about the drive in day to day use you will never actually see the problem.
I suggest you guys testing do so away from CDM (unless you set to uncompressed also) and AS-SSD to see what the drive does when dirty with alternative data patterns, I do know that just testing with these 2 can actually paint a dirtier picture than is actually there.
