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.
As for the speeds.. only the Sequentials are affected, because of the sheer volume of data involved in large file transfers. The Random speeds, which are more representative of OS usage day to day, remain largely excellent. Even so, Sequentials drops in real world OS usage (where caching policies are used) DO NOT reflect what AS_SSD and CDM or Passmark sequentials report. Because of System Cache, the largest drop in write speed you are likely to see (using compressed or compressable data) is around 10-15%. This as opposed to benchmarks that may show 50% drop.
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.
On a SF drive a TRIM does not happen instantly, the trim is issued and the addy for that trim is mapped, the controller then sees you are writing more data so it kicks into active TRIM and write mode where it pulls the most suitable blocks from the map, resets them and then writes to them. From the look of things this happens on the fly.
Also the controller ONLY cleans what it needs for a given write, not 1 block more.
And lastly the speed of the TRIMs is dependent on what was previously written to the blocks, with incompressible data taking longer to TRIM then compressible data. If you are at this time writing an incompressible data file to the drive this is then going to make it look even slower.
expecting the SF drive to actively clean large amounts of blocks then run them at full speed when you run a benchmark so the drive reports a fast speed...NOT going to happen. The drive does not clean huge amounts of blocks as this would massively increase write amplification and end up killing the nand much faster.
