Question *STABLE* NVMe - USB Adapter?

[cyberjedi]

I'm looking to buy a *RELIABLE* NVME-USB external adapter, that doesn't disconnect randomly, can keep up the close to 1GB/s speed.
So far all adapter's reviews contain frighteningly high % of reports of malfunction, random disconnects, sub-par speeds, falling to even under USB 2.0 speeds, etc.
There are 3 main chipsets in the market: JMicron JMS583, Asmedia ASM2362, and Realtek RTL9210 (no product has surfaced with the latter yet, so no REAL reviews, experiences yet UPDATE: it is on the market already).
Also ASUS has a new product, ROG Strix Arion, but there isn't enough feedback about it yet, and I mean real life feedback not just being able to run a few benchmarks, but real stress test to see if the device (adapter) can keep it up, without disconnecting or slowing down hard.
I would really appreciate any feedback from those who have GOOD experiences during stress-tests, like tons of random 4k writes with a stable speed, cloning 100's of GB-s at a stable high speed close to 1GB/s.
I know SSD's very well, so please stick to the point and don't start to educate me on how their speed falls after some writes, etc. I'm aware and this is NOT the point.
You can help if you can point me to a STABLE and RELIABLE NVMe-USB-C adapter that WORKS as expected.
Thank you in advance!

 

[ApplesOfEpicness]

This happens very often due to a bad cable. That's why I only use real Thunderbolt cables nowadays instead of the cables which come with the enclosures, at least when operating them with speeds faster than 5Gbit/s.

It's definitely not the cable. I have tested several cables now ranging in speed from USB 3.2 Gen2 to Thunderbolt 4. All of them were fairly short and high quality too.

Is there a way to limit the speed artificially in the firmware configuration? I care less about speed than I do stability and usability. The reason I use the ACASIS in the first place is because it has a ton of other things on it so I only need to carry around one hub.

 

[igor_kavinski]

It's definitely not the cable.

Could be bad firmware coding that is reacting to some specific bytes in that file. RAR or 7zip the file and try copying the resulting archive. If that doesn't work, encrypt the archive with password and try one more time. If that also doesn't work, format the drive with a different filesystem (try exFAT if it is currently NTFS and vice versa).

 

[ApplesOfEpicness]

Could be bad firmware coding that is reacting to some specific bytes in that file. RAR or 7zip the file and try copying the resulting archive. If that doesn't work, encrypt the archive with password and try one more time. If that also doesn't work, format the drive with a different filesystem (try exFAT if it is currently NTFS and vice versa).

I was able to successfully copy a .rar version of the file onto the drive. Unfortunately decompressing it caused an I/O error.

 

[igor_kavinski]

Unfortunately decompressing it caused an I/O error.

Did you decompress it to the same drive or to a different drive?

After copying the RAR to the enclosure drive, copy the RAR file from the enclosure drive to some other drive and then try decompressing it.

 

[ApplesOfEpicness]

Did you decompress it to the same drive or to a different drive?

After copying the RAR to the enclosure drive, copy the RAR file from the enclosure drive to some other drive and then try decompressing it.

Decompressing it in the same drive failed. Copying the RAR file to another drive and decompressing the file yielded an identical file (success).

 

[igor_kavinski]

Decompressing it in the same drive failed. Copying the RAR file to another drive and decompressing the file yielded an identical file (success).

Try to find updated firmware. That should fix it.

Found this: https://media.plugable.com/downloads/drivers/products/usbc-nvme/usbc-nvme_realtekfirmware202112.zip

from here:

https://www.reddit.com/r/CKsTechNews/comments/slajn9

I take no responsibility if this bricks your enclosure.

 

[ApplesOfEpicness]

Try to find updated firmware. That should fix it.

I am already on 1.29.391 which is the latest I can find unfortunately. Should I try contacting Realtek about it?

 

[Ananas]

I was able to successfully copy a .rar version of the file onto the drive. Unfortunately decompressing it caused an I/O error.

I actually also had such a problem with two different RTL9210B based enclosures: When these were connected to a Thunderbolt dock with was in turn connected to a MacBook Pro 14" (M1 Pro chip) running macOS Monterey, a certain I/O intensive operation would always fail (eventually, after a different percentage of progress had already been made) with an I/O error, while the same operation would always complete successfully when the enclosure was connected directly to one of the USB Type C ports of the notebook, or if different (non-RTL9210B based) encosures connected to the Thunderbolt dock were used.

The "certain I/O intensive operation" mentioned above was the conversion of a .sparsebundle disk image into a compressed and encrypted .dmg file with both source and destination being on the same NVMe SSD inside of the enclosure, i.e. the enclosure and the SSD inside of it where subject to heavy concurrent read/write traffic.

I have not been able to track this down to a final conclusion as the NVMe SSD eventually died on me. But it might in fact be the case that the RTL9210B chip is broken in hardware or software.

 

[igor_kavinski]

I am already on 1.29.391 which is the latest I can find unfortunately. Should I try contacting Realtek about it?

Yeah. I think they should be very interested in a file that breaks their firmware.

 

[ApplesOfEpicness]

I actually also had such a problem with two different RTL9210B based enclosures: When these were connected to a Thunderbolt dock with was in turn connected to a MacBook Pro 14" (M1 Pro chip) running macOS Monterey, a certain I/O intensive operation would always fail (eventually, after a different percentage of progress had already been made) with an I/O error, while the same operation would always complete successfully when the enclosure was connected directly to one of the USB Type C ports of the notebook, or if different (non-RTL9210B based) encosures connected to the Thunderbolt dock were used.

The "certain I/O intensive operation" mentioned above was the conversion of a .sparsebundle disk image into a compressed and encrypted .dmg file with both source and destination being on the same NVMe SSD inside of the enclosure, i.e. the enclosure and the SSD inside of it where subject to heavy concurrent read/write traffic.

I have not been able to track this down to a final conclusion as the NVMe SSD eventually died on me. But it might in fact be the case that the RTL9210B chip is broken in hardware or software.

Interesting. I hope someone with a different enclosure that uses the same chip can try testing my file at USB 3.2 Gen2 speeds to find out if it's a problem with the chip/firmware, or if ACASIS made a mistake with the implementation.

 

[Ananas]

I hope someone with a different enclosure that uses the same chip can try testing my file at USB 3.2 Gen2 speeds to find out if it's a problem with the chip/firmware, or if ACASIS made a mistake with the implementation.

Perhaps you should mention the hardware and software configuration you encountered the problem with (eg. PC or notebook, Windows or Linux) and the exact procedure that someone would need to follow to reproduce the problem. Then someone from ACASIS tech support might be willing give it a try, you should be able to get in touch through eg. Facebook. Did you try different USB ports on different computers yourself?

 

[ApplesOfEpicness]

Perhaps you should mention the hardware and software configuration you encountered the problem with (eg. PC or notebook, Windows or Linux) and the exact procedure that someone would need to follow to reproduce the problem. Then someone from ACASIS tech support might be willing give it a try, you should be able to get in touch through eg. Facebook. Did you try different USB ports on different computers yourself?

ACASIS support has not been very helpful; I haven't heard from them once in the past week and a half. I have tried using the drive on both my laptop and my PC, but the issue persists (Windows 10/11). Haven't tried Linux/Mac yet, maybe later. I should mention that I do have 2 of the same 10-in-1 hubs that have the same issue, so my unit probably isn't defective.

 

[Ananas]

OK, so you really did your homework already, i.e. trying with different computers and multiple copies of the CM073, that is good to hear.

I currently don't have a spare NVMe M.2 SSD handy, but could try with a SATA one, which I suppose wouldn't be of much help, right? (I assume you only tried NVMe M.2 SSDs, or does it happen with a SATA M.2 one, too?)

I admit that I am somewhat reluctant to download your file though anyway. When clicking on your link, Google Drive doesn't tell me anything about it whatsoever, i.e. neither its name nor its size, it just offers it for download, and you didn't give us any such information either — except that its apparently "big". Nobody would be well advised to download unknown stuff from unknown sources, right? Not so much because it might be malware, but it might also contain something that is deemed illegal in the downloader's part of the world.

So perhaps you'll want to try these two things first:
1. Does the copy always fail at the same percentage of progress, i.e. at the same byte/block of file contents?
2. What happens if you spilt the files into multiple parts, is there a specific part which will trigger the failure?

 

[ApplesOfEpicness]

OK, so you really did your homework already, i.e. trying with different computers and multiple copies of the CM073, that is good to hear.

I currently don't have a spare NVMe M.2 SSD handy, but could try with a SATA one, which I suppose wouldn't be of much help, right? (I assume you only tried NVMe M.2 SSDs, or does it happen with a SATA M.2 one, too?)

I admit that I am somewhat reluctant to download your file though anyway. When clicking on your link, Google Drive doesn't tell me anything about it whatsoever, i.e. neither its name nor its size, it just offers it for download, and you didn't give us any such information either — except that its apparently "big". Nobody would be well advised to download unknown stuff from unknown sources, right? Not so much because it might be malware, but it might also contain something that is deemed illegal in the downloader's part of the world.

So perhaps you'll want to try these two things first:
1. Does the copy always fail at the same percentage of progress, i.e. at the same byte/block of file contents?
2. What happens if you spilt the files into multiple parts, is there a specific part which will trigger the failure?

Yeah I get that people are wary of downloading an unknown file, and I don't blame them. I have tried with both SATA and NVME drives and it is the same issue unfortunately (I guess you could test your SATA drive if you wanted to). As for what part of the transfer fails, it's hard to tell. The moment I try to transfer that file it shows the transfer screen for a split second before giving me an I/O error and making the drive disappear (disconnect). I can try splitting the file up, though it might be a bit difficult since it's not any standard file type.

Also, if anyone is curious what the file is, it's part of the soundbank for Japanese voicelines in Genshin Impact (lol). This whole thing started because I wanted to download the game to a separate drive since my main laptop drive is small and cannot be upgraded.

 

[Ananas]

I can try splitting the file up, though it might be a bit difficult since it's not any standard file type.

OK, if you're on Windows, you should be able to make use of the Windows Subsystem for Linux (WSL) which Microsoft introduced with Windows 10. This would give you a quick way to have a bunch of nice command line tools available, like "cp" to copy files and "dd" to split them up.

Having said that: Perhaps you first try the COPY.EXE command inside of a CMD.EXE window. I am no Windows expert, but I remember there is an option switch to have COPY treat the file as binary. This should fail, too.

How to split your big file using the Linux command "dd" and writing the parts to the destination SSD at the same time:

i=0; while ((i+=1)); do dd if=/path/to/your-big-file bs=1m skip=$((i-1)) count=1 of=part.$i && [ -s part.$i ] || break; done

Before running this you "cd" into a directory on your SSD to have the part files created there. With "bs=1m" they will be one megabyte each.

 

[ApplesOfEpicness]

OK, if you're on Windows, you should be able to make use of the Linux Subsystem for Linux (WSL) which Microsoft introduced with Windows 10. This would give you a quick way to have a bunch of nice command line tools available, like "cp" to copy files and "dd" to split them up.

Having said that: Perhaps you first try the COPY.EXE command inside of a CMD.EXE window. I am no Windows expert, but I remember there is an option switch to have COPY treat the file as binary. This should fail, too.

How to split your big file using the Linux command "dd" and writing the parts to the destination SSD at the same time:

i=0; while ((i+=1)); do dd if=/path/to/your-big-file bs=1m skip=$((i-1)) count=1 of=part.$i && [ -s part.$i ] || break; done

Before running this you "cd" into a directory on your SSD to have the part files created there. With "bs=1m" they will be one megabyte each.

I ended up using git bash to run the "split" command and turned the file into 1,024KB files. The problem apparently lies in the first 1024KB, so I guess that's a start. Will update here when I narrow it down more.

Edit: Have narrowed it down to 1KB. If I split this file into 2 512B sections the problem goes away, so getting close.

Edit 2: Well this is about as good as I can get it. I couldn't get an error with any smaller file size. Interestingly the behavior is slightly different than the full file. Instead of giving me an I/O error, it seems to transfer the whole file, but then the drive disconnects and the file written is filled with zeros. This particular chunk was located in the:

1st 1024KB of the file,
2nd 512KB of that chunk,
1st 128KB of that,
2nd 64KB,
2nd 32KB (this is where behavior changed),
1st 16KB,
2nd 8KB,
2nd 4KB,
1st 2KB.
1st 1KB.

a

drive.google.com

 

[Ananas]

a

drive.google.com

Wow, cool! Are you saying that this little 1024 bytes file "a" is sufficient to cause a malfunction (albeit a different one)?

So if you copy this little file to your SSD, no matter whether by means of "cp", "COPY.EXE" or the Windows Explorer, the destination file will be garbage? Do I understand this correctly?

I will give it a try now myself.

Edit: No, works in my case (MacBook Pro 14" M1 Pro macOS 12.6.1 "Monterey"), Transcend 256GB M.2 SATA SSD in RTL9210B based Graugear G-M2DK-AC-10G connected to a Type C USB 3.2 Gen 2 port on Thunderbolt 3 dock with 10Gbit/s (see pics as proof):

$ ls -l a; md5sum a
-rw-r--r--@ 1 ananas staff  1024 16 Nov 21:57 a
7a3d146467525bf9aa6a698b49b9e792  a

$ time cp -v a /Volumes/GRAUGEAR; ls -l /Volumes/GRAUGEAR/a; md5sum /Volumes/GRAUGEAR/a
a -> /Volumes/GRAUGEAR/a

real    0m0.007s
user    0m0.001s
sys    0m0.004s
-rw-------@ 1 ananas staff  1024 16 Nov 22:06 /Volumes/GRAUGEAR/a
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a

 

[ApplesOfEpicness]

Wow, cool! Are you saying that this little 1024 bytes file "a" is sufficient to cause a malfunction (albeit a different one)?

So if you copy this little file to your SSD, no matter whether by means of "cp", "COPY.EXE" or the Windows Explorer, the destination file will be garbage? Do I understand this correctly?

I will give it a try now myself.

Edit: No, works in my case (MacBook Pro 14" M1 Pro macOS 12.6.1 "Monterey"), Transcend 256GB M.2 SATA SSD in RTL9210B based Graugear G-M2DK-AC-10G connected to a Type C USB 3.2 Gen 2 port on Thunderbolt 3 dock with 10Gbit/s (see pics as proof):

$ ls -l a; md5sum a
-rw-r--r--@ 1 ananas staff  1024 16 Nov 21:57 a
7a3d146467525bf9aa6a698b49b9e792  a

$ time cp -v a /Volumes/GRAUGEAR; ls -l /Volumes/GRAUGEAR/a; md5sum /Volumes/GRAUGEAR/a
a -> /Volumes/GRAUGEAR/a

real    0m0.007s
user    0m0.001s
sys    0m0.004s
-rw-------@ 1 ananas staff  1024 16 Nov 22:06 /Volumes/GRAUGEAR/a
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a

Huh. Interesting. Yeah as far as I'm aware any attempt to copy that file to my SSD causes it to disconnect. Maybe it's a Windows thing (or ACASIS). I'm going to see if I can try this on a different operating system. Unfortunately this transfer bug causes some system instability. I'm running chkdsk right now on my PC so will report back later when that finishes.

 

[Ananas]

Apparently the I/O error comes from the SSD going into a weird state while the operating system is still about to send more data. With smaller files, the SSD also goes into the same weird state, but when this happens the OS is already done with its part of the job so assumes the drive has received all the data properly, so it does not raise an I/O error.

 

[ApplesOfEpicness]

Apparently the I/O error comes from the SSD going into a weird state while the operating system is still about to send more data. With smaller files, the SSD also goes into the same weird state, but when this happens the OS is already done with its part of the job so assumes the drive has received all the data properly, so it does not raise an I/O error.

So I just tried to copy this file from my iPad to the drive, and the same thing happened. It's looking more and more like this is a problem with ACASIS's implementation.

 

[Ananas]

So I just tried to copy this file from my iPad to the drive, and the same thing happened. It's looking more and more like this is a problem with ACASIS's implementation.

ACASIS should surely no longer refuse to look at it now, but since my own problems described above occurred with a NVMe SSD in two different RTL9210B based enclosures (and not with ASMedia and JMicron based ones), I am still wondering whether others can possibly reproduce your case with RTL9210B based enclosures other than the ACASIS CM073. I guess it might only occur under special circumstances though like only with certain types or models of SSDs.

Edit #1: Stress test with 10,000 copies of "a" to the RTL9210B-enclosed SATA SSD, no errors (yes, I verified that all md5sums are the same):

$ i=0; while (((i+=1)<=10000)); do cp a /Volumes/GRAUGEAR/a.$i && md5sum /Volumes/GRAUGEAR/a.$i || break; done
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a.1
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a.2
...
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a.10000

Edit #2: As above was using Apple's APFS, I retried the 10,000 files test with both FAT32 and ExFAT, both completed successfully as well. I.e. I cannot reproduce your problem with this SSD inside of the GRAUGEAR G-M2DK-AC-10G.

 

[mclain]

FW 1.30.17 found - might be of interest to someone.

UTHSB_MPtool_Lite_v1.30.17_20220630（最新FW）.rar - 蓝奏云

文件大小：9.9 M|

wwm.lanzout.com

VirusTotal

VirusTotal

www.virustotal.com

 

[ApplesOfEpicness]

ACASIS should surely no longer refuse to look at it now, but since my own problems described above occurred with a NVMe SSD in two different RTL9210B based enclosures (and not with ASMedia and JMicron based ones), I am still wondering whether others can possibly reproduce your case with RTL9210B based enclosures other than the ACASIS CM073. I guess it might only occur under special circumstances though like only with certain types or models of SSDs.

Edit #1: Stress test with 10,000 copies of "a" to the RTL9210B-enclosed SATA SSD, no errors (yes, I verified that all md5sums are the same):

$ i=0; while (((i+=1)<=10000)); do cp a /Volumes/GRAUGEAR/a.$i && md5sum /Volumes/GRAUGEAR/a.$i || break; done
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a.1
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a.2
...
7a3d146467525bf9aa6a698b49b9e792  /Volumes/GRAUGEAR/a.10000

Edit #2: As above was using Apple's APFS, I retried the 10,000 files test with both FAT32 and ExFAT, both completed successfully as well. I.e. I cannot reproduce your problem with this SSD inside of the GRAUGEAR G-M2DK-AC-10G.

I'm getting another SSD hub that also uses the RTL9210B to test. My theory is that, since the CM073 is a multi-function hub, the Realtek chip has to be connected through a USB hub chip. Maybe that interaction is causing some data corruption at high speeds.

 

[Ananas]

the Realtek chip has to be connected through a USB hub chip. Maybe that interaction is causing some data corruption at high speeds.

That is a good theory indeed. Also in my case the I/O errors occurred with an USB hub inbetween (MacBook Pro → Thunderbolt hub → USB hub → RTL9210B → NVMe SSD).

 

[LuckMan212]

Anyone got any news of a more recent firmware for JMicron JMS583 chips? I'm using v02.01.02 with a Mac M1, occasionally the thing will just go brain-dead (slow, freeze on access, or just fail to mount) until I unplug it for a few seconds and then plug it back in.