SSD Speed/Reliability

Feb 10, 2026 Last reply: 5 months ago 4 Replies

I have my fancy new Startech USB 3.2 card and my Terramaster DAS and I'm getting the following using AS SSD benchmark over 6 test runs:



Crucial BX 500 4TB



Read 134 to 282 MB/s Write 33 to 447 MB/s



Crucial MX 500 2TB



Read 382 to 447 MB/s Write 328 to 454 MB/s



The MX 500 is pretty solid, they were good drives, but the BX 500 worries me. I swapped them over in the Terramaster and got similar results.



Is the BX 500 going to die on me? It doesn't matter what sort of flashy kit drives it if it fails :-(



I had 2 x WD SSDs and 1 x Crucial die on me last year and they went overnight catastrophically, couldn't read a thing on them. Data is backed up several times but the plan was for this to be my "grab it and run" DAS in the vent of an emergency.



CrystalDiskInfo returns 0 for all SMART data so I don't think it can read it?


That can happen with a bad interface chip. I only had one do that, shirtly after purchase. Kingston IIRC

Probably. Did they all go at once?

Ive had zero issues with any ssds since that one went. many years ago,

The BX is the budget version, so not surprised that it's slow. It also has lower endurance, but still plenty.

I have a pair of BX drives that have been running for several years with no problem. I'm relaxed enough, as they are in a mirror.

With benchmarks, it seems your choices are the obviously wrong ones (the old version of HDTune), or, the other tools give rather optimistic values and tightly clustered at that.

[Picture] If picture is fuzzy, use "Download Original"

formatting link
W10/W11 seem to have trouble with timekeeping, and I spent a couple days playing with code and trying the various routines, with no good result from the work. Even the routine with the very long name, claiming "a timepiece as accurate as the filesystem clock" could not make a convincing real time clock. I guess I'm just not TimeLord material.

CrystalDiskMark seemed to produce a decent result. But it is less good than a graph style thing, for determining health.

The GnomeDisks bench in LinuxMint gives nice numbers, but the drives are awfully close to one another during read, and this is suspicious, because the NS100 drive included in the test, is normally "a few paces off the others". In practice, those three drives are not the same.

The seek dots seem to indicate a little wear around the edges, and that's probably the most indicative thing in the graphs.

The first bench at the top, I didn't let that finish, because it didn't look like a keeper. But even my "special" quiet-mode run using a Macrium Rescue CD as an OS, still could not get into the 500MB/sec domain.

Summary: Get yourself a copy of CrystalDiskMark and pretend all is grand.

Paul

Paul

What does the QNAP NAS look like, in terms of protocols ? Does the OS "like the taste of that connection" ? Or does it require some sort of special driver ?

There were at one time, NAS and NDAS, and the second one had a custom driver you installed on each PC.

Benchmarking tools, can work at a couple different levels. They can work at the physical (sector) level and require Administrator to do so.

Or, they can run at user level and work through the filesystem, which produces a pessimistic value for "speed". Going through a filesystem can be slower, to a lot slower.

I don't have a NAS here, so don't have any first hand experience with such.

As for testing recently purchased devices, I would not put them in the NAS at first. I would check them out in my desktop machine (assuming a port is available for connection) and then run my bench. On the assumption that, at least the connector on the NAS works in much the same way, and any other slowdowns on the NAS side, are caused by the software stack in the NAS. That's why when I ran the Linux test on my daily driver, I put the three SSDs on the three SATA cables, and the OS was a Live Session that I did a TORAM=yes on so that the distribution files were in RAM.

When TLC storage devices sit on the shelf at the store, the TLC gets "mushy", the ARM Cores are busy doing error correction on every sector, the situation looks "bad". But when the device is written once from end to end, that "makes the numbers look better". At that point, the sectors do not need correction and should be in better shape (for the next three months).

Paul

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required