Question (Too) Slow SSD NVMe & SATA disks (?)

Jan 28, 2021
45
0
30
0
I always had problems with disks being apparently too slow than their advertised speeds. Way slower. And once gain I have a totally new machine with Windows installed on it from scratch. This time I am running Windows 10 Enterprise 20H2 19042.746 on a Gigabyte X570 Aorus Ultra rev. 1.2 with AMD Ryzen 5 3500X OEM and G.SKILL RipjawsX DDR3 DIMM 2133MHz CL9 16GB (2x8). So my CPU and RAM maybe not be the quickest available, but I have PCI-Express 4.0 and more than enough power from a high-end PSU - and what is more important, I have top notch drives

And the drives tested and their specs are



C
Samsung 980 PRO 500GB = MZ-V8P500BW / R-R-SEC-MZ-V8P1T0


form factor - M.2 2280
interface - PCIe Gen 4.0 x4
interface - NVMe 1.3c
read speed - 6900 MB/s
write speed - 5000 MB/s
cache - 1GB LPDDR4
random read QD 1 Thread - 122K IOPS
random write QD 1 Thread - 160K IOPS
random read QD 32 Thread - 16800K IOPS
random write QD 32 Thread - 161000K IOPS



M
Samsung 980 PRO 1TB = MZ-V8P1T0BW / R-R-SEC-MZ-V8P1T


form factor - M.2 2280
interface - PCIe Gen 4.0 x4
interface - NVMe 1.3c
read speed - 7000 MB/s
write speed - 5000 MB/s
cache - 1GB LPDDR4
random read QD 1 Thread - 122K IOPS
random write QD 1 Thread - 160K IOPS
random read QD 32 Thread - 161000K IOPS
random write QD 32 Thread - 161000K IOPS



P
Samsung 860 EVO 1TB = MZ-76E1T0B


form factor - 2.5"
interface - SATA III
interface - SATA 6 Gbps
read speed - 550 MB/s
write speed - 520 MB/s
cache - 1GB LPDDR4
random read QD 1 Thread 1 - 10K IOPS
random write QD 1 Thread 1 - 42K IOPS
random read QD 32 Thread 16 - 98K IOPS
random write QD 32 Thread 16 - 90K IOPS



Those first two M.2 drives are brand new, while that third one SATA is a 1 year old. All of my drives [for the longest time - i.e. all of the others also and on my previous machines also] are set to: partition style GPT, layout simple, filesystem NTFS, allocation unit size 64 KB

The test were performed with operating system being idle, with CrystalDiskMark 8.0.1 in 4 ways:

1 - size 1GiB - Settings default
2 - size 1GiB - Settings NVMe SSD
3 - size 32MiB - Settings default
4 - size 32MiB - Settings NVMe SSD


So when a screenshot says for example M-4 then it means that it is of the drive M [i.e. Samsung 980 PRO 1TB] with Settings of the CrystalDiskMark having been turned from default to NVMe and with the size set to 32MiB. And now - please take a look at all of those tests results:
gallery showcasing tests from C through M to P - https://imgur.com/a/vzpNSSt


Do they make any sense? SATA being able to write more than 100 times quicker than NVMe [RND4K Q1TA values of e.g. P-4 vs. M-4]? Settings set to default for an NVMe give a better result than when set to NVMe [SQ1M Q8T1 of M-1 vs. M-2 ]? That last one could be explained by assuming that the latter test just happened to come off slower, because such inconsistencies are to be expected - but the why do test for P are consistent with default Settings [P-1 and P-3] despite choosing for the later on a wrong Setting [in P-2 and P-4]?

Should I be maybe performing such tests with my [free COMODO] antivirus being disabled? Should they be empty and not with the operating system running on them?



As for real life situations [with NVMes]. When I copy or move a 10 GB movie file from C to M the transfer starts at ~1.6 GB/s and after few seconds drops to ~1.0 GB/s. But when I do it the other way around, i.e. from C to M, the transfers drops to ~100 MB/s after which it climbs to ~150 MB/s. So few things here are to be explained:

1] That would be logical, as the cache on both of them has 1GB. But it is also illogical when both ways of transit are taken into account. But after checking the box located at

Windows System > Control Panel > Device Manager > Disk drives > [DRIVE] > Properties > Policies >Enable cache writing on the device

the coping / moving that file from M to C sustains ~1.6 GB/s. But from M to C it still drops to ~1.0 GB/s [and C had its cache turned on from the get go]


2] How does real life write 1-1.5 GB/s stack up to the advertised 5000 MB/s?

If turned of cache has such a profound impact - then a user who for data eligibility reasons turns it off, should not buy drives with high write values, because that user is just wasting money on an vastly unused feature? Does it really come down nowadays to the this choice: ultra high speeds [with cache turned on] or more certainty that the data will not be lost because of a power failure [when operating without cache]?


3] If the advertised read speed are 6900 [for C] and 7000 MB/s [for M] and the test sequential read is no lower than 3650 MB/s, then why does it take accordingly around 60 and 300 seconds to load 184 / 392 GB of audio files up to the Mp3tag. Those GBs consist of 18800 / 91250 audio files placed in 1300 / 3800 sub-folders. All Mp3tag is fed with is the path of a o couple of main folders from which it reads all those sub-folders [so it is not looking for some specified files from a playlist] and loads paths of found files and data from tag fields of the recognized formats [and only eligible audio formats are in those folders - so Mp3tag does not have to go through GB of unknown data / thousands of unrecognized items]. Does the sequential read apply to big files and sequential to small ones?

Or is this more or less exactly what I should be getting in terms of reading speeds because [calculating roughly]: 184 GB is 184000 MB thus 184000 divided by 30 seconds equals 6134? But then again: 392 GB is 392000 MB thus divided by 300 gives a value of 1307. Why so vastly different? Are all of those additional folder / path dropping the read speed?


4] Can pagefile.sys set on a given drive slow it down? Drive C is set to 1111-2222 MB but M to 11111-11111 MB - so the now [because of cache also being turned on] quicker drive [M] has in theory 50-100% more of pagefile.sys


5] Is leaving less than 20% of free space on SSD really slowing it down? With only 10% of free space left being much worse than 20%? And does this go for both for SATA and NVMe? Does this affect both writing and reading?


6] How can I speed the loading process of files:

A] Install faster RAM?
B] Install faster CPU?
C] Install CPU with more threads - assuming that Mp3tag is optimized for multi-CPU running?
D] Change allocation unit size from 64 KB to e.g. 1 MB - thus sacrifice space]?
E] Turn on indexing of files?
F] Turn on caching of drive - assuming that Mp3tag writes some temporal file with read data?
 
Jan 28, 2021
45
0
30
0
latest bios? installed samsung magician ?
The manufacturer says to not update BIOS when things are working. And yes- they are [possibly] not working but I also do not want to mess things up

My mobo already was the highest revision of it [designated 1.2] - but nevertheless I did update the BIOS from the one given at the assembly line to version 30. The newest one is 33 but from its description I reckon it has nothing of value for me



I am not using Samsung Magician. Can it somehow boost speeds; unblock some features features maybe concerning this issue?

If I am to use Samsung Magician just for [theoretical] tests then I prefer using a third party too. And if U have to, I would rather indulge myself in some real life situation tests
 

Andrewbandrew05

Prominent
Jun 30, 2019
221
16
595
2
I think the cpu has something to do with read and writes, at least with ram (like mem controller etc). I wonder if your cpu can't handle your drives? I'd try running ATTO disk benchmark to check. Drives will prob not be 100% of rated speeds but they should be at least pretty close. (As long as you haven't like completely filled them up or anything like that)
 
Jan 28, 2021
45
0
30
0
Magician is a testing and diagnostic tool for Samsung drives.

I'm not seeing an "issue" to be "fixed".
I have installed Samsung Magician 6.2.1. Its Performance Benchmark shows total BS

Both NVMe drives are shown to have ~6300 MB/s of sequential read speed. A as for writing, the larger M is suppose to have 585 MB/s and C with the system is supposedly having speed of 2300 MB/s. As in reality my write speed have dropped [for an unknown reason] on both of them to a mere ~550 MB/s

That 2300 MB/s is laughable lie, as even earlier all I could squeeze out was ~1100 MB/s. I wonder, how is it possible that the manufacturer's dedicated software tool shows 200% / 400% of the real speed?



Sure seems like it



So what can I do; like realistically looking? Just sit and wait for some drivers upgrade of motherboard and / or operating system? Can drives themselves have firmware upgrades applied?

Or [assuming I will find money for this] buy another NVMe drive but not from Samsung - and see if it gets near its advertised speeds. And if it works more or less OK - claim a warranty from Samsung on a faulty products?
 

USAFRet

Titan
Moderator
Mar 16, 2013
139,094
7,396
166,440
21,425
Both NVMe drives are shown to have ~6300 MB/s of sequential read speed. A as for writing, the larger M is suppose to have 585 MB/s and C with the system is supposedly having speed of 2300 MB/s. As in reality my write speed have dropped [for an unknown reason] on both of them to a mere ~550 MB/s
550MBs is exactly what the 860 EVO should be doing.

And again, the sequential benchmark number is completely different than transferring several thousand small files.
 
Jan 28, 2021
45
0
30
0
550MBs is exactly what the 860 EVO should be doing.

And again, the sequential benchmark number is completely different than transferring several thousand small files.
But I was referring now to Samsung 980 PRO 500GB [my C] and Samsung 980 PRO [my M]

And again, the sequential benchmark number is completely different than transferring several thousand small files.
For my real life test I am using a 10 GB and 40 GB movie file copied / moved between C and M [disregarding the P drive for now]

So no wonder that my load up of XX XXX files to Mp3tag is suspiciously slow if those two drives cannot even handle a sequencial transfer of literally 1 file
 

ASK THE COMMUNITY

TRENDING THREADS