Products > Computers

NVME read speed

(1/4) > >>

dunkemhigh:
Trying to sort out an issue with an NVME drive. The problem is that it's slow. Really slow, like sometimes <1MB/s during backups. This is read speed and is difficult to pin down. A Crystal Disk Mark test shows nothing untoward, but do a backup and after a little bit of full speed stuff it slows to a crawl. Eventually I replaced the SSD with a WDC job, and things are back to being fast again.

Except... I ran the HD Tune benchmark on both the current WDC and previous Silicon Power, and noticed that read speed is slower where there is data. On the SP, which was the problem drive, it is really really pronounced so I thought there was some fault in the drive. But now I notice that the WDC is showing the same symptom, although in use it's not apparent. The attached benchmark for the WDC illustrates the issue.

[attach=1]

The HD Tune benchmark is really aimed at spinning disks, so it starts at sector 0 and then reads sequentially to the end sector. It ignores any filesystem and just hits the disk direct, whether there is actual data there or not. The graph shows the start of the drive on the left, the end on the right.

This drive has 5 partitions with a little free space for expansion between them. The dips correspond to partitions, and the peaks between them to the free space. Only the first 500GB is in use (the rest is for expansion/wear). Seems pretty clear to me that where there is actual data the read speed is slower than where there isn't.

I tried to force CDM to use the trough for benchmarking, but it writes the data it's going to read first, so of course it's going to be a relatively unused space. It also only shows an average, which can hide what we can see here.

I find it strange that this effect should exist. Am I missing something that might explain it, or is it a real thing? I note that SATA SSDs don't show this, but then the read spead is substantially slower than the chip capability so may be hiding the same thing.

Marco:
AFAIK they generally detect formats and zero writes and just mark the block as zero in the metadata, reading just the metadata to return all zeros is obviously going to be faster.

olkipukki:

--- Quote from: dunkemhigh on December 01, 2021, 07:47:35 pm ---Trying to sort out an issue with an NVME drive.

--- End quote ---

Why do you think you have NVME and not SATA?   ???

mariush:
If he gets speeds higher than ~560 MB/s, he has a nvme SSD.

I have some issue with your comments about leaving some room for expansion and for wear.

There's no need to leave unused space for "wear" - the SSD controller doesn't store the data like a mechanical drive, data ends up at some random offset in one of the flash memory chips and there's a translation table stored in the SSD which keeps track of where the data of a particular sector is actually located in the nand chips.

So whether you leave some room for "wear" or not, those flash blocks will be used just like any other flash memory so it's pointless to not have it included in a partition.

Also note that modern SSDs use a portion of the flash memory in pseudo-SLC mode, for caching writes - that's another reason why data is more or less random on the ssd.

For example, in the case of your 1 TB SSD which uses TLC memory (3 bit per cell), the SSD controller can take up to maybe 400 GB worth of TCL memory and flip it to pseudo-SLC memory storing just 1 bit in every cell.
Those 400 GB of TLC end up to maybe 256 GB of SLC memory - these are not the exact numbers, I don't feel like looking the exact values, but it's not that critical - so if you write something to the SSD, it gets quickly dumped in this portion of SLC memory and later when the SSD is idle, the data is moved to regular TLC memory emptying the SLC cache.

As you fill the drive with data, the ssd controller has to "release" chunks of the pseudo-SLC cache, converting that back to TLC ... for example, if there's 50 GB empty space, the controller takes 16 GB of pseudo-slc memory and converts it back to 20-24 GB of TLC memory and now you have 70-74 GB of free space.

So HDTach doesn't do the SSD a favor by requesting data sector by sector, in a linear fashion. The SSD controller has to constantly look up into its internal translation table to see where exactly is sector 0 stored, then sector 1, and so on...

dunkemhigh:

--- Quote from: olkipukki on December 01, 2021, 08:18:02 pm ---
--- Quote from: dunkemhigh on December 01, 2021, 07:47:35 pm ---Trying to sort out an issue with an NVME drive.

--- End quote ---

Why do you think you have NVME and not SATA?   ???

--- End quote ---

Because it's not an SATA interface, it's sold as NVMe, the connector is NVMe, it's reported as NVMe, and when it's fast it's MUCH faster than SATA.

Other than that, dunno :)

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version