Slow USB 3.0 speeds

[Goi]

Hi,

I have a new 2016 Dell XPS 13 with Windows 10 installed. I also have an external USB 3.0 drive with a Samsung SSD in it. I've noticed recently that the transfers to and from the drive top out at about only 80MB/s, even though the drive has previously been benchmarked on other systems (ATTO/Crystaldiskmark) to reach much higher speeds. Running Crystaldiskmark on the XPS13 also confirms the slow transfer speeds. Changing to another USB port didn't help either, and Device Manager shows all drivers installed with no errors.

Is there some special driver or something I don't have that's causing sub-optimal speeds?

 

[frowertr]

What's the drive in the laptop? That is likely your bottleneck if it's mechanical.

 

[myocardia]

...

 

[Coup27]

Windows 10 comes with a built in USB3 driver but you can check the Dell website to see if they have released a specific USB3 driver for your laptop.

If not then it's most likely going to be a crappy USB3 controller inside your SATA>USB3 adapter. If you choose to replace it do some research on one which supports USAP and try and get the manufacturer to confirm it's max sequential read and writes.

 

[Insert_Nickname]

Windows 10 comes with a built in USB3 driver but you can check the Dell website to see if they have released a specific USB3 driver for your laptop.

I would recommend sticking with the Windows provided driver. Because unless Dell is licensing UASP, using a manufacturer provided driver often removes support for it.

If not then it's most likely going to be a crappy USB3 controller inside your SATA>USB3 adapter. If you choose to replace it do some research on one which supports USAP and try and get the manufacturer to confirm it's max sequential read and writes.

Performance can also vary tremendously with the kind of transfer used. If its sequential you should expect 250-300MB/s, with UASP 375-425MB/s is possible. If you're transferring a lot of small(er) files without a UASP supporting external enclosure, 80-100MB/s sounds quite realistic.

 

[VirtualLarry]

I would recommend sticking with the Windows provided driver. Because unless Dell is licensing UASP, using a manufacturer provided driver often removes support for it.



Performance can also vary tremendously with the kind of transfer used. If its sequential you should expect 250-300MB/s, with UASP 375-425MB/s is possible. If you're transferring a lot of small(er) files without a UASP supporting external enclosure, 80-100MB/s sounds quite realistic.

My Seagate Expansion 5TB Desktop External HDDs, USB3.0 interface, when I copy files from my internal M.2 PCI-E SSD, in Win7 64-bit, I get an initial transfer rate of 1+GB/sec, then it slows down to 145-170MB/sec copying files to the HDD. (ISO files.)

Does that suggest that the Seagate external HDD enclosure supports UASP, since it's faster than 80MB/sec?

 

[Insert_Nickname]

My Seagate Expansion 5TB Desktop External HDDs, USB3.0 interface, when I copy files from my internal M.2 PCI-E SSD, in Win7 64-bit, I get an initial transfer rate of 1+GB/sec, then it slows down to 145-170MB/sec copying files to the HDD. (ISO files.)

If you're seeing 1GB/s+ transfer rates, its some internal buffer getting filled. That simply isn't possible today, even with current 10Gbit USB 3.1 implementation. 145-170MB/s isn't half bad for a regular single HDD however.

On a good day I can get ~800MB/s (sequential) out of an Asmedia 1142 controller, but that requires some speciality hardware (f.x. external RAID), since its above SATA3 speeds.

Does that suggest that the Seagate external HDD enclosure supports UASP, since it's faster than 80MB/sec?

You can quickly check if it does. If it supports UASP, it will be listed as a "UAS device (USB attached SCSI)" under storage devices in device manager.

Edit; Win7 doesn't have a built-in USB3(.1) driver, so for UASP support you're at the mercy of your mainboard manufacturer. ASUS f.x. has their own Win7 UASP implementation.

 

[h9826790]

If that slow speed only happen on writing, but not reading. That may be because no TRIM available via USB connection.

Without TRIM, GC cannot zero the cell which no longer require to store any data under the file system. Therefore, in the controller's point of view, the SSD is actually "full" after some time (no free cell ready for immediate write action), which will greatly slow down the writing process.

To solve this issue. You have to keep some free space on the SSD that NEVER been written since it was erased. That means, you have to SECURE erase the whole SSD, and then partition your SSD. e.g. a 1T SSD, partition it into 800G and 200G partitions. Only format the 800G partition and let the OS to use it. Leave that 200G unformatted, which means the OS CANNOT see it, and CANNOT write to it. Therefore, GC can use that ~20% of the "free space" to maintain the write speed.

Since the problem exist in benchmark, that means the problem is not the famous slow reading firmware bug which affected the 840 Evo long time ago. However, if your SSD is actually the 840 Evo, and you hasn't update the firmware yet, you better do it after you backup all your data.

 

[Goi]

What's the drive in the laptop? That is likely your bottleneck if it's mechanical.

It's a M.2 256GB SSD, and I'm pretty sure it isn't the bottleneck. Benchmarks have it at over 1GB/s transfer speeds

All USB transfers go through the CPU. The faster the CPU, the faster the transfers. USB 3.0 just exaggerates the differences compared to USB 2.0, because of just how much faster it has the capacity to be.

Are you comparing the laptop with fast desktop CPUs? If so, that's likely accounting for the difference. The two models (gold or silver) of that laptop have either a Skylake i5u, or a Skylake i7u, neither of which is anywhere near the clockspeed of the better Haswell or Skylake desktop CPUs.

I'm comparing it with another 2015 Lenovo Thinkpad with what I think is a Core i5 Haswell/Broadwell (I don't have it anymore so I can't confirm) and I think an Ivy Bridge i7-3770 desktop.

The XPS13 I currently have has an i5-6600. Are you saying that a current generation quad core laptop CPU can't muster more than 80-90MB/s over USB 3.0?

Performance can also vary tremendously with the kind of transfer used. If its sequential you should expect 250-300MB/s, with UASP 375-425MB/s is possible. If you're transferring a lot of small(er) files without a UASP supporting external enclosure, 80-100MB/s sounds quite realistic.

I was copying a large VM to back it up on the external drive. Not sure if it's many small files though I don't think so. However, CrystalDiskMark also showed similar results.

 

[Phynaz]

If that slow speed only happen on writing, but not reading. That may be because no TRIM available via USB connection.

Without TRIM, GC cannot zero the cell which no longer require to store any data under the file system. Therefore, in the controller's point of view, the SSD is actually "full" after some time (no free cell ready for immediate write action), which will greatly slow down the writing process.

To solve this issue. You have to keep some free space on the SSD that NEVER been written since it was erased. That means, you have to SECURE erase the whole SSD, and then partition your SSD. e.g. a 1T SSD, partition it into 800G and 200G partitions. Only format the 800G partition and let the OS to use it. Leave that 200G unformatted, which means the OS CANNOT see it, and CANNOT write to it. Therefore, GC can use that ~20% of the "free space" to maintain the write speed.

Since the problem exist in benchmark, that means the problem is not the famous slow reading firmware bug which affected the 840 Evo long time ago. However, if your SSD is actually the 840 Evo, and you hasn't update the firmware yet, you better do it after you backup all your data.

Trim and garbage collection are not related. Garbage collection occurs regardless of trim.

 

[h9826790]

Trim and garbage collection are not related. Garbage collection occurs regardless of trim.

Even though GC will work regardless if TRIM is there or not, but TRIM will make GC work much much better. They are somehow related, not totally independent.

GC can only recover the cell that marked no longer occupy with useful data. without TRIM, GC cannot recover the cell that no longer use by the OS, but occupied by the useless data. Because on the controller's point of view, that cell is occupied.