I also discovered smartctl.exe has a command option to force the ssd to start a new self-test even if the previous self-test hasn't completed, so I've added that option to the. Last night I discovered the extended self-test occasionally lasts longer than 26 minutes.
#Crucial ssd testing software manual
(It would help if I could find a ready-made utility to parse the relevant data from the logfile into my spreadsheet, to eliminate the manual copy&paste operations.) There may be a pattern buried in the SMART logfile, but I don't know if I can find the time to hunt for it. The priority of the static wear leveling process might get bumped up if it doesn't run for a few hours. Perhaps there's a limit to how long the ssd will postpone running the static wear leveling. I don't know why WAF occasionally jumps to 20-ish. I stopped the self-tests for about 2 hours this morning. With self-tests running, about four in five of the 26 minute WAFs are less than 3, and about one in five is close to 20. The periodic SMART snapshots continue to show that self-tests are effective at reducing WAF. It's been less than a day since I began the experiment - too early to reach a solid conclusion - but the SMART snapshots so far are encouraging: If it's lower priority, it might not reduce the wear leveling runtime, and thus might be useless. One of the questions to be determined empirically is whether the self-test is a lower priority process than the Static Wear Leveling process. And it prevents the ssd from going to a low power state, which can be seen by its effect on Power On Hours. However, it should be noted that the self-test raises the temperature of the ssd by about 5 degrees C. I think self-tests have huge advantages: it's a background task within the ssd so I think its low priority doesn't interfere much with host read/write performance, and it doesn't require the host cpu to do any extra work so it doesn't heat the cpu or waste as much power as the other ideas would. The self-test idea is similar to the ideas we discussed earlier: keep the ssd busy reading by running virus scans, searches, or backups. My theory is that by spending a lot of time internally reading itself for the self-tests, the ssd won't be able to spend as much time running the overly aggressive Static Wear Leveling process. I chose 26 because it appears the self-test takes about 25 minutes to complete and I want the ssd to spend most of its time running a self-test. I've been running a batch file that commands the ssd to run an extended self-test every 26 minutes. Last night I began a new experiment, and so far its WAF results are very encouraging. it seems counter-productive to heavily waste scarce NAND writes in order to maximize equality of P/E cycles. I see no value in "over-circulating" static data blocks when write rate is low. the algorithm when write rate is low shouldn't be the same as the algorithm when write rate is high or moderate.
It seems to me the truly "best" wear leveling algorithm should depend on the host write rate. It's plausible that reading reduces the rate at which the ssd can circulate blocks.
It's another reason to test the theory that WAF will be helped by running an app that reads frequently from the ssd (such as a virus scanner).
"Life Consumed as a function of Host Writes" isn't necessarily reasonably monotonic it may have a sweet spot. If true, the implication is that it's not straight-forward to try to increase an ssd's years of life by reducing the host write rate (by moving frequently written temporary files to a hard drive). Click to expand.That's an excerpt from a blog post at: