Imaging Speed Anomaly Observed

[Leo Casas]

Interesting troubleshooting thread. The SLC cache point is especially worth considering because sustained transfers can behave very differently from short benchmark tests. A drive may look perfectly fine in a quick speed test but slow down significantly once the cache is exhausted or temperatures start climbing.
I’ve seen similar behavior when moving large files, so monitoring temperature, active time and transfer speed together is probably more useful than relying on benchmark numbers alone.
I usually have a browser open in the background for work and sometimes play quick games on GD Lite while waiting for large transfers to finish. Definitely a good reminder to keep an eye on SSD temperatures during long operations.

[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...

Having carefully tested (4) different NvMEs, incl. both 1 & 2tB sizes, what I'm currently seeing is an internal cache size anomaly between commercial grade and PRO grade devices.  All individual speed tests show what's typical of this class of PCiE v3 devices and they are all the same... as expected.  As soon as you throw large DATA transfers at them, (3) of them fall off a cliff as far as their speed is concerned, one of them sustains the typical PCiE v3 speed expected of it.  In all cases it's the target device (the WRITER) that seems to be the cliff dweller.


I've crawled through AI summaries of cached devices in this area and, indeed, there are significant cache size differences from device to device.  What surprised me was that even one of them couldn't sustain a full high speed transfer even with the DATA source at SATA III speeds (525mB/s).  Most of the testing was done NvME v3 to NvME v3.

Based on this, I will be purchasing one of the more PRO devices (I need another disk anyway) and see if this theory can be qualified.

So... bottom line for me is that bandwidth testing for large FULL image transfers, using so-called high speed devices, remains a crap shoot for me... at least until I can pair up devices that hold up under these types of testing scenarios.  All the devices hold up well when used for typical SYSTEM operations... it's only when large DATA transfers rear their ugly head that the anomalies show up.

Anything I find out I'll be happy to pass on...

[Froggie]

Observation addendum to the above... temp and speed monitoring don't seem to be an issue with my testing... all numbers remain within reasonable limits before and during the anomaly, FYI.

[Froggie]

Observation addendum #2 (IMHO only)... PCiE v4/5 devices will also be much more robust in these areas (possibly even larger caches) in order to handle the 7+gB/sec (PCiE v4) transfer rates within this speed realm.  PCiE v5 rates are potentially twice that rate.

They will probably hold up a bit better than PCiE v3 devices do (the ones that I have)... but it really appears to be a device cache related issue that I'm dealing with.