[SOLVED] mx500 SSD not performing right?

Feb 14, 2020
7
0
10
on user bench mark it really gives me a terrible rating for my SSD drive. It is a crucial mx500 250 gigs.. I tried crystal diskmark and it seems the write speeds look slower than they should be as well.
Any ideas?
 
Solution
Write caching should always be enabled but especially with SSDs, they're designed with it in mind, for both performance and endurance. Write deferment improves endurance for two reasons: one, it reduces unnecessary writes (lower write amplification) and two, it writes sequentially (not randomly) which also reduces NAND wear. Nowadays consumer drives have SLC caching - portion of the TLC in single-bit mode - so this is a bit more complicated, but that's the general idea. For performance it's also improved because it can have optimal parallelization (esp. important for SSDs vs. HDDs). SSDs also rely on DRAM (and/or SRAM) for the flash translation layer (FTL) which handles metadata (data about data - mapping/addressing, garbage...
Feb 14, 2020
7
0
10
well this site won't allow me to post a screen shot.. Says my message can't go through because of spam.. very weird. So i guess ill type out my results.
Q8t1 Read- 561.95 Write 156.89
Q1T1 Read-507.14 Write 154.38
Q32T16 Read 299.79 Write 12.09
Q1t1 RND4k Read 56.57 Write 10.00
 
Interesting call.. seems that the write caching is off.. perhaps i shut it off and forgot when I was overclocking my CPU... Where it says write caching policy, the box wasn't checked.

SSDs are designed to have write-caching enabled due to how they work, it has a very noticeable impact on write performance. SSDs also often rely on volatile cache (DRAM) for metadata, so the importance of power protection is especially high. It's why people who tell you not to use write caching are very wrong, but also shows one reason SSDs are prone to sudden failure. Maintain your systems!
 
Last edited:
Feb 14, 2020
7
0
10
SSDs are designed to have write-caching enabled due to how they work, it has a very noticeable impact on write performance. SSDs also often rely on volatile cache (DRAM) for metadata, so the importance of power protection is especially high. It's why people who tell you not to use write caching are very wrong, but also shows one reason SSDs are prone to sudden failure. Maintain your systems!

Yeah it says about battery power. I don't have a battery backup power.. I am not using a laptop but a PC.. Should I just keep it off to play it safe?

I put write caching on and tested it, and the speeds dramatically increased.. I totally forgot that I took off write caching. Thanks for thinking of that so fast.. I guess that was my problem and i Just completely forgot about it.
 
Last edited:
Write caching should always be enabled but especially with SSDs, they're designed with it in mind, for both performance and endurance. Write deferment improves endurance for two reasons: one, it reduces unnecessary writes (lower write amplification) and two, it writes sequentially (not randomly) which also reduces NAND wear. Nowadays consumer drives have SLC caching - portion of the TLC in single-bit mode - so this is a bit more complicated, but that's the general idea. For performance it's also improved because it can have optimal parallelization (esp. important for SSDs vs. HDDs). SSDs also rely on DRAM (and/or SRAM) for the flash translation layer (FTL) which handles metadata (data about data - mapping/addressing, garbage collection/maintenance/TRIM, wear-leveling, page-caching) and this also benefits from the write caching because it too can defer writes to the flash (there's always a non-volatile copy) and also write-combine (make the request nice and sequential). So for these reasons it's inadvisable to disable write-caching for SSDs.

That being said, having a stable system with a surge protector and UPS (or battery) is ideal when using any type of storage but especially SSDs. When power is lost, they have a small amount of time to commit writes to the drive, this being both metadata and data updates. Windows is pretty good with this and you'll usually just lose immediate data in open applications if anything but over time if there's mapping corruption you can secure erase the drive to restore it usually. Keep in mind that you should always have a backup system in place. In other words, write-caching should always be enabled since you're at risk of data loss at all times regardless.
 
Solution
Feb 14, 2020
7
0
10
Write caching should always be enabled but especially with SSDs,...............

Thanks for that thorough explanation I appreciate it. I now remember shutting it off when I was overclocking.. Now playing VR games I been having weird windows crashes out of no where and blue screens of death. Not sure if it was an update that caused it or my video card driver not being updated in awhile. I'm a little scared to enable the write caching now with these crashes because I don't have a battery back up or anything backed up. I don't have room to back up the harddrive anywhere.
 
Understood.

This forum doesn't specifically cover that issue but obviously I have a ton of experience with overclocking and instability. My go-to is 8+ hours of Prime95 Blend - you can disable AVX if necessary - and I know many people say not to use it or to use e.g. RealBench instead. I can assure you, you can pass 8 hours of RB and fail within minutes in P95. For memory testing I suggest HCI Memtest (free, you have to tweak it) or Karhu (paid), amount of coverage is a complex question but it's in the 12+ hour range. If both of those tests pass you go to Unigine Valley and set Afterburner/HWInfo/whatever to log so you can see if there was a VPU recovery (core clocks drop out) during an 8+ hour pass, that is if you don't outright see artifacts. For PSU testing I actually use specific games - Rainbow Six Siege is notorious, for example. For driver issues you use LatencyMon to track down potential sources. If you have actual BSODs you can use WinDbg tools with the dumps. Hmm, I think that covers most things.
 
Feb 14, 2020
7
0
10
I have used prime 95 on a custom setting, but definitely didn't do an 8 hour test.. i forgot how long exactly i ran it for, but the forum members at overclock.net seemed to think it was fine. I haven't had any trouble since then... which has been quite awhile.. All of the sudden now I get the problem during VR applications. My guess is it's something to do with recent updates .. I got the blue screen of death. I looked at the error log and it just said kernel power event 41 task 63