Very slow tranfer rates with NVMe copying with IFL 4.05

[timg11]

I'm using IFL 4.05 to do a drive to drive copy of a Samsung 970 SSD to a 990 Pro.
The 970 is on the motherboard and is recognized by IFL as NVME01.
The 990 is in a Sabrent USB3 to M.2 adapter and plugged into a USB-C 3.2 port.

When the copy process starts copying the primary data partition (NTFS) it shows a progress of over 1 GiB / second, and estimates total time for copying 1 TiB and performing byte for byte verify at 30 minutes.
Then it starts slowing down, and when 25% completed after an hour, the total time is estimated at 4.5 hours.
At that point, the writing rate in IFL is about 14 seconds per GiB or around 76 MiB / second. That is measured by timing how long the GiB processed value in IFL takes to increase by 1 GiB.

The 990 Pro drive has a built in heat sink, and is warm but definitely not hot while it is being written to. I put a fan on it just to be sure.

This article reports that the 990 Pro has a sustained write rate of 1.7 to 1.8 GiB/s after its cache fills.

Why am I not seeing anywhere close to that throughput with IFL? How can I diagnose the problem?
If the drive is misconfigured or incompatible with the Gigabye 890UD motherboard, I want to solve the problem before I migrate to the 990 as the primary drive.

[TeraByte Support]

you can dmesg to see if Linux reports anything, otherwise it could be heat, cable, port, drive starting to act up, etc.. In general I think it's more the USB than the NVMe. Ensure you have the heat sink and thermal pads installed properly, etc.. including in the USB adapter.

[timg11]

Is there any type of utility existing in IFL (or one I could add into my environment) that would test throughput to a device? E.G. I have a new SSD that I want to check out before proceeding with copying the environment onto it. I don't care if it is wiped, but want to get a sense of whether it is working as expected.

[timg11]

After 5 hours, the copy still has 40 minutes to go.
Surprisingly when IFL moved into the B4B verification phase (with both source and destination drives reading), it continued to run at a very slow rate.

Here's the dmesg output (last two screens) Sandisk is the IFL boot drive. Sabrent is the USB M.2 adapter holding the destination drive SDC

[TeraByte Support]

my guess would be the target device path (data transfer).

[OldNavyGuy]

You may also want to check drive temps...

NVMe throttling kicks in when an NVMe's drive's temp exceeds a set threshold.

It reduces perfomance to allow the drive to cool down, preventing damage.

Check your drive manufacturer's specs for the threshold.

[Brian K]

timg11,

I have a 970 and 990 installed in M.2 slots. No problems when creating a 400 GiB image. It took 3.5 minutes using IFL. No hashes or /vb.

If you have a spare M.2 slot you could do your IFL copy without needing USB.

[timg11]

@Brian K, Yes I tried that. The Z890UD has a conveniently accessible M.2 slot called M2M_SB.
I installed the 990 in it, and it was not recognized, either by the BIOS or by IFL.

There is supposed to be a setting in the BIOS for SATA mode vs NVME, but nothing is shown under NVME configuration except the primary NVME (the 970) in slot M2A_CPU, so I went back to the Sabrent USB adapter.

I let the copy process run and it completed after 6 hours. IFL reported no errors.
After the copy, I installed the 990 in the primary slot M2A_CPU, and the system failed to boot. The BIOS did recognize it as 990 Pro, but Windows went into the attempt Repair/Fail mode.
I have re-installed the 970 for now, and it is able to boot normally.

Maybe there is a problem with the USB controllers, or the Sabrent USB to M2 adapter?

[timg11]

I've been booting off USB into IFL and using the IFL drive Copy function to clone these M.2 SSDs.
Because physical access is challenging to the M.2 slots, I'd rather minimize the inserting and removal of the SSDs.

Could I get the effect of the Copy Drive by backing up the entire drive to a single file and saving it to my NAS over the LAN, and then using a different test machine, booted into IFL to restore to the target drive? That would avoid having to have the main machine down for so many hours?
What considerations would be needed to ensure the target drive ends up being bootable?

[TeraByte Support]

disable fast start up or ensure you reboot to boot ifl (not shutdown / power on), chkdsk /f, ensure drive firmware up to date (not sure if it happens anymore but in the past there were bsod of ssd drives until firmware updated), if you want to see what the bsod is, you can use osdtool.tbs to disable to automatic restart. Ensure the controller mode is the same (AHCI vs RAID for example). Ensure you don't bring both drives online in windows while attached (using simple operations copy will handle that), yes you can backup/restore instead of copy.