SSD Tweak Guide

Status
Not open for further replies.
I saw your post so I re-ran the AS-SSD Benchmark on my drive. It scored better than yours, but worse than my last run. So I cleaned up my drive thinking it would force the TRIM command and I re-ran AS-SSD again, this time my seq. write was worse than yours so I did some investigating and found this.

OCZ Forum said:
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.

Basically, what there saying is, the TRIM command does not work the same way with the new drives. With the old drives anytime you deleted something the TRIM command was issued. With these new drives the TRIM command is issued before a write but it doesn't clean the whole drive, only what it needs for the write. And then, based upon your "average" general usage it cleans the drive slowly when not in use. It does this slowly to prolong drive life over performance, but even with the somewhat slower performannce it is still a lot faster than an older SSD.
 
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.

From what I understood the AS SDD reports a 50% speed drop, which is my case, but "in real life" this decrease is around 10/15 % but only to preserve the NANDs. So, my results are normal, good to know :D
Thanks for the explanation.
 
Any chance you could explain what each tweak does too? Rather then just telling us how to do it?
Like what does Enable Write Caching do? or Disable Superfetch / Prefetch do?
It would help a lot

Thanks.
 
I don't have the time to go through all of that, I suggest you try a simple google search.

However, all/most of these tweaks are recommended by the various manufacturers.
 
I did all this after i got my drive a while back. Made little noticeable difference to be honest, though it's supposed to be better for the drive.
 
LoL

you have the time to take 20 some screenshots, add red rectangles and arrows and whatever else to them, upload them, embed them in a huge (and incidentally very useful post) but you don't have time to quickly explain what each does?!?

something smells. weak sauce.
 
Why write what they do if there already good explanations out there? This is just a list of tweaks, not an in-depth guide to the workings of the Windows OSs.
 
Status
Not open for further replies.
Back
Top Bottom