Review Index:
Feedback

Crucial MX500 2.5" SATA SSD Review - Make SSDs Affordable Again

Subject: Storage
Manufacturer: Crucial

Performance Comparisons - TRIM Speed

Thanks to the plethora of data we have at our disposal from the new suite, I can derive some additional interesting data that nobody seems to have been paying any attention to yet. Have you ever deleted a large file and then noticed your system seem to hang for some time afterward? Maybe file moves from your SSD seemed to take longer than expected?

View Full Size

That's your problem right there. In the above capture, a 16GB file was deleted while a minimal level of background IO was taking place. Note how that IO completely stalls for a few seconds shortly after the file was deleted? That's a bad thing. We don't want that, but to fix it, someone needs to measure it and point it out. Enter another aspect of our new testing:

View Full Size

Latency Percentile data was obtained while running a 'light' (1000 IOPS) workload in the background while files of varying sizes were deleted. The amount of latency added during the deletions was measured, compared with a baseline, and correlated with the sizes of the deleted files. The result is how much latency is added to the active workload per GB of file size that was deleted. In short, this is how long you may notice a stutter last after deleting a 1GB file.

To avoid confusion, I've maintained the performance-based sort from the mixed test for these charts. Here you can tell that some drives that did perform well on that test stick out a bit here when it comes to how they handle TRIM. Ideally, these results should all be as close to 0.000 as possible. Higher figures translate to longer performance dips after files have been moved or deleted.

View Full Size

This is another result sourced from a different segment of data. While our suite runs, it issues a full drive TRIM several times. Some of those times it is done on an empty SSD, others is it done on a full SSD. Any difference in time taken is measured and calculated, normalizing to a response time per GB TRIMmed. In short, this is how long an otherwise idle SSD would hang upon receiving a TRIM command for a 1GB file. These times are shorter than the last chart because the SSD controller does not have to juggle this TRIM with background activity and can throw all of its resources at the request.

Looks like we found a chink in the armor. The MX500 delayed accesses by nearly 1/2 second per GB of data deleted/TRIMmed, and clearing the entire 1TB volume (as seen with an OS reinstall or repartitioning a previously full SSD) took nearly two full minutes (107 seconds). Now, this isn't a deal breaker, but it is something to be aware of considering your specific use case.

Below are more results for this valuable metric, sorted by performance. Note that the oldest SSDs (X25-M) are N/A here because they did not employ TRIM:

View Full Size

View Full Size


December 19, 2017 | 09:14 PM - Posted by LostInTheLongLists (not verified)

Now go back on those long lists of SSD tested and put a red box around the SSD being tested because that's some haystack of results to visually search through to see where the drive being tested compares to all those others in that very long List.

December 19, 2017 | 10:14 PM - Posted by Humanitarian

You can see the 4k and 128kb scores in the 2 top charts, take that score and scroll down till you get to it.

December 19, 2017 | 11:07 PM - Posted by Allyn Malventano

The SSD being tested is at the top of the abbreviated charts - above the longer charts.

December 19, 2017 | 11:46 PM - Posted by khanmein

Allyn Malventano, Regarding the TRIM issues, can Crucial fix the problem with a firmware update? Thanks.

December 20, 2017 | 04:56 PM - Posted by Allyn Malventano

Most likely, yes.

December 20, 2017 | 08:00 AM - Posted by John H (not verified)

Looks like a solid alternative to 850 evo..

December 20, 2017 | 09:09 AM - Posted by Cyclops

Allyn, what do you think of a MLC SSD with TLC cache?

December 20, 2017 | 10:20 PM - Posted by RealExascale (not verified)

TLC is slower than MLC, which itself is slower than SLC. Micron has SLC mode caching for their smaller MLC/TLC drives because it improves speed.

A TLC cache would hurt performance.

I have the 1TB MLC Crucial MX200, which has enough flash that it doesnt need an SLC cache, however i do use the Momentum Cache which uses system DRAM as a fast cache. Its a good idea if you have a UPS, which i do.

December 20, 2017 | 10:23 AM - Posted by Mobile_Dom

Interesting, I wonder if, with the BX line being the ultra cheap ones, we'll see it move to 3D QLC NAND before long, sure it'll be slower than the others, but it'll be a butt tonne cheaper.

December 20, 2017 | 10:27 AM - Posted by Anonymously Anonymous (not verified)

get back to us when they are at $.10 a GB

December 31, 2017 | 11:37 PM - Posted by Sid (not verified)

Maybe in 5 years

December 20, 2017 | 03:58 PM - Posted by Abdullah Abdul-Rahman (not verified)

With regards to what Jon Tanguy said in the video about Power Loss Immunity eliminating the need for banks of capacitors - they were pretty cool to look at: https://i.imgur.com/wVXxOre.jpg

December 20, 2017 | 10:46 PM - Posted by Anonymous.. (not verified)

How does it compare with MX300?

December 23, 2017 | 02:22 PM - Posted by DaVolfman (not verified)

One of my takeaways is (trim speed aside) the performance on this isn't all that different from a Vector. And the Vector was a monster (an unsafe hotrod that blew a gasket if you cycled power at the wrong time) of a client drive when it came out and was MLC only. It's nice to see a budget TLC drive isn't completely compromised.

December 25, 2017 | 10:46 PM - Posted by Godrilla

Went from a 256 gig c300 at launch to a 500gig mx100, I just might upgrade to a 1 terabyte mx500.
Things are getting a bit saturated.

January 15, 2018 | 06:19 PM - Posted by Tt78 (not verified)

MX500 2TB appears to be 25% cheaper than the 850 EVO 2TB

January 22, 2018 | 11:28 AM - Posted by MrX (not verified)

Maybe the trim results are like that because Crucial MX500 NCQ (Native Command Queuing) TRIM is actually working unlike Samsungs SSDs which have broken NCQ TRIM (this is why 8xx series are blacklisted for NCQ TRIM in Linux kernel).

Is there any test you could do to confirm this? Maybe somehow try to disable NCQ TRIM and then run the tests again. Maybe even run MX500 and 850 EVO in IDE mode instead of AHCI to make sure that NCQ is not a factor.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote><p><br>
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.