Question SSD has slow read speed ?

[Klaasz]

hi
correct me if i'm wrong,
I tested below on 3 different servers with 480Gb Raid1 OS disks and several Tb Raid6 spinning disk storage
recently I found that the SSD read performance degrades over time quite dramatically
during install, about 2 years ago, I put some testdata on the C drive, and now the raid6 with spinning disks
is faster to load this test data than the SSD, this wasn't the case initially, so something must be wrong
when running any of the SSD benchmark Tools, it writes a testfile to SSD and does the speed test on that
now the SSD controllers have some tricks up their sleeve to enhance endurance
since the flash cells can do limited P/E cycles, for a 3D or V NAND that is around 1000~3000 cycles
and with each P/E cycle they get a little slower since it's harder to distinguish between the 8 voltage levels (TLC)
the error correction that is needed takes time, and there are more reasons that SSD degrade over time
one of the other tricks the SSD controller has is wear leveling, where it decides on where to put the data depending on the amount of P/E cycles a cell already has done
so the SSD benchmark testfile will be put on relatively fresh NAND flash cells, so basically these benchmaring Tools
are NO good for SSD's that are in use for some time, it only gives reliable results on newer SSD's
on our systems we have Raid controllers with 2Gb cache but for reads they are pass-through, i think HP calls it HBA
among the many SSD benchmark Tools I found 2 that do what i want them to do, and that is READ test the entire area of the SSD
they are old programs, but still do what they supposed to do, HD Tune and HD Tach the latter you even need to run in XP compatibility mode.
now when i run these test, I get below results, where a read speed of 150MB/s is even slower than a spinning disk

now something must be wrong here, i'm wondering if there are any new benchmarking tools that address the disk directly ?

i also ran the test on another 10 year old Intel SSD (MLC), result below, this is what i would expect

below from another system, tested with both HD Tune Pro and HD Tach, 2 independent programs with same result

 

[helpstar]

check if a firmware update is available
check the SSD by the manufacturer tools

 

[Klaasz]

yeah, forgot to mention in my first post but all firmware SDD, disk controller etc are up to date

 

[MWink64]

Big question, what brand/model SSDs are these? I've seen similar, and occasionally much more severe things on a variety of flash media (SSDs, SD cards, and USB flash drives). I've got a few drives (including a Crucial BX500) that will crater below 5MB/s in some areas. I've become a bit enamored trying to figure out what exactly is going on.

Do you know if data in the slow areas is old (written months/years ago)? I often find this to be the case. Overwriting the affected LBAs seems to speed things back up, at least for a while. I used to image, wipe, and restore the BX500 when it got too slow. I've put off doing it recently because I want to see just how slow it will get and if it may even reach the point of losing integrity. It has a very severe impact on performance. I'm not exaggerating when I say it can take 10-15 seconds to load something as simple as Notepad or Paint.

I've recently had the same experience with a couple Samsung USB flash drives that are only about 6 months old. That's what sparked my curiosity about the subject. Interestingly, it doesn't affect all drives, as you saw on the old Intel SSD. A number of drives I tested, ironically many of them low end, had relatively consistent performance throughout (even drives with very old data, some of which have sat unpowered for years).

I have not been able to find a commonality between all the drives that are and aren't affected. Unsurprisingly, MLC drives don't seem to be affected. I have found some TLC drives that are affected and others that aren't. The affected drives I've encountered seem to use either Samsung or Micron NAND. I have yet to find a drive with Kioxia/Toshiba NAND that behaves this way (and I have several low end ones). Many of the affected drives seem to have Silicon Motion (SMI) controllers. I have yet to find a Phison based drive with the issue. The presence/absence of DRAM is not necessarily a factor either.

It was kind of amusing to watch my 2018 SATA Samsung 860 EVO (Samsung controller, Samsung TLC NAND, with DRAM) sometimes outpacing my 2021 NVMe ADATA XPG SX8200 Pro (SMI controller, Samsung 92-layer TLC NAND, with DRAM). Actually, even a 2018 SATA Inland Pro (Phison S11, Kioxia TLC NAND, DRAM-less) did better.

I'd love to know what's going on here. It's an issue that has real implications and sometimes manifests in only weeks/months. It seems to be appreciably more widespread than I initially realized. I'm just so curious why this is happening and this post seems to be one of the only ones I've seen mention it.

By the way, I suspect those faster areas, towards the end of the drive are either newly written or empty, trimmed space.

 

[BFG-9000]

Do your RAID controllers even support TRIM/Discard when in RAID mode? Most hardware RAID controllers only support this when in pass-through mode (ie individual disks in non-RAID) because that's the only time the OS can see the disks directly.

Now theoretically the lack of TRIM should only affect write speed and not read, but you might still try writing zeroes to free space with things like
sdelete -z D:
or
cipher /w😀
where D is the letter of the drive or partition you want to wipe free space on, to see if things improve. At least it's faster than a full wipe and restore!

 

[MWink64]

Do your RAID controllers even support TRIM/Discard when in RAID mode? Most hardware RAID controllers only support this when in pass-through mode (ie individual disks in non-RAID) because that's the only time the OS can see the disks directly.

Now theoretically the lack of TRIM should only affect write speed and not read, but you might still try writing zeroes to free space with things like
sdelete -z D:
or
cipher /w😀
where D is the letter of the drive or partition you want to wipe free space on, to see if things improve. At least it's faster than a full wipe and restore!

In my case, RAID wouldn't be a factor, as I don't use it. In the OP's case, it seems like the end of the drive was either never written, recently written, or trimmed.

His bottom images ("from another system") look very reminiscent of my Crucial BX500. It even has the same large spike near the beginning. My best guess was it's a large, allocated but unwritten area, possibly an unused hiberfile.