Imaging Speed Anomaly Observed

[Froggie]

I have noticed a recent anomaly with MR8.1 that, at this point, won't allow me to run an unquestioned comparison... I have no idea what's going on.

While imaging a multi-BOOT System (EFI, MSR, Win10 OS, Win11 OS & Recovery) I experience a very weird anomaly.  While imaging between NvMEs (different internal SOURCE and TARGET), The LIVE OS partition images at the expected speed while the non-LIVE OS partition images at a speed 10x lower.  This occurs regardless of whether the LIVE OS partition is either Win10 or Win11... makes no sense at all.  Both are standard NTFS partitions, one LIVE and one hidden.  It almost acts like it's viewing the hidden partition as though it's an unsupported FileSystem.  I see the same kind of imaging speed differences between LIVE NTFS partitions and hidden EXT<n> partitions.  Macrium (like HBS) must image the "unknown" format (EXT<n>) in a forensic mode, having to read every sector of DATA defined in the partition... this creates a much longer imaging operation for those partition types.

I only bring this up when I noticed Bespoken's latest MR8.1 imaging... his MR8.1 time is double his HBS time, this should not be the case when using identical SOURCE and TARGET devices.  Although my anomaly (multi-BOOT) is not the same as Bespoken's, the massive difference between MR8.1 and HBS is the same.  Remember, both use the exact same DATA compression algorithms during their imaging processes.

I believe something has changed with MR8.x's Windows interface recently, probably due to a possible Windows update.  I have never before seen this type of anomaly and I've used HBS and MR8.1 side by side for years.

Just some food for thought...

[Froggie]

Just noticed an interesting phenomena regarding the above observation associated with the SOURCE NvME.  I will report back as soon as I can confirm.

[Bespoken]

I only bring this up when I noticed Bespoken's latest MR8.1 imaging... his MR8.1 time is double his HBS time, this should not be the case when using identical SOURCE and TARGET devices.  Although my anomaly (multi-BOOT) is not the same as Bespoken's, the massive difference between MR8.1 and HBS is the same.  Remember, both use the exact same DATA compression algorithms during their imaging processes.

I believe something has changed with MR8.x's Windows interface recently, probably due to a possible Windows update.  I have never before seen this type of anomaly and I've used HBS and MR8.1 side by side for years.

It would not be a surprise if the performance impact was due to a Windows update. The v8.0.7175 version was instelled from an old saved download, and it would not update to the latest. The v8.1.8853 was downloaded from softpedia.com and a registration key applied. This suggests that the anomaly is not with the program, and I have not seen any other reports of performance issues.

It will be interesting see what you find.

[Froggie]

OK, I'm at a pause at the moment.  Discovered varying imaging speeds with HBS, same as Macrium.  Hmmm... maybe some wierdness with the SOURCE NvME, swapped it, no change.  Changed the TARGET disk, no change.  Hmmm... maybe this is a product of the compression software (same one in use by both imaging Systems).

Stopped imaging and started standard Windows COPY (no imaging engines, no compression algorithms), same result.  I have (3) NvMEs in my System, (2) connected to my mainboard and one connected, via a caddy, to my PCIe v3 bus, (2) different brands, (3) different models.  The result remains the same regardless of the SOURCE and TARGET.  All NvMEs run at the same expected speed when testing with a disk tool.

What does this leave me with... OS and or hardware.  OS tests were run with Win10, Win11 and a Win10 WinPE/RAM-based mini System... same results.  Then reduced my System RAM from 32 to 16gB... same result.

When doing the simple file copy, The process starts off as expected... SOURCE disk running full bore at max speed and the ACTIVE time at about 100%, the TARGET disk running almost as fast with its ACTIVE time at about 75%.  All of a sudden the SOURCE disk drops to about .1-.2x of its max speed speed with its ACTIVE time dropping significantly.  The TARGET disk is all of a sudden at 100% ACTIVE and the DATA rate at about .1x.  The TARGET disk change seems to be the thing that starts slowing down the whole process (100% ACTIVE queueing and a slow data rate).  Sometimes this happens once over the span of the entire 147gB file copy, sometimes it happens multiple times during the process,  This anomaly happens regardless of the Write-Cache setting of the TARGET drive.

This is why I'm pausing at the moment.  This testing is being done with a 10th gen i7 (16-threads) so the processor has never really been challenged.  Due to these random changing I/O disk conditions, I cannot make a valid comparison between any similar processes.  Any suggestions, greatly appreciated!  And if anyone can do a simple Windows COPY of a large file (150gB) from one NvME to a different one while monitoring the disks with the TASK MANAGER, I love to know what your observation is as far as SOURCE/TARGET ACTIVE times and throughput speed.

Puzzled at the moment... looking at a possible System change (if I can find a similar one).

[al3x]

Hi Froggie,

there are so many factors that could be involved. I wouldn't be surprised if Defender was also slowing down the copy progress to some extent.

If it's copying files between two NVMe this could also be a heat problem. NVMes tend to get hot very fast if you access data a lot.
Have you checked temperatures with a tool like CrystalDiskInfo before and during the copy progress?

Here's a quick video of my task manager during a 120GB file copy from C: to D:, hope that helps:
https://youtu.be/Y9H7SiIAbqU

My specs:
- OS: Windows 11 Pro 25H2 (Build 26200.9168)
- CPU: AMD Ryzen 9 5900X
- RAM: 4x G.Skill DIMM 16 GB DDR4-3600
- SSD: 2x Samsung 980 PRO NVMe 1TB

[Froggie]

That's exactly what I would expect, albeit a bit slower in my case due to PCIe v3.  I need to get deeper into this to see what is going on.

Haven't checked the temps, will do so now... thanks!

[Froggie]

@al3x, thank you again for your further diagnostic suggestion!

Using CrustalDiskInfo, I have discovered (2) anomalies in the System.  My oldest NvME, although its health is shown as GOOD, is down to a 15% health rating. This, of course, is way to low for me.  The second NvME (2tB Solidigm) definitely has a heat issue... quickly runs up over 60-deg C which is where the bandwidth problem begins.  When I isolate the transfer to the two no temp issue disks (one is that 15% GOOD health), all is fine, no speed anomalies.

Thank you again for your very valuable suggestion     Now the problem is replacing this item affordably (prices have almost tripled since I bought most of this stuff).

Thanks again!!

[al3x]

Just a quick note about the temperatures:

You should check the manual/specs for the NVMe what it says about max. temps before throttling kicks in. For my Samsung 980 PRO this is 70°C and it's running at ~62°C for me during the copy. So up to 70°C in general shouldn't be a problem I guess.

Nevertheless a good heatsink cooler, e.g. ARCTIC M2 Pro or similar, also helps to reduce temperatures of course.
So I'm not sure if temps are the main problem here for you, but it could be.

Anyway: You're welcome, glad I could somewhat help, keep us posted when you manage to solve your challenges

[pt58]

@Froggie,
You could also be hitting the limit of the SLC cache on your target NVME drive, particularly if the drive is starting to fill up.
On an empty 2TB drive, the SLC cache can be 100s of GB, but as the drive fills, the cache size reduces.
Once the SLC cache is filled, the drive has to write directly to the underlying TLC or QLC Flash, which is much slower, particularly in the case of QLC.
Another thing which can cause slowdowns is if the SSD hasn't been TRIM'd for a while. That can also make a huge difference.
Anyway, just thought I'd throw a few other ideas into the melting pot. 

[Froggie]

Thanks for the suggestions, @pt58!  The drive has plenty of room and is "optimized" (TRIMmed) under Windows quite often.  The larger drive (2tB) seems to be the bigger culprit... and it may be some sort of other cache issue.  It's commercial grade and I have been able to make it "busy" (dropping in bandwidth) by force feeding it either from another same speed drive (NvME @2gB/sec) and even doing the same from a SATA III SSD (510mB/sec).

The commercial grade just may not  be able to hold up against high speed streaming.  Still looking into it...