Question Crucial MX500 500GB SATA SSD - - - Remaining Life decreasing fast despite only a few bytes being written to it ?

Page 15 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
L

Lucretia19

Reputable
Feb 5, 2020
195
15
5,245
The Remaining Life (RL) of my Crucial MX500 ssd has been decreasing rapidly, even though the pc doesn't write much to it. Below is the log I began keeping after I noticed RL reached 95% after about 6 months of use.

Assuming RL truly depends on bytes written, the decrease in RL is accelerating and something is very wrong. The latest decrease in RL, from 94% to 93%, occurred after writing only 138 GB in 20 days.

(Note 1: After RL reached 95%, I took some steps to reduce "unnecessary" writes to the ssd by moving some frequently written files to a hard drive, for example the Firefox profile folder. That's why only 528 GB have been written to the ssd since Dec 23rd, even though the pc is set to Never Sleep and is always powered on. Note 2: After the pc and ssd were about 2 months old, around September, I changed the pc's power profile so it would Never Sleep. Note 3: The ssd still has a lot of free space; only 111 GB of its 500 GB capacity is occupied. Note 4: Three different software utilities agree on the numbers: Crucial's Storage Executive, HWiNFO64, and CrystalDiskInfo. Note 5: Storage Executive also shows that Total Bytes Written isn't much greater than Total Host Writes, implying write amplification hasn't been a significant factor.)

My understanding is that Remaining Life is supposed to depend on bytes written, but it looks more like the drive reports a value that depends mainly on its powered-on hours. Can someone explain what's happening? Am I misinterpreting the meaning of Remaining Life? Isn't it essentially a synonym for endurance?

�
Crucial MX500 500GB SSD in desktop pc since summer 2019​
Date​
Remaining Life​
Total Host Writes (GB)​
Host Writes (GB) Since Previous Drop​
12/23/2019​
95%​
5,782​
​
01/15/2020​
94%​
6,172​
390​
02/04/2020​
93%​
6,310​
138​
 
  • Like
Reactions: demonized
Sort by date Sort by votes
worstalentscout said:
life just dropped to 81%..............

247 erases..........13,075 GB written.........

write amplification...........1.74..........
Click to expand...

During the Remaining Life decrease from 82% to 81%, the host pc wrote 626 GB (= 13075 GB - 12449 GB) to the ssd. That's similar to the amounts written during the previous two decreases, so the bug's excessive writing still doesn't appear to be accelerating. Or at least not by much... dividing 13075 GB by 19 gives the average: 688 GB per percent of Life used, and 626 is worse than the average.

Total write amplification increased to 1.74. Although the increase from 1.73 looks small, it corresponds to a recent larger amount that's averaged in with about 20 times as many older smaller amounts. That recent larger amount is larger than 1.74. I'll leave it at that, because you haven't been showing how you calculated the write amplification. (Assuming you've been using the correct formula to calculate write amplification, those calculations would provide the "NAND pages written by the host pc" and the "NAND pages written by the ssd's FTL controller" at each of the recent percent decreases of Remaining Life.)
 
Upvote 0 Downvote
Lucretia19 said:
During the Remaining Life decrease from 82% to 81%, the host pc wrote 626 GB (= 13075 GB - 12449 GB) to the ssd. That's similar to the amounts written during the previous two decreases, so the bug's excessive writing still doesn't appear to be accelerating. Or at least not by much... dividing 13075 GB by 19 gives the average: 688 GB per percent of Life used, and 626 is worse than the average.

Total write amplification increased to 1.74. Although the increase from 1.73 looks small, it corresponds to a recent larger amount that's averaged in with about 20 times as many older smaller amounts. That recent larger amount is larger than 1.74. I'll leave it at that, because you haven't been showing how you calculated the write amplification. (Assuming you've been using the correct formula to calculate write amplification, those calculations would provide the "NAND pages written by the host pc" and the "NAND pages written by the ssd's FTL controller" at each of the recent percent decreases of Remaining Life.)
Click to expand...

the decrease in GB written per 1% in life is a little concerning to me...........but not much i can do about it..........tried many times but can't update the firmware ................also afraid updating the firmware might produce bigger issues..........

lucky thing is MX500 prices had come down a lot.............so i can just grab a new one...........i do have a clone of the boot drive (also MX500 250GB) so i think both should last me next 5-6 years if not longer.........
 
Upvote 0 Downvote
worstalentscout said:
the decrease in GB written per 1% in life is a little concerning to me...........but not much i can do about it..........tried many times but can't update the firmware ................also afraid updating the firmware might produce bigger issues..........
Click to expand...

You could try to mitigate the problem as I did, by running ssd selftests nearly nonstop. On my ssd it made a huge difference, as the data table below shows, without slowing down the ssd read/write speeds. I posted a .BAT file here in 2020 that you could use to run the selftests. You could set Windows Task Scheduler to launch the .BAT file every time Windows starts.

I began running the nearly nonstop ssd selftests near the end of February 2020. At the time, the most recent "GB Written per Life%" was 138 GB (highlighted in red in the table below), during the drop of Remaining Life from 94% to 93%. The period during which Remaining Life dropped from 93% to 92% began with a few weeks without the selftests and ended with a few weeks under the selftests regime, so its 337 GB Written is a mix. During the 3.5 years since it reached 92% it's dropped only 6% further under the selftests regime and averaged 1400 GB Written per Life%.

Date​
Attribute 173
(ABEC)
= 15 x (100-RL)​
Remaining Life %​
Total Host Writes (GB)​
1Row Host Writes (GB)​
07/28/2019​
0​
100​
0​
​
08/31/2019​
15​
99​
1,772​
1,772​
​
30​
98​
​
​
​
45​
97​
​
​
​
60​
96​
​
​
12/23/2019​
75​
95​
5,782​
​
01/15/2020​
90​
94​
6,172​
390​
02/04/2020​
105​
93​
6,310​
138​
03/13/2020​
120​
92​
6,647​
337​
10/19/2020​
135​
91​
8,178​
1,531​
09/16/2021​
150​
90​
9,395​
1,217​
05/20/2022​
165​
89​
10,532​
1,137​
11/12/2022​
180​
88​
12,082​
1,550​
04/11/2023​
195​
87​
13,535​
1,453​
08/25/2023​
210​
86​
15,038​
1,503​
 
Upvote 0 Downvote
Lucretia19 said:
You could try to mitigate the problem as I did, by running ssd selftests nearly nonstop. On my ssd it made a huge difference, as the data table below shows, without slowing down the ssd read/write speeds. I posted a .BAT file here in 2020 that you could use to run the selftests. You could set Windows Task Scheduler to launch the .BAT file every time Windows starts.

I began running the nearly nonstop ssd selftests near the end of February 2020. At the time, the most recent "GB Written per Life%" was 138 GB (highlighted in red in the table below), during the drop of Remaining Life from 94% to 93%. The period during which Remaining Life dropped from 93% to 92% began with a few weeks without the selftests and ended with a few weeks under the selftests regime, so its 337 GB Written is a mix. During the 3.5 years since it reached 92% it's dropped only 6% further under the selftests regime and averaged 1400 GB Written per Life%.

Date​
Attribute 173
(ABEC)
= 15 x (100-RL)​
Remaining Life %​
Total Host Writes (GB)​
1Row Host Writes (GB)​
07/28/2019​
0​
100​
0​
​
08/31/2019​
15​
99​
1,772​
1,772​
​
30​
98​
​
​
​
45​
97​
​
​
​
60​
96​
​
​
12/23/2019​
75​
95​
5,782​
​
01/15/2020​
90​
94​
6,172​
390​
02/04/2020​
105​
93​
6,310​
138​
03/13/2020​
120​
92​
6,647​
337​
10/19/2020​
135​
91​
8,178​
1,531​
09/16/2021​
150​
90​
9,395​
1,217​
05/20/2022​
165​
89​
10,532​
1,137​
11/12/2022​
180​
88​
12,082​
1,550​
04/11/2023​
195​
87​
13,535​
1,453​
08/25/2023​
210​
86​
15,038​
1,503​
Click to expand...

many thanks...............but will running the self-test non-stop slow down the pc ?....i'm running just a AMD Ryzen 3200G processor............my MX500 is 250GB though so 1% drop in life after over 600GB written is slightly under your average since you're using a 500GB unit
 
Upvote 0 Downvote
No, the selftest doesn't use the cpu. (And it doesn't slow down the ssd read/write speed, because selftesting is a lower priority ssd task than reading and writing.) The cpu thread that executes the .BAT file spends most of the time in a halted state, using a timer command to wake it after 19.5 minutes, when it sends an "abort selftest" command to the ssd. Then the thread sleeps for 30 seconds, then it sends the "start selftest" command to the ssd. (Then the cycle repeats, beginning again with another "wake me after 19.5 minutes" command.) The actual active cpu time of that thread is only a fraction of a second every 20 minutes, which is why I began by saying it "doesn't use the cpu."
I too have a Ryzen 3200G cpu. To extend its lifespan, I set the BIOS to cap its maximum power dissipation. It won't get above about 60 degrees Celsius on cpu-intensive activities (such as the weekly virus scan). I also set the cpu's cooling fan to spin fast at a temperature lower than the BIOS default, to keep the cpu cool. I also run the memory at a voltage lower than rated and slower than rated, to preserve the lifespan of the memory chips. These settings DO reduce the computer's performance, but I haven't noticed a performance problem, so I'm comfortable with the tradeoff.
 
Upvote 0 Downvote
Hello. I hope I am not breaking any community rules by getting of the subject but since it might contribute to the drive's operation, I am posting it here.

Very interesting to read all the pages about the Crucial MX500 SATA SSD's. I just got one, the 1TB version (CT1000MX500SSD1), ordered from Amazon. I have purchased dozens of different HDD's and SDD's and among the first thing I do is examine the packaging and the drive itself along with the date of manufactured. I am not sure that I have the correct information, but it was explained to me not to keep a drive with Manufacturing Date /Shelf Life older than a year. I purchased some drives as new but were perhaps "sitting on a shelf" in unknown environment for few years.

I assume I will be able to determine that after installing OS and look at the SMART values, I just do not feel like formatting, installing OS if the drive end's up being of old version but new as far as unused.

I wonder if any owner of Crucial MX500 SATA SSD's can see the manufacture date on the drive itself or on the box. Since the significant hardware changes the MX500 brings over the years (controllers, DRAM, PLP and so on). Also, I have never run into a drive or a RAM stick without a manufacturing date on the sticker of the drive.

Any advise would be appreciated. Thank You!
 
Upvote 0 Downvote
This marketing photo would suggest that the first 4 characters of the serial number reflect the year (YY) and week (WW) of manufacture.


crucial-mx500-2tb.jpg
 
Upvote 0 Downvote
Lucretia19 said:
No, the selftest doesn't use the cpu. (And it doesn't slow down the ssd read/write speed, because selftesting is a lower priority ssd task than reading and writing.) The cpu thread that executes the .BAT file spends most of the time in a halted state, using a timer command to wake it after 19.5 minutes, when it sends an "abort selftest" command to the ssd. Then the thread sleeps for 30 seconds, then it sends the "start selftest" command to the ssd. (Then the cycle repeats, beginning again with another "wake me after 19.5 minutes" command.) The actual active cpu time of that thread is only a fraction of a second every 20 minutes, which is why I began by saying it "doesn't use the cpu."
I too have a Ryzen 3200G cpu. To extend its lifespan, I set the BIOS to cap its maximum power dissipation. It won't get above about 60 degrees Celsius on cpu-intensive activities (such as the weekly virus scan). I also set the cpu's cooling fan to spin fast at a temperature lower than the BIOS default, to keep the cpu cool. I also run the memory at a voltage lower than rated and slower than rated, to preserve the lifespan of the memory chips. These settings DO reduce the computer's performance, but I haven't noticed a performance problem, so I'm comfortable with the tradeoff.
Click to expand...


many thanks for the info, Lucretia.............if the amount of writes per 1% drop continue to get worse, i will try out the file that you posted.........i was worried the self-tests will somehow slow down the pc too much or cause some other bigger problems
 
Upvote 0 Downvote
worstalentscout said:
life just dropped to 81%..............

247 erases..........13,075 GB written.........

write amplification...........1.74..........:disrelieved:
Click to expand...

life just dropped to 80%..............

260 erases (so life drops 1% per 13 erases)..........13,697 GB written (622GB written compared to 626GB written for last 1% drop in life).........😒

write amplification...........still 1.74......
 
Upvote 0 Downvote
worstalentscout said:
life just dropped to 80%..............

260 erases (so life drops 1% per 13 erases)..........13,697 GB written (622GB written compared to 626GB written for last 1% drop in life).........😒

write amplification...........still 1.74......
Click to expand...

life just dropped to 79%.............. :bounce:

273 erases (so life drops 1% per 13 erases)..........14,330 GB written (633GB written compared to 622GB written for last 1% drop in life)........:hello:

write amplification...........still 1.74......
 
Upvote 0 Downvote
worstalentscout said:
life just dropped to 79%.............. :bounce:

273 erases (so life drops 1% per 13 erases)..........14,330 GB written (633GB written compared to 622GB written for last 1% drop in life)........:hello:

write amplification...........still 1.74......
Click to expand...

life just dropped to 78%..............

14,951 GB written (621GB written compared to 633GB written for last 1% drop in life)........😒

write amplification...........up to 1.75...... :disrelieved:
 
Upvote 0 Downvote
worstalentscout said:
life just dropped to 78%..............

14,951 GB written (621GB written compared to 633GB written for last 1% drop in life)........😒

write amplification...........up to 1.75...... :disrelieved:
Click to expand...

life just dropped to 77%..............

15,553 GB written (602GB written compared to 621GB written for last 1% drop in life)........

write amplification...........up to 1.75......
 
Upvote 0 Downvote
4th Annual Report of Effect of Nearly-Nonstop Selftests on Crucial MX500 SSD - 3/02/2024

SUMMARY: The selftests regime continues to effectively reduce the SSD's buggy Write Amplification, and there have been no signs of negative consequences (other than the one expected: slightly increased power consumption due to the SSD not entering the "idle" low power mode).

The nearly-nonstop SSD selftests have been running for 4 years, since 2/23/2020. During these 4 years, the Write Amplification Factor (WAF) has been 3.08. The SSD’s Remaining Life decreased by 7.6%, from 92.2% to 84.6% (as of 2/26/2024). Extrapolating, Remaining Lifetime is 45 years. Extrapolating instead from the 5 week period prior to the start of the selftests regime (1/15/2020 to 2/22/2020), Remaining Lifetime would presumably now be about 1 year if the selftests regime had not been running.

I still suspect some excess Write Amplification relates to the time the SSD has been on since it was last powered off. So when I notice daily WAF has exceeded 4.0 for a few days (about once per month) I sleep the pc for a few seconds, and I briefly shut down the pc when Windows requires a restart (about once per month). However, I haven't rigorously verified the correlation.

LOG OF SSD REMAINING LIFE:

Remaining Life %​
Date​
Total Host Writes (GB)​
Host Writes (GB) since previous RL decrement​
Days since previous RL decrement​
Host Writes / Days (GB/day),
1 row​
100​
07/28/19​
0​
​
​
​
99​
08/31/19​
1772​
1772​
34​
52.1​
98​
not logged​
not logged​
​
​
​
97​
not logged​
not logged​
​
​
​
96​
not logged​
not logged​
​
​
​
95​
12/23/19​
5782​
​
​
​
94​
01/15/20​
6172​
390​
23​
17.0​
93​
02/04/20​
6310​
138​
20​
6.9​
92​
03/13/20​
6647​
337​
38​
8.9​
91​
10/19/20​
8178​
1531​
220​
7.0​
90​
09/16/21​
9395​
1217​
332​
3.7​
89​
05/20/22​
10532​
1137​
246​
4.7​
88​
11/12/22​
12082​
1550​
176​
8.8​
87​
04/11/23​
13535​
1453​
150​
9.7​
86​
08/25/23​
15038​
1503​
136​
11.1​
85​
12/30/23​
16563​
1525​
127​
12.0​



HISTORICAL BACKGROUND:
Early in 2020, after my MX500 SSD had been in use about 5 months, its Write Amplification was very excessive and growing worse. During the 5 weeks prior to the start of the selftests regime, the Write Amplification Factor (WAF) was 45.63. Logging of SMART attribute F8 (every second for several hours) revealed bursts of writing by the SSD to itself many times per day, each burst approximately 37,000 NAND pages (about 1 GByte) or a small integer times that amount. Each burst lasted about 5 seconds, or a small integer times about 5 seconds. The write bursts correlated perfectly with a well-known MX500 bug: Current Pending Sector Count occasionally briefly becomes 1 (which triggers alerts by software that monitors SMART data).

I guessed that the SSD firmware routine responsible for the excess writes might have lower runtime priority than an SSD selftest (which reads SSD blocks to check for issues). Testing showed the guess is correct: while a selftest is running, there are no write bursts. Benchmark testing showed selftests don't reduce read or write performance. So I wrote a .BAT script to automatically run SSD selftests nearly nonstop, to drastically reduce the runtime available to the SSD's buggy routine. The selftests regime was begun in late February 2020 and has been running ever since (24 hours per day except for occasional maintenance or power outages). I also wrote a .BAT script that logs SMART data in comma-delimited format daily and every 2 hours, and I copy/paste all the daily data into a spreadsheet for analysis.

In late February 2020, I experimented to try to find the optimal duty cycle of the selftests, to optimize the health of the SSD. Nonstop selftests reduced the SSD's daily WAF to less than 2. I settled on 19.5 of every 20 minutes. The 30 seconds pauses between selftests are available to the SSD firmware to run any low priority tasks essential for SSD health. Examination of logged data showed that most 30 seconds pauses contain no write bursts, so it seems a good bet that pausing the selftesting for 30 seconds every 20 minutes provides sufficient runtime for essential low priority tasks, if there are any.
 
Upvote 0 Downvote
Lucretia19 said:
4th Annual Report of Effect of Nearly-Nonstop Selftests on Crucial MX500 SSD - 3/02/2024

SUMMARY: The selftests regime continues to effectively reduce the SSD's buggy Write Amplification, and there have been no signs of negative consequences (other than the one expected: slightly increased power consumption due to the SSD not entering the "idle" low power mode).

The nearly-nonstop SSD selftests have been running for 4 years, since 2/23/2020. During these 4 years, the Write Amplification Factor (WAF) has been 3.08. The SSD’s Remaining Life decreased by 7.6%, from 92.2% to 84.6% (as of 2/26/2024). Extrapolating, Remaining Lifetime is 45 years. Extrapolating instead from the 5 week period prior to the start of the selftests regime (1/15/2020 to 2/22/2020), Remaining Lifetime would presumably now be about 1 year if the selftests regime had not been running.

I still suspect some excess Write Amplification relates to the time the SSD has been on since it was last powered off. So when I notice daily WAF has exceeded 4.0 for a few days (about once per month) I sleep the pc for a few seconds, and I briefly shut down the pc when Windows requires a restart (about once per month). However, I haven't rigorously verified the correlation.

LOG OF SSD REMAINING LIFE:

Remaining Life %​
Date​
Total Host Writes (GB)​
Host Writes (GB) since previous RL decrement​
Days since previous RL decrement​
Host Writes / Days (GB/day),
1 row​
100​
07/28/19​
0​
​
​
​
99​
08/31/19​
1772​
1772​
34​
52.1​
98​
not logged​
not logged​
​
​
​
97​
not logged​
not logged​
​
​
​
96​
not logged​
not logged​
​
​
​
95​
12/23/19​
5782​
​
​
​
94​
01/15/20​
6172​
390​
23​
17.0​
93​
02/04/20​
6310​
138​
20​
6.9​
92​
03/13/20​
6647​
337​
38​
8.9​
91​
10/19/20​
8178​
1531​
220​
7.0​
90​
09/16/21​
9395​
1217​
332​
3.7​
89​
05/20/22​
10532​
1137​
246​
4.7​
88​
11/12/22​
12082​
1550​
176​
8.8​
87​
04/11/23​
13535​
1453​
150​
9.7​
86​
08/25/23​
15038​
1503​
136​
11.1​
85​
12/30/23​
16563​
1525​
127​
12.0​



HISTORICAL BACKGROUND:
Early in 2020, after my MX500 SSD had been in use about 5 months, its Write Amplification was very excessive and growing worse. During the 5 weeks prior to the start of the selftests regime, the Write Amplification Factor (WAF) was 45.63. Logging of SMART attribute F8 (every second for several hours) revealed bursts of writing by the SSD to itself many times per day, each burst approximately 37,000 NAND pages (about 1 GByte) or a small integer times that amount. Each burst lasted about 5 seconds, or a small integer times about 5 seconds. The write bursts correlated perfectly with a well-known MX500 bug: Current Pending Sector Count occasionally briefly becomes 1 (which triggers alerts by software that monitors SMART data).

I guessed that the SSD firmware routine responsible for the excess writes might have lower runtime priority than an SSD selftest (which reads SSD blocks to check for issues). Testing showed the guess is correct: while a selftest is running, there are no write bursts. Benchmark testing showed selftests don't reduce read or write performance. So I wrote a .BAT script to automatically run SSD selftests nearly nonstop, to drastically reduce the runtime available to the SSD's buggy routine. The selftests regime was begun in late February 2020 and has been running ever since (24 hours per day except for occasional maintenance or power outages). I also wrote a .BAT script that logs SMART data in comma-delimited format daily and every 2 hours, and I copy/paste all the daily data into a spreadsheet for analysis.

In late February 2020, I experimented to try to find the optimal duty cycle of the selftests, to optimize the health of the SSD. Nonstop selftests reduced the SSD's daily WAF to less than 2. I settled on 19.5 of every 20 minutes. The 30 seconds pauses between selftests are available to the SSD firmware to run any low priority tasks essential for SSD health. Examination of logged data showed that most 30 seconds pauses contain no write bursts, so it seems a good bet that pausing the selftesting for 30 seconds every 20 minutes provides sufficient runtime for essential low priority tasks, if there are any.
Click to expand...

if the WAF is over 3.0 for over 4 years.............how come the Life Remaining only dropped over 7% in 4 years ??!!
 
Upvote 0 Downvote
worstalentscout said:
if the WAF is over 3.0 for over 4 years.............how come the Life Remaining only dropped over 7% in 4 years ??!!
Click to expand...

That's due to the low rate of writing by the host pc to the ssd: approximately 10 TB over 4 years (shown in my annual report). Most users' computers write to ssd at a much higher rate, and then the excess writing by the ssd bug is a smaller fraction of the total writing and is harder for users to notice.

Some of my early posts described steps I took to reduce unnecessary writing to the ssd... mainly by changing the write destination to a hard drive. One example is Windows' incessant logging of events, which by default is written to folders on the C: system drive... the ssd. (Windows updates can revert the destination back to the default location. This is another Windows annoyance.) Another example: Firefox used to frequently write to its cache folder, which by default is on the C: drive. Another example: The PowerPanel software supplied with my CyberPower UPS frequently logs data related to the UPS battery, by default to the C: drive. Although the hard drive is slower than an ssd, I think the changed destination actually increases system performance, because the data is first written to the hard drive's ram cache at high speed, after which the hard drive copies the data from its cache to its magnetic storage while the computer is free to read or write from/to the ssd. (That's just a natural advantage of having more than one drive in a system, to share the load.)
 
Upvote 0 Downvote
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom