1

I have Adata SU SATA SSD. 480GB. It’s about 1 year old and so far hardly 2 TB are written to it. The estimated life is I believe 150 TBW. These days when I test it with Crystaldisk mark on Windows 10, just once a while, not always, (completely random) the write speed sequential is shown as just 30 MB/s. Almost all other times it's about 400 MB/s. Tested with a chunk of 512MB or 1 GB data from within the app.

When I copy a single large file and check the progress, most of the time it’s about 200Mb/s but intermittently for the same time, it can drop to literally 35 Mb/s. I understand it could be normal when you copy 100’s of smaller files but here it’s a single very large file like a virtual hard disk file about 9 GB in size.

See the attached screenshot of the progress.

Does this mean there are worn-out areas on this SSD?

Or does it mean that there’s no contiguous block available to store 9GB in one go, so intermittently the file is stored in smaller chunks so momentarily speed drops? i.e. the file copy operation is sort of split between sequential + random I/O? Adata’s own app 'SSD toolkit' shows health as 100% good with 100% life remaining.

Does Crystaldiskmark verify the availability of a full sequential chunk of free space before testing? As mentioned, it also sometimes shows 30Mb/s sequential.

Edit - The SSD is inside the laptop. There are no SATA cables.

The model is Adata SU650. If that helps to add any more relevant details in the context of the question.

Also attached ssd toolbox screenshot showing Good status.

enter image description here

enter image description here

SMART results

enter image description here

4
  • 1
    "Does this mean there are worn-out areas on this SSD?" -- No. "Or does it mean that there’s no contiguous block available to store 9GB in one go" -- A "slowdown" when writing to NAND flash has little to do with contiguous blocks. It's the erase procedure that is time consuming. Beware that you're "measuring" speed from the host side of the SATA interface. You really have no insight as to what the drive is actually performing other than the transfer over the SATA interface.
    – sawdust
    Dec 2, 2021 at 7:28
  • Is your drive perhaps relatively full? All in all, it appears this is a rather low-performance SSD in general.
    – Daniel B
    Dec 2, 2021 at 9:09
  • Please add a screenshot of the SMART data for the disk.
    – harrymc
    Dec 2, 2021 at 12:23
  • SSDs are not written in contiguous blocks. This is why you cant defragment them. They are intentionally fragmented. This is called "wear leveling." The SSD writes all over the disk so that the cells are used equally to prevent the first from wearing out before the last. Since SSD have near instant seek time, this is not an issue as it would be in hard disk drives.
    – Keltari
    Dec 2, 2021 at 19:23

1 Answer 1

1

It could be an issue with the SSD, or with its firmware.

At work, we had two computers with ADATA SU650 SSDs that would drop to tens of MB/s read speed, sometimes even KB/s for certain sectors, with nothing unusual reported in SMART data or anywhere else. (The SSDs were only a year old.) They only recovered to normal after using an ATA "Enhanced Secure Erase".

I have Adata SU SATA SSD. 480GB.

You didn't mention the model. A lot of ADATA SU-series SSDs use QLC flash, and QLC flash is slow. (From what I could find, SU630 is QLC, though SU650 is probably not? Still unclear on that.)

Typically SSDs have some amount of very fast "write cache" SLC flash where writes go first (and then transferred to main flash), but if the entire copy doesn't fit in the write-cache, you'll begin writing directly to the main flash memory and the speed will drop accordingly.

It's not the only cause of slow write speeds, but it's a thing.

Or does it mean that there’s no contiguous block available to store 9GB in one go, so intermittently the file is stored in smaller chunks so momentarily speed drops? i.e. the file copy operation is sort of split between sequential + random I/O?

"Contiguous block" doesn't matter. Even on an HDD, if the filesystem had to start another extent elsewhere, it'd only have to seek once and the write speed would quickly return to maximum again.

(I think it doesn't make sense for it to be random blocks scattered around in the middle of a copy – even if the filesystem was so full and incredibly fragmented that the FS couldn't find a place to put larger extents, then it would continue all the way through, not suddenly return to normal.)

But with an SSD, when you don't have a mechanical read/write head and therefore no "seek time", there is no difference between a single contiguous 1GB extent and 10 smaller ones. (And it won't be contiguous physically either way, as logical sector numbers don't map 1:1 to flash storage – all SSDs have a "flash translation layer" which will map writes to whatever physical flash sectors it considers least-worn.)

2
  • Thanks a lot for such a detailed answer +1 from me. The model is Adata SU650 in case there's anything specific to add about this model in your answer. As of now though there's some backup, at this moment secure erase is a bit difficult to undertake. But will try that option sooner or later. I think they say SU650 has something called SLC. I don't know what it means.
    – ramki
    Dec 2, 2021 at 8:55
  • SLC (single-level) is the "very fast but low-density" flash type used for write caches, while the main storage is MLC/TLC/QLC (2/3/quad-level), increasingly higher densities and lower speeds, where mid-tier SSDs usually use TLC while budget ones have QLC as the main flash type. Dec 2, 2021 at 9:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .