Also my SSD is the "Safely remove Hardware Eject Media" button is the system tray. Obviously it's not meant to be there. Just thought this might help pin pot my problem.
It's there because SATA by default allows "hot swapping" of drives. This paper from Microsoft describes how to edit the Registry to tell Windows that the drive should be treated as a non-removable device.
Might I suggest not running AS SSD too many times? It writes a very large amount of data to the drive to produce the result. It makes it more accurate, but more wearing on the drive. The original numbers look low, but the ones you posted second look fine, so I'd just start using the drive for what you bought it for instead of benchmarking it to death
Although not directly related to this thread, users need to quit fretting over SSD degradation (i.e. should I move the pagefile, cache, etc) and use the drive for what it is!
I recently replied on a thread about a user with a 128GB SSD, whom wanted to know how to move "things" off the SSD to a HDD. I told them to quit worrying about it and use the drive! Wouldn't you want the faster access to these "things"?
Yes, multiple writes and re-write do degrade the drive, but they are rated something like 20GB a day, for 5 years. In 5 years, we'll all need new drives anyway, to go with the newer systems.
Those numbers (20GB/day for 5 years) are debatable, at least for 5k NAND.
The numbers come from Intel based on the wear-leveling algorithms used in it's controller. The original X-25M drives were rated at 100GByte/day for 5 years, the G2 drives are rated at 20GByte/day for 5 years. We'll have to see what happens with the next generation...
Now the original poster is using a Kingston drive (and it's not one of the rebranded Intels), so Intel's numbers probably don't directly apply. One of the reasons I chose Intel when I shopped for an SSD is that they were the only vendor who was actually quoting what their drive's durability was.
Interesting. However it depends largely on the type of data as well as the controller. For example, a Sandforce controller compresses data to reduce writes, but already compressed data (or random data) will not be compressed easily. Contrast that with an Indillinx controller which will write things at a 1:1 ratio or worse. Obviously larger files have less issues with write amplification than small files as well. Anything under 512kB is going to waste a whole block.