• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

USB 3.0 to SSD throughput disappointing

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

HankB

Member
Joined
Jan 27, 2011
Location
Beautiful Sunny Winfield
I'm copying a VM to an SSD via a USB 3.0 external enclosure. The process is taking a long time and the progress popup is reporting a speed of 14.8 MB/sec. I could hope for more. (This is copying from a system drive that is also an SSD on a modern laptop.)

Both SSDs are Crucial of some sort. The external is an MX100 and the internal is an M550.

Is this what I should expect or should I start looking for the weak link in the chain? The device is listed as:
Code:
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge
This is on Linux, BTW.)

Thanks!
 
What exact external enclosure are you using?
What size of files are you moving, large or small? I've seen VM's both ways.
 
The enclosure is a Sabrent EC-UASP http://www.sabrent.com/category/hard-drive-enclosures/EC-UASP/

The files start out with some large ones - the virtual disk I suppose:
Code:
./Windows 10 x64:
total 51072509
drwx------ 1 hbarta hbarta          0 Apr 12  2015 caches
-rw------- 1 hbarta hbarta    1343488 Aug 26 09:11 vmmcores-3.gz
-rw------- 1 hbarta hbarta    9296808 Aug 27 17:54 vmmcores-4.gz
-rw------- 1 hbarta hbarta     406689 Nov 28 13:49 vmware-0.log
-rw------- 1 hbarta hbarta     382504 Nov  7 08:33 vmware-1.log
-rw------- 1 hbarta hbarta     883466 Oct 14 20:44 vmware-2.log
-rw------- 1 hbarta hbarta     918377 Nov 30 17:40 vmware.log
-rw------- 1 hbarta hbarta       8684 Nov 30 17:40 Windows 10 x64.nvram
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s001.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s002.vmdk
-rw------- 1 hbarta hbarta 4251713536 Nov 30 17:40 Windows 10 x64-s003.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s004.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s005.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s006.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s007.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s008.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s009.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s010.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s011.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s012.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s013.vmdk
-rw------- 1 hbarta hbarta 4252499968 Nov 30 17:40 Windows 10 x64-s014.vmdk
-rw------- 1 hbarta hbarta 4024369152 Nov 30 17:40 Windows 10 x64-s015.vmdk
-rw------- 1 hbarta hbarta  504430592 Nov 30 17:40 Windows 10 x64-s016.vmdk
-rw------- 1 hbarta hbarta       1194 Nov 29 11:37 Windows 10 x64.vmdk
-rw------- 1 hbarta hbarta          0 Apr 12  2015 Windows 10 x64.vmsd
-rw------- 1 hbarta hbarta       4132 Nov 30 17:40 Windows 10 x64.vmx
-rw------- 1 hbarta hbarta        373 Nov 29 11:37 Windows 10 x64.vmxf
Then there are a bunch of smaller files ranging from a few bytes to a few tens of KB:
Code:
./Windows 10 x64/caches/GuestAppsCache/appData:
total 2094
-rw------- 1 hbarta hbarta  6616 Jul 25 17:33 0067b282d227682b3cf812969ce2c000.appicon
-rw------- 1 hbarta hbarta   248 Jul 25 17:33 0067b282d227682b3cf812969ce2c000.appinfo
-rw------- 1 hbarta hbarta   636 Aug 14 19:37 01434f2d0aa86feb8778372c528a21d1.appicon
-rw------- 1 hbarta hbarta   176 Aug 14 19:37 01434f2d0aa86feb8778372c528a21d1.appinfo
-rw------- 1 hbarta hbarta  4724 Nov 29 20:12 0230eccc5f7b7a01b9f0a276862ed63f.appicon
-rw------- 1 hbarta hbarta   180 Nov 29 20:12 0230eccc5f7b7a01b9f0a276862ed63f.appinfo
-rw------- 1 hbarta hbarta  6112 Nov 30 17:32 02d3ee671ac2944f9ca39c8de01f7997.appicon
-rw------- 1 hbarta hbarta   224 Nov 30 17:32 02d3ee671ac2944f9ca39c8de01f7997.appinfo
-rw------- 1 hbarta hbarta   972 Nov 30 17:18 02f541ee60a19c82c6751394d3c2f58e.appicon
-rw------- 1 hbarta hbarta   224 Nov 30 17:18 02f541ee60a19c82c6751394d3c2f58e.appinfo
-rw------- 1 hbarta hbarta 12312 May  4  2015 02f6a532830b2c82079c630e5f9d387b.appicon
-rw------- 1 hbarta hbarta   244 May  4  2015 02f6a532830b2c82079c630e5f9d387b.appinfo
-rw------- 1 hbarta hbarta   756 Aug 14 19:37 04097482d654de2ee53f5327f3288f5f.appicon
-rw------- 1 hbarta hbarta   188 Aug 14 19:37 04097482d654de2ee53f5327f3288f5f.appinfo
-rw------- 1 hbarta hbarta  2024 Jul 25 17:32 04278b03f59b11d7c95972a19c4f6b01.appicon
-rw------- 1 hbarta hbarta   176 Jul 25 17:32 04278b03f59b11d7c95972a19c4f6b01.appinfo
-rw------- 1 hbarta hbarta  5700 Sep  2 06:46 0433bdf5688ccc03551e4b4742c93103.appicon
-rw------- 1 hbarta hbarta   220 Sep  2 06:46 0433bdf5688ccc03551e4b4742c93103.appinfo
-rw------- 1 hbarta hbarta  4528 Jul 25 17:33 04ae0f4509e090a65ffd3c745c0942e8.appicon
-rw------- 1 hbarta hbarta   192 Jul 25 17:33 04ae0f4509e090a65ffd3c745c0942e8.appinfo
-rw------- 1 hbarta hbarta  1272 Aug  2 06:17 05157268902612bccc80cbdc49bdce40.appicon
-rw------- 1 hbarta hbarta   252 Aug  2 06:17 05157268902612bccc80cbdc49bdce40.appinfo
-rw------- 1 hbarta hbarta   972 Nov 30 17:18 05930e5852c7a323ac8a8f5a23230372.appicon
-rw------- 1 hbarta hbarta   248 Nov 30 17:18 05930e5852c7a323ac8a8f5a23230372.appinfo
-rw------- 1 hbarta hbarta  5892 Aug 14 19:37 05a3cd064963aa1199f85ad7b45a8c8b.appicon
-rw------- 1 hbarta hbarta   168 Aug 14 19:37 05a3cd064963aa1199f85ad7b45a8c8b.appinfo
-rw------- 1 hbarta hbarta  6984 Jul 25 17:33 0878c36ca1082ee9973f71d0b786f35b.appicon
-rw------- 1 hbarta hbarta   208 Jul 25 17:33 0878c36ca1082ee9973f71d0b786f35b.appinfo
    .
    .
    .
Total number of files is 511:
Code:
hbarta@olive /media/hbarta/floater/yggdrasil $ find .|wc -l
511
hbarta@olive /media/hbarta/floater/yggdrasil $

Thanks!

Edit: It may matter that the FS is NTFS. I chose that so it would be compatible across all of my PCs.
 
That's not even USB 2.0 speeds. Driver issue with USB 3.0 ports?
 
Yes something is clearly wrong. I'd start by working from the card back. Plug another usb 3 device into it and see what speeds you get. If you're not running at close to the max speed of the device then either you have the wrong driver for the card or it is defective. If the device works properly then something is up with your enclosure.

I have an asmedia 1031 card and I have no issues reaching the rated speeds of 95mb/s on my sd cards and between 300-400 mb/s on my mx100 ssd.
 
Did the speed ever run faster than the 14MB/s? Maybe speed up past 14MB/s after a while?
You won't saturate a USB 3.0 or SATA III connection with 1-100KB files.
 
Only some comments about USB performance:
- It's impossible to reach max USB 3.0 bandwidth. Max I've seen was ~450MB/s
- USB 3.0 controller without good drivers will work at USB 2.0 bandwidth max so it's ~32MB/s in most cases
- If USB driver isn't optimized and is sharing bandwidth with other devices then max bandwidth will be lower ( sometimes ~20MB/s )
- I don't think that Linux has good drivers to handle USB 3.0. If there is no good driver then you may see bandwidth even lower than USB 2.0
- Windows 8/10 built-in drivers are often corrupted in some way and can also lock at max ~30-40MB/s
- That USB enclosure is clearly designed for Windows so it probably requires some kind of driver to run faster ( even if it's not asking for driver then will be something in Windows )
- On USB random operations can be lower than expected. Even on SSD it's not much more than ~40MB/s. However if you are moving large image files then it should base on sequential operations.

That's all for now. I just see that reaching optimal USB performance is hard. I'm often testing USB 3.0 devices and most of them stuck at lower bandwidth than they should because of driver issues or hardware design.
 
Have you run any benchmarks on the SSD drive through the USB 3.0 interface? To see what it's capable of?

USB 3.0 has a high maximum bandwidth, but the USB protocol has a decent amount of overhead that chips away at this.
 
Thanks for the suggestions. I copied a large file to it on my desktop and it did about 50% better.

I haven't looked at this much before as I don't usually copy that much data to it (when I'm waiting for it to finish.) I needed to update VMware so I wanted a copy of a VM before I proceeded.

I should boot up Windows on that PC and see if it does batter. That would tend to indicate driver support issues.

Thanks!

Edit: I tested on my laptop running Windows 10 and saw essentially the same performance. Throughput on a large file (~1/2 GB) varied between 14MB/s and 15GB/s. occasionally dropping as low as 10GB/s. Most transfers started about 24 MB/s and dropped to 14 GB/s. Some sustained 24 MB/s for the entire transfer. I do not consider this to be significantly better than performance under Linux.

If I google the chipset name ("ASMedia 2105 SATA bridge firmware") I do find some information about firmware updates for the device so I might look into that. I also wonder if GC/trim (and lack thereof) could cause a problem. I've written enough data to the drive to have filled it more than once. Trim is not enabled in the automount for Linux and I'm not sure if GC works with NTFS. If the drive controller has to erase block by block to write a file it seems like that would slow things down a lot.

The other thing that occurs to me
 
Last edited:
I wish I could recall where that last thought was going. Age taking its toll I suppose. ;)

I spent some more time investigating this. In particular I ran some benchmarks under Windows. That's not my typical use case but if this H/W is supported at all, it will be supported best in that environment. I also tried some different H/W. I have a USB3 drive sled and also a new 850 EVO :D.

But first the stuff that matters. I put the EVO into the sled and partitioned it half and half NTFS and EXT4. On Linux I copied the Win10 ISO to both partitions and timed the operation as a crude measure of disk throughput. The file copied in under 10 seconds to the EXT4 partition for a BW of 411 MB/s. Copy to the NTFS partition took about 16 seconds for throughput about 250 MB/s. Both are reasonable numbers. Just to confirm, I copied the same file to the MX100 in the Sabrent enclosure and it took 2:40 for a throughput of 25.5 MB/s confirming my initial experience. By contrast File Explorer reported copying that file to the NTFS partition on Win10 using

On Windows I ran proper benchmarks. First I benched the boot drive on the system, a Crucial MX550. I see it has the same issue seen in other Crucial drives with slow reads at lower block sizes.

Some of the benchmarks look pretty bogus now that I took a second look at them. Suffice to say that the MX100 had much lower performance numbers than the maximum throughput would suggest.
 
Back