Question Slow write speeds on all SSDs ?

[jeffnhardy]

Hi, I've been facing this issue for a couple of months and was wondering if someone has ever faced or has any idea on any other solutions that I may try to fix it.

MSI B450M Bazooka Plus (Latest BIOS)
Ryzen 5 5600X
2x16GB 3200MHz Jazer (currently using 2400MHz CL17)
RTX 3080 Galax SG 1-Click OC
H100i V2
EVGA 750W BQ (Bronze)
Sata SSDs
Silicon Power 512GB (185GB free space)
Netac 2TB (1.3TB free space)
Kingdian 1TB (134GB free space)

I also have a XPG Spectrix S40G NVMe SSD that I'm not using right now and removed due to thinking it was the main issue and created a whole new installation in the Silicon Power SSD that resulted in the same exact problems.
Whenever I extract files using Winrar on even install games on Steam, Epic or Xbox the SSD usage instantly goes to 100% and the pc freezes for a few seconds multiple times until the installation/extraction is over.
The temperatures are all pretty decent (GPU is undervolted and reaches a max of 67ºC in full load, CPU stock and tops at 71ºC and SSDs according to HWInfo64 all on the 37 to 39ºC range.)

Things I've already tried:
- I've tried 2 different Windows 11 installations downloaded directly from Microsoft to no success (one on the S40G NVMe drive and one on the Silicon Power Sata Drive)
- Used 6 different sata cables and all sata ports on motherboard.
- Checked in BIOS if it's on AHCI.
- Update ssds firmwares and motherboard drivers.
- Disable Superfetch
- Deleted all temp files
- Checked if using "Maximum performance" and all Energy Saving features are off in Power Options

Atto Disk Benchmark Results:

https://imgur.com/6VL8e45

View: https://imgur.com/6VL8e45
C: Silicon Power 512GB

https://imgur.com/AcsRefB

View: https://imgur.com/AcsRefB
D: Netac 2TB

https://imgur.com/e33N8Gv

View: https://imgur.com/e33N8Gv
E: Kingdian 1TB

 

[spunner5]

Odd, as your R/W speeds look as expected (SATA limitation), but if you're saying the hangs occur even on a fresh install of windows, with only the basic AMD driver set... wow. How is overall cooling on your MB? Have you tried 'overcompensating' by installing fan/fans in and around your chipset or VRM's? I built a MSI system once and had hangs about 20 minutes into booting/gaming and found that cooling the VRM's did the trick. I had the MB replaced by MSI, as this was obviously a defect, as I wasn't pushing the MB at all, leaving it at defaults.

 

[jeffnhardy]

Odd, as your R/W speeds look as expected (SATA limitation), but if you're saying the hangs occur even on a fresh install of windows, with only the basic AMD driver set... wow. How is overall cooling on your MB? Have you tried 'overcompensating' by installing fan/fans in and around your chipset or VRM's? I built a MSI system once and had hangs about 20 minutes into booting/gaming and found that cooling the VRM's did the trick. I had the MB replaced by MSI, as this was obviously a defect, as I wasn't pushing the MB at all, leaving it at defaults.

The only thing I thought could be happening was those sub 10MBps write speeds speeds (512B to 16GB) and the 20 to 40MBps randomly showing through were bottlenecking when installing games/softwares, etc and caused the massive freezes.
Also worth mentioning is that before removing my NVMe SSD it would only be recognized in BIOS and as a bootable device when I turned my PSU off and on again, else the RGB would work but not show in BIOS or WIndows (using other bootable device of course).
The airflow is pretty decent in my case but there's no airflow directly to the VRMs, I'll try it immediately.
I've got my radiador in the front of the case with push and pull + 2 top fans and 1 back fan (not using the side panel at the moment) but I have some spare fans that I can use to cool the VRMs.

 

[Maxxify]

Looks like write caching is disabled, or something is delaying/throttling writes. One (somewhat complicated) way of testing this is bootable Linux (which can be done in a number of ways) and running KDiskMark to see if it mirrors the Windows experience. If it does, it's a hardware or UEFI issue. Also, try CrystalDiskMark and also ATTO without Direct I/O to see response.

 

[Maxxify]

Also worth mentioning is that before removing my NVMe SSD it would only be recognized in BIOS and as a bootable device when I turned my PSU off and on again, else the RGB would work but not show in BIOS or WIndows (using other bootable device of course).

This can be related to power settings, in the OS and/or UEFI. Basically if the machine doesn't awaken properly (which includes if there's any sort of fast startup enabled, since that is hibernation) the drive won't be detected. Or, it might be unrelated. Also in addition to my write caching point above, I/O goes through RAM so make sure that's error-free. I don't think it's the PSU in this case. Also, as for drivers (SATA) - do NOT use the AMD drivers but Microsoft's default/stock as sometimes these drivers will cause DPC latency spikes.

 

[jeffnhardy]

Looks like write caching is disabled, or something is delaying/throttling writes. One (somewhat complicated) way of testing this is bootable Linux (which can be done in a number of ways) and running KDiskMark to see if it mirrors the Windows experience. If it does, it's a hardware or UEFI issue. Also, try CrystalDiskMark and also ATTO without Direct I/O to see response.

I've done the three benchmarks you mentioned and only the 4K seems to be a bit low, right?
I've tried to move a file from one SSD to another and also install an update on a game on Epic Games Launcher and in both occasions Windows frooze for 5~10 seconds a few times until the process was over.
I wasn't able to test the RAM quite yet, but I'll try and do it today.
Thanks a lot

C:

https://imgur.com/H6Nbvae

View: https://imgur.com/H6Nbvae

D:

https://imgur.com/xJ3TzQv

View: https://imgur.com/xJ3TzQv

E:

https://imgur.com/8CVYjtT

View: https://imgur.com/8CVYjtT

 

[Maxxify]

Definitely seems to be a write issue in all 3 cases. In addition to the information and options I gave in two posts above, you can also bypass the SATA controller with a USB enclosure or SATA to PCIe adapter that has its own SATA controller on-board or better yet a SATA PCIe card that adds SATA ports which will have its own controller. This would rule out the motherboard's SATA controller. The AMD SATA driver is ruled out I think with Linux/KDiskMark. For RAM testing, yes the traditional method is Memtest overnight (24H ideally) but there are Windows clients that work well (e.g. Karhu). Although, I'd think you would notice system instability at this point. Otherwise it does look like DPC latency or some sort of interrupt polling (this is what causes the "freezing" impression) which is usually a hardware issue (but not always).

Also of course, you can test the NVMe drive to rule out some things.

 

[jeffnhardy]

After a long time the Sata to USB 3.0 case I bought from Aliexpress arrived.
Although the writes SEQ writes are low the RND writes are way above then when benchmarking on my desktop. Is there any other benchmarks or tests I could run to narrow this problem?
The only thing I though would be testing the other sata drives on the laptop as well.

Using the Sata to USB 3.0 case on a laptop

https://imgur.com/k4V6kLa

View: https://imgur.com/k4V6kLa


Connected directly to the laptop

https://imgur.com/UzIS3lL

View: https://imgur.com/UzIS3lL


(like this but on a Acer Predator Helios 300 PH315-53-735Y)

https://imgur.com/9t8WMN8

View: https://imgur.com/9t8WMN8

 

[Maxxify]

The drives are very full which can cause issues with writes, otherwise make sure write caching is enabled for portable (USB) drives.

 

[jeffnhardy]

The drives are very full which can cause issues with writes, otherwise make sure write caching is enabled for portable (USB) drives.

I've just done the tests again (45% used space).

On my desktop:

https://imgur.com/fRFnFGN

View: https://imgur.com/fRFnFGN

-
On USB Case on my desktop on the back USB 3.1 Gen1 port:

https://imgur.com/FkdP78d

View: https://imgur.com/FkdP78d

-
On my laptop:

https://imgur.com/H1elEEA

View: https://imgur.com/H1elEEA

-
On USB Case on my laptop on the back USB 3.1 port:

https://imgur.com/E2bQGuP

View: https://imgur.com/E2bQGuP

 

[MWink64]

Those CrystalDiskMark screenshots are a bit difficult to read, as you're running different tests on some of them. A few were taken while the tests were still running, meaning we can't even see what benchmarks were run.

Can you post CrystalDiskInfo screenshots, so we can see the SMART attributes of the drives? Please make sure the raw values are readable to us mere mortals by going to Function > Advanced Feature > Raw Values > 10 [DEC].

You might also try running HDDScan's Read (data to the host) test and posting a screenshot of the Graph tab (not the Map). Please make sure the window is maximized. Be aware, this test can take a while.

 

[jeffnhardy]

Those CrystalDiskMark screenshots are a bit difficult to read, as you're running different tests on some of them. A few were taken while the tests were still running, meaning we can't even see what benchmarks were run.

Can you post CrystalDiskInfo screenshots, so we can see the SMART attributes of the drives? Please make sure the raw values are readable to us mere mortals by going to Function > Advanced Feature > Raw Values > 10 [DEC].

You might also try running HDDScan's Read (data to the host) test and posting a screenshot of the Graph tab (not the Map). Please make sure the window is maximized. Be aware, this test can take a while.

I can also re-do the test I took the printscreens while still running.
If there's any other benchmark/test that I could run, even if it takes a long time I can try as well

https://imgur.com/NgN2H64

View: https://imgur.com/NgN2H64

https://imgur.com/InhQywn

View: https://imgur.com/InhQywn

 

[Maxxify]

It has to be a hardware issue on the desktop. I have to go back to memory again, try to run one stick and with DOCP.

 

[jeffnhardy]

It has to be a hardware issue on the desktop. I have to go back to memory again, try to run one stick and with DOCP.

Got it, should I just test ram stability (Karhu/Test Mem 5) and MemTest86?
I'm currently using only two of the four ram slots and I have access to 2 other Ram sticks, so there's room for a lot of tests that I'll start immediately

 

[Maxxify]

Got it, should I just test ram stability (Karhu/Test Mem 5) and MemTest86?
I'm currently using only two of the four ram slots and I have access to 2 other Ram sticks, so there's room for a lot of tests that I'll start immediately

I mean, poor write speeds regardless of drive type...in Linux (KDiskMark) and Windows, even clean installs...drives are fine otherwise (other systems) but are slow even in USB...it has to be a caching issue unrelated to software. The freezing issue is weird though, as the RAM should be able to keep up and if it were unstable it'd blue screen, but still worth trying a single stick at "overclocked" XMP/DOCP speeds to see if there's a bad slot or something. Otherwise I would say CPU (if not maintaining max speed, but it seems like you checked this) or motherboard (unfortunately looking more likely).

 

[MWink64]

I can also re-do the test I took the printscreens while still running.
If there's any other benchmark/test that I could run, even if it takes a long time I can try as well

https://imgur.com/NgN2H64

View: https://imgur.com/NgN2H64

https://imgur.com/InhQywn

View: https://imgur.com/InhQywn

Are you sure you selected the right drive and test in HDDScan? Those results are outright impossible for a SATA drive. Could you have inadvertently selected an NVMe drive or the Verify test?

The CrystalDiskInfo screenshot, which you only provided for the 1TB (Kingdian?) drive, shows evidence of a potentially failing drive. It appears to have developed a number of bad blocks and has consumed nearly a quarter of its reserves. This is concerning. I would be wary of trusting this drive with any important data, regardless of the existence of performance issues.

Can you show us screenshots for the other drives. They are selected near the top of the window.

 

[jeffnhardy]

Are you sure you selected the right drive and test in HDDScan? Those results are outright impossible for a SATA drive. Could you have inadvertently selected an NVMe drive or the Verify test?

The CrystalDiskInfo screenshot, which you only provided for the 1TB (Kingdian?) drive, shows evidence of a potentially failing drive. It appears to have developed a number of bad blocks and has consumed nearly a quarter of its reserves. This is concerning. I would be wary of trusting this drive with any important data, regardless of the existence of performance issues.

Can you show us screenshots for the other drives. They are selected near the top of the window.

Yes, the first HDDScan print was done on the 1TB Kingdian Sata Drive (the Map tab showed a ton of Bads).
The 1TB (Kingdian) took 6 hours to complete, the 2TB (Netac) took 1 hour and 10 minutes and the 512GB (Silicon Power) drive took way less than an hour (not sure exactly how many minutes)

Only the Kindian drive had bad blocks in HDDScan so I guess that's the reason why it took almost 6 hours to finish the test and may also be the reason why the read speeds were all messed up

Netac 2TB:

https://imgur.com/0aQPoax

View: https://imgur.com/0aQPoax

Silicon Power 512GB:

https://imgur.com/BL5Y0Kd

View: https://imgur.com/BL5Y0Kd


CrystalDiskInfo showing all drives:

https://imgur.com/7QAmnI4

View: https://imgur.com/7QAmnI4

 

[MWink64]

https://imgur.com/InhQywn

View: https://imgur.com/InhQywn

Are you absolutely sure this screenshot is the graph for the Kingdian 1TB and that you ran the READ (not verify) test? Regardless, it looks very much like the Kingdian is failing. During the time between the screenshots you posted, it has detected more errors. I hope you have good backups of its contents.

I don't see anything majorly wrong with the other two drives. Have you tried running the machine without the Kingdian drive? If that doesn't help, I'd consider the possibility there's an incompatibility between the SATA controller and the drives, though that would likely have been apparent from the time they were first used together. I'll note that I suspect all three drives may use the same controller (probably the SMI 2258XT/2259XT) and could even be manufactured by the same company.

 

[kerberos_20]

lots of drives using your unallocated space as a SLC write buffer, without it, you would hit native nand writes pretty fast...and those 40MB slowdowns could be because of not enough empty blocks, so it has to move stufs around to make up free blocks (kinda like defragmenting on the fly) , trim your drive oneday and enable overprovisioning

 

[MWink64]

lots of drives using your unallocated space as a SLC write buffer, without it, you would hit native nand writes pretty fast...and those 40MB slowdowns could be because of not enough empty blocks, so it has to move stufs around to make up free blocks (kinda like defragmenting on the fly) , trim your drive oneday and enable overprovisioning

Overprovisioning by leaving unpartitioned space isn't really necessary anymore. As long as TRIM is functioning, any free space (whether it's within a partition or not) is acting as dynamic overprovisioning.

 

[kerberos_20]

is acting as dynamic overprovisioning.

huh, since when, whats your source?
mine source says:
any user can set aside a portion of the SSD when first setting it up in the system by creating a partition that does not use the drive's full capacity. This unclaimed space will automatically be used by the controller as dynamic over-provisioning.

based on his drives:
silicon power - user defined locked space out of host, so OS cant access it...
netac/kingdian cant find any overprovisioning info on their sites..but i doubt their firmware is smarter then other brands like samsung

 

[MWink64]

huh, since when, whats your source?
mine source says:
any user can set aside a portion of the SSD when first setting it up in the system by creating a partition that does not use the drive's full capacity. This unclaimed space will automatically be used by the controller as dynamic over-provisioning.

based on his drives:
silicon power - user defined locked space out of host, so OS cant access it...
netac/kingdian cant find any overprovisioning info on their sites..but i doubt their firmware is smarter then other brands like samsung

My claim isn't contradictory to what you're saying. I'm just pointing out that leaving unpartitioned space or reducing the drive's user-accessible capacity is often unnecessary.

The link is dead and I don't have time to go digging for a live one but here's a snippet from a page that used to be on Seagate's site:

An SSD does not natively know which blocks of data are invalid and available for replacing with new data. Only when the operating system (OS) tries to store new data in a previously used location does the SSD know that a particular location contains invalid data. All free space not consumed by the user becomes available to hold whatever the SSD believes is valid data. This is why the storage industry created the TRIM command. TRIM enables the OS to alert the SSD about pages that now contain unneeded data so they can be tagged as invalid. When this is done, the pages do not need to be copied during garbage collection and wear leveling. This reduces write amplification and improves performance. The graphic below shows how much of a difference TRIM can make in allowing more capacity to be available for over-provisioning.

TRIM is yet another method that vendors can employ to boost over-provisioning, thereby increasing performance and drive longevity. It shows a more preferable way to reclaim SSD capacity for acceleration compared to forcing drives to permanently surrender large swaths of their capacity

Basically, whether it's space the drive's controller makes unavailable to the host (which ALL drives have, to varying degrees), user-accessible space that is unpartitioned, or space that is partitioned but unused AND trimmed, it all effectively functions as overprovisioning. Leaving unpartitioned space (that was never written to) would be beneficial to drives that don't support TRIM or can't use it (like some RAID setups and such).

By the way, Silicon Power and likely Kingdian don't even make drives. Netac does. It wouldn't surprise me if all three of his drives were manufactured by Netac and the same internally.

 

[kerberos_20]

My claim isn't contradictory to what you're saying. I'm just pointing out that leaving unpartitioned space or reducing the drive's user-accessible capacity is often unnecessary.

The link is dead and I don't have time to go digging for a live one but here's a snippet from a page that used to be on Seagate's site:



Basically, whether it's space the drive's controller makes unavailable to the host (which ALL drives have, to varying degrees), user-accessible space that is unpartitioned, or space that is partitioned but unused AND trimmed, it all effectively functions as overprovisioning. Leaving unpartitioned space (that was never written to) would be beneficial to drives that don't support TRIM or can't use it (like some RAID setups and such).

By the way, Silicon Power and likely Kingdian don't even make drives. Netac does. It wouldn't surprise me if all three of his drives were manufactured by Netac and the same internally.

this is about trim, as you could read, drive is dumb and doesnt know when data is invalid, once OS tries to write something, drive would than know that data is invalid, thus being replaced...first and foremost drive will mark invalid data for garbage collection and use any free page (not blocks) to write new data...if there is none (because of no overprovisioning), then it will need to use free block or rewrite some block marked for garbage collection, in both cases that means deleting whole page full of blocks and writing them all with new+old content (as it can be mix of anything, old, new, marked for deletion)
trim doesnt happen that offten...by default its once per week
ssd isnt as smart as you think it is, overprovisioning as posted by you from seagate gives you buffer of free pages


as far as raid goes, garbage collection (trim) on raid is supported through software

datacenter SSDs in raid doesnt use trim at all, they have durawrite, overprovisioning is still there, at much larger scale

 

[jeffnhardy]

Are you absolutely sure this screenshot is the graph for the Kingdian 1TB and that you ran the READ (not verify) test? Regardless, it looks very much like the Kingdian is failing. During the time between the screenshots you posted, it has detected more errors. I hope you have good backups of its contents.

I don't see anything majorly wrong with the other two drives. Have you tried running the machine without the Kingdian drive? If that doesn't help, I'd consider the possibility there's an incompatibility between the SATA controller and the drives, though that would likely have been apparent from the time they were first used together. I'll note that I suspect all three drives may use the same controller (probably the SMI 2258XT/2259XT) and could even be manufactured by the same company.

Yes, the screenshot is the graph for the Kindian 1TB and it was the READ test, I ran it again to screenshot the other tabs as well.

It took 3 hours this time to finish the tests

https://imgur.com/KCaDlKO

View: https://imgur.com/KCaDlKO


The time it took for each block

https://imgur.com/o5nl2yZ

View: https://imgur.com/o5nl2yZ


The graph tab

https://imgur.com/Y15yunc

View: https://imgur.com/Y15yunc


And when it started catching bad blocks the speed dropped quite low

https://imgur.com/AMBMqTo

View: https://imgur.com/AMBMqTo


Then I proceded to remove the 1TB Kingdian Drive from the PC, turned it on again, left 280GB unallocated on the 2TB Netac Drive as @kerberos_20 said, Trim was enabled but I manually ran it again and then the Crystal Disk Mark again

https://imgur.com/ucVKqTm

View: https://imgur.com/ucVKqTm

-

https://imgur.com/eCCINK7

View: https://imgur.com/eCCINK7

 

[MWink64]

Yes, the screenshot is the graph for the Kindian 1TB and it was the READ test, I ran it again to screenshot the other tabs as well.

It took 3 hours this time to finish the tests

https://imgur.com/KCaDlKO

View: https://imgur.com/KCaDlKO


The time it took for each block

https://imgur.com/o5nl2yZ

View: https://imgur.com/o5nl2yZ


The graph tab

https://imgur.com/Y15yunc

View: https://imgur.com/Y15yunc


And when it started catching bad blocks the speed dropped quite low

https://imgur.com/AMBMqTo

View: https://imgur.com/AMBMqTo


Then I proceded to remove the 1TB Kingdian Drive from the PC, turned it on again, left 280GB unallocated on the 2TB Netac Drive as @kerberos_20 said, Trim was enabled but I manually ran it again and then the Crystal Disk Mark again

https://imgur.com/ucVKqTm

View: https://imgur.com/ucVKqTm

-

https://imgur.com/eCCINK7

View: https://imgur.com/eCCINK7

Ah, I see what happened! HDDScan is weird when it comes to scaling. What I assumed was 5.5GB/s was actually 5.5MB/s. Yeah, it looks like the Kingdian drive is toast.

Now that you no longer have the Kingdian drive in the system, how is it behaving? Ignoring what any benchmark programs are reporting, are you still having noticeable slowdowns?

this is about trim, as you could read, drive is dumb and doesnt know when data is invalid, once OS tries to write something, drive would than know that data is invalid, thus being replaced...first and foremost drive will mark invalid data for garbage collection and use any free page (not blocks) to write new data...if there is none (because of no overprovisioning), then it will need to use free block or rewrite some block marked for garbage collection, in both cases that means deleting whole page full of blocks and writing them all with new+old content (as it can be mix of anything, old, new, marked for deletion)
trim doesnt happen that offten...by default its once per week
ssd isnt as smart as you think it is, overprovisioning as posted by you from seagate gives you buffer of free pages


as far as raid goes, garbage collection (trim) on raid is supported through software

datacenter SSDs in raid doesnt use trim at all, they have durawrite, overprovisioning is still there, at much larger scale

The point of both TRIM and Durawrite is to contribute to overprovisioning. Durawrite is mostly about compression, which may allow compressible data to be stored in fewer pages, thus leaving more free to function as overprovisioning.

As you said, SSDs aren't very smart. They know where data has and has not been stored. They do not inherently know where data has been stored but is no longer needed, as a result of files being deleted and such. This is where TRIM comes in. TRIM is a command that allows the host PC/OS to inform the drive where there isn't useful data (such as if a file has been deleted). The drive's controller then notes that any pages containing data currently relating to those LBAs is stale and does not need to be preserved during garbage collection. This effectively adds them to the pool of free space (overprovisioning).

The drive's controller doesn't care how much of the drive has been partitioned or not. It just knows where it's been told to store data, and it will continue to preserve that data until it's told otherwise. TRIM is how it's told that LBAs that previously held useful data no longer contain any. It's added back to the pool of free space (overprovisioning).

How often TRIM happens depends on its implementation. It can vary considerably. It can be invoked on-demand but some operating systems also support continuous TRIM. There is considerable debate over the issue, in the Linux community.