USB drives bad performance, low speed

Hi!

I have experienced very low speeds when trying to copy large files (over 2GB, up to 8GB) to a USB drive. This happened first with FAT32 formatted USB drives, and when I changed to using NTFS formatted USB drives for files larger than 4GB, results were the same: the copying speed is really low, and it can take hours to copy a large file.

Has anybody solved this? I googled around, and found several other cases of the same problem, and even some comments regarding a supposed kernel problem, which hadn’t yet been paid attention to.

Thanks!

On Sat, 19 May 2012 03:16:02 +0000, fkereki wrote:

> I have experienced very low speeds when trying to copy large files (over
> 2GB, up to 8GB) to a USB drive. This happened first with FAT32 formatted
> USB drives, and when I changed to using NTFS formatted USB drives for
> files larger than 4GB, results were the same: the copying speed is
> really low, and it can take hours to copy a large file.
>
> Has anybody solved this? I googled around, and found several other cases
> of the same problem, and even some comments regarding a supposed kernel
> problem, which hadn’t yet been paid attention to.

Can you give us some hard data? File of what size took how long to copy
over?

USB 1.1 is particularly slow. Make sure you’re actually using USB 2.0
ports and devices (or 3.0 if you’ve got it available).

USB in general is not incredibly fast, and with large files going to the
device, the write buffer can fill up fairly quickly - and the system will
hold writes until the buffer has flushed.

You /may/ be seeing something that’s entirely normal. If you tell us
more about the hardware and some specific hard data as indicated above,
we will better be able to tell you if this is normal or not.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

fkereki wrote:

>
> Hi!
>
> I have experienced very low speeds when trying to copy large files
> (over 2GB, up to 8GB) to a USB drive. This happened first with FAT32
> formatted USB drives, and when I changed to using NTFS formatted USB
> drives for files larger than 4GB, results were the same: the copying
> speed is really low, and it can take hours to copy a large file.
>
> Has anybody solved this? I googled around, and found several other
> cases of the same problem, and even some comments regarding a supposed
> kernel problem, which hadn’t yet been paid attention to.
>
> Thanks!
>
>
> –
> fkereki
> ------------------------------------------------------------------------
> fkereki’s Profile: http://forums.opensuse.org/member.php?userid=11471
> View this thread: http://forums.opensuse.org/showthread.php?t=475403

What version of openSUSE?
KDE or Gnome?

Single large files of like 8GB would not copy to FAT
But regardless, such a file would take quite some time. It is often the case
that cheap USB flash drives have poor performance stats, especially in the
write to mode.

In openSUSE 12.1 there were freezing issues with the initial release, but
updates seem to have fixed this, has for me.

A point to note and one I think needs attention. The system gives
notification of copy complete to a USB before it’s really finished, if your
USB has a LED you’ll see that it continues working long after the
notification, as is verifies the copy.

What kernel version are you using ? The 3.1.10 kernel on openSUSE-12.1 did fix some USB issues, where we discussed that kernel release here: http://forums.opensuse.org/forums/english/other-forums/community-fun/general-chit-chat/474637-new-kernel-3-1-10-1-9-1-a.html

I noted some marginal improvements with my USB-3.0 device with that kernel release and the closest I could find to one that might explain the improved performance I have observed with USB-3.0 is this one Bug 719416 - writing to usb flashdisk uses too much cpu and makes system unresponsive. I note that is NOT focused at USB-3.0 and it also does not appear to describe the sort of transfer speeds I am work with, but still possibly if you do not have that kernel version on your openSUSE-12.1 you could update to it (as it is a nominal openSUSE-12.1 update).

I assume, of course, that you are copying to a GNU/Linux file system or to an NTFS system (and not to a FAT32 which of course will have difficulties with large files).

On 2012-05-19 05:16, fkereki wrote:
>
> Hi!
>
> I have experienced very low speeds when trying to copy large files
> (over 2GB, up to 8GB) to a USB drive. This happened first with FAT32
> formatted USB drives, and when I changed to using NTFS formatted USB
> drives for files larger than 4GB, results were the same: the copying
> speed is really low, and it can take hours to copy a large file.

Please give figures, and details of your usb hardware. Flash sticks are
slow at writing, some very much so.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Hi! Thanks for the answers; let’s have some data.

First, about USB:

> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 003: ID 1e4e:0100  
Bus 001 Device 060: ID 04f3:0232 Elan Microelectronics Corp. 
Bus 001 Device 005: ID 046d:c317 Logitech, Inc. Wave Corded Keyboard

and also

> lsusb -t
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
        |__ Port 1: Dev 3, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
        |__ Port 3: Dev 60, If 0, Class=HID, Driver=usbhid, 1.5M
        |__ Port 4: Dev 5, If 0, Class=HID, Driver=usbhid, 1.5M
        |__ Port 4: Dev 5, If 1, Class=HID, Driver=usbhid, 1.5M

After (auto) mounting the HP USB drive, I get:

> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 003: ID 1e4e:0100  
Bus 001 Device 060: ID 04f3:0232 Elan Microelectronics Corp. 
Bus 001 Device 005: ID 046d:c317 Logitech, Inc. Wave Corded Keyboard
**Bus 001 Device 064: ID 03f0:5307 Hewlett-Packard** 

so I’m guessing it’s OK; I don’t have USB3 devices, but the disk is plugged as USB2.

As to the auto-mounting features, I don’t see anything strange:

> mount
...
*...snipped plenty of other lines...*
...
/dev/sdc1 on /media/HPV165W type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

Then, I copied a 6.4GB file to the disk, which had almost 9GB free, and had been recently re-built with mkfs.ntfs.

> time cp $HOME/Television/_TO_SEE_/mybigfile.mkv /media/HPV165W/

real    177m15.353s
user    0m0.252s
sys     0m26.757s
fkereki@fkereki-desktop:~> dir /media/HPV165W/*mkv
-rw------- 1 fkereki users 6800876294 May 19 16:40 /media/HPV165W/mybigfile.mkv

As you see, it’s just short of 3 hours for a bit over 6GB… isn’t something wrong there?

On 2012-05-20 00:36, fkereki wrote:

> so I’m guessing it’s OK; I don’t have USB3 devices, but the disk is
> plugged as USB2.

You would have to look at dmesg output after plugging the device - and
while writing to see if there are errors.

> Then, I copied a 6.4GB file to the disk, which had almost 9GB free, and
> had been recently re-built with mkfs.ntfs.

Is it a flash device, or a real hard disk?

Is it connected via external hub?

> As you see, it’s just short of 3 hours for a bit over 6GB… isn’t
> something wrong there?

Yes, indeed. 36 MB/m.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Hi!

Here are some answers. dmesg | grep -i usb shows

[1212442.993033] usb 1-3: new high-speed USB device number 64 using ehci_hcd
[1212443.109412] usb 1-3: New USB device found, idVendor=03f0, idProduct=5307
[1212443.109416] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1212443.109419] usb 1-3: Product: v165w
[1212443.109420] usb 1-3: Manufacturer: hp
[1212443.109422] usb 1-3: SerialNumber: 002215D21FFBAC2152CF0060
[1212443.114824] scsi36 : usb-storage 1-3:1.0
[1212664.134030] usb 1-3: reset high-speed USB device number 64 using ehci_hcd
[1212695.110047] usb 1-3: reset high-speed USB device number 64 using ehci_hcd
[1212738.118040] usb 1-3: reset high-speed USB device number 64 using ehci_hcd
...
... *many, many more of the same*
...
[1226415.110020] usb 1-3: reset high-speed USB device number 64 using ehci_hcd
[1230251.110018] usb 1-3: reset high-speed USB device number 64 using ehci_hcd
[1231877.811398] usb 1-3: USB disconnect, device number 64

I had googled the “reset high-speed USB device number” message, and found a suggestion: remove “ehci_hcd”. However, modprobe -l showed

# modprobe -l | grep hcd
kernel/drivers/usb/host/whci/whci-hcd.ko
kernel/drivers/usb/host/oxu210hp-hcd.ko
kernel/drivers/usb/host/isp116x-hcd.ko
kernel/drivers/usb/host/isp1362-hcd.ko
kernel/drivers/usb/host/xhci-hcd.ko
kernel/drivers/usb/host/sl811-hcd.ko
kernel/drivers/usb/host/u132-hcd.ko
kernel/drivers/usb/host/r8a66597-hcd.ko
kernel/drivers/staging/usbip/vhci-hcd.ko

and there was no ehci_hcd to remove.

The device is a flash disk, and I plugged it directly at the back of the motherboard.

Thanks for your help; any ideas or experiments to do?

Further to my above post, and again I do not know how relevant, but in addition to the USB bug I noted, there is also a bug in NTFS-3G that slowed down data transfers to NTFS drives on GNU/Linux, where it appears to me that it was not possible for the bug fix to make it in the ntfs-3g version in openSUSE-12.1.

I say that because if one looks at the ntfs-3g change log on their website: NTFS-3G: Changelog for the Advanced Versions one can read that Version 2011.10.9AR.1 (Nov 7, 2011) had this fix:


Version 2011.10.9AR.1 (Nov 7, 2011)
........
fixed huge data writes
........

checking the version of ‘ntfs-3g’ on openSUSE-12.1 I note it is " ntfs-3g-2011.4.12-3.1.2.x86_64 " which is the previous ntfs-3g version and that openSUSE-12.1 version does not have that fix.

Ergo, if you have an openSUSE version without the 3.1.10 kernel there is a bug that slows down USB transfers, and also the version of ntfs-3g that is packaged with openSUSE-12.1 also has an unfixed bug impact large data writes to an NTFS drive.

Hi!

I just checked; my kernel is 3.3.4, and the ntfs-3g version is dated 2011.4.12, so it would seem I should be safe on those counts.


# uname -a
Linux fkereki-desktop **3.3.4-22-desktop** #1 SMP PREEMPT Fri Apr 27 20:36:58 UTC 2012 (d42fe44) i686 i686 i386 GNU/Linux

# zypper info ntfs-3g
Loading repository data...
Reading installed packages...

Information for package ntfs-3g:

Repository: Current OSS
Name: ntfs-3g
**Version: 2011.4.12-3.1.2**
Arch: i586
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 219.0 KiB
Summary: NTFS Support in Userspace
Description: 
NTFS-3G allows for read/write access to NTFS partitions which can be
shared with Windows XP, Windows Server 2003, Windows 2000, Windows
Vista and Windows Seven.

However, there is an even newer version (dated 2012.1.15) so I’ll give it a try, and also try moving up to kernel 3.3.6-24, just in case.

Any other suggestions?

Thanks for your help!

Your kernel is very new, and not the standard openSUSE-12.1. kernel.

But your ntfs-3g is the standard version, and it does have the bug I noted. ie it is NOT fixed for ntfs transfers.

Let me know how that works. I am curious.

I do NOT recommend moving to kernel 3.3.6-24 ‘just in case’ without first checking to see if there is a specific bug that is fixed (and you have seen the bug report noting the fix is definitely in 3.3.6-24). my guess is that is not the case. Can you point to a bug fix here ? New kernels can always cause other problems IMHO and hence caution, especially with a kernel, can be a good idea (again IMHO).

On 2012-05-20 05:56, fkereki wrote:
>
> Hi!
>
> Here are some answers. dmesg | grep -i usb shows

No mentions of errors, usb 1…

> I had googled the “reset high-speed USB device number” message, and
> found a suggestion: remove “ehci_hcd”. However, modprobe -l showed

Mmm.

> Thanks for your help; any ideas or experiments to do?

(moan/grumble) No…


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

How do you plan to install the newer version ?

I note in factory snapshot there is a 2012.1.15 version build against the factory snapshot kernel in repository :


http://download.opensuse.org/factory-snapshot/repo/oss/

and I have no idea how that will perform against a non-factory kernel.

I note the factory snapshot source code is here:


http://download.opensuse.org/factory-snapshot/repo/source/suse/src/

with the rpm src file " ntfs-3g_ntfsprogs-2012.1.15-2.1.src.rpm "

out of curiousity I downloaded that rpm and on my 64-bit openSUSE-12.1 rebuilt it with:


rpmbuild --rebuild ntfs-3g_ntfsprogs-2012.1.15-2.1.src.rpm

which in directory /home/oldcpu/rpmbuild/RPMS/x86_64/ created the rpms:

  • libntfs-3g83-2012.1.15-2.1.x86_64.rpm
  • libntfs-3g-devel-2012.1.15-2.1.x86_64.rpm
  • ntfs-3g-2012.1.15-2.1.x86_64.rpm
  • ntfsprogs-2012.1.15-2.1.x86_64.rpm

Now I currently have installed:

  • libntfs-3g81-2011.4.12-3.1.2.x86_64
  • ntfs-3g-2011.4.12-3.1.2.x86_64
  • ntfsprogs-2011.4.12-3.1.2.x86_64

and I am tempted to replace that with the rebuilt:

  • libntfs-3g83-2012.1.15-2.1.x86_64.rpm
  • ntfs-3g-2012.1.15-2.1.x86_64.rpm
  • ntfsprogs-2012.1.15-2.1.x86_64.rpm

and reboot and test.

But I have not done so (yet). Caution and a fear of breaking things is slowing me down.

Those speeds are not good. I do not know enough about USB devices nor drivers to help you.

I do note that am getting superior transfer speeds on my 64-bit openSUSE-12.1.

This is a 1.9 GByte test file. I picked this size file as it works well with VFAT and NTFS formats


-rw-r--r-- 1 oldcpu users 1928069215 Nov 21 07:08 testfile.mkv

I first copied it from a USB-3.0 PCI-e card to my USB-3.0 memory stick (formatted as VFAT)


oldcpu@corei7:~> time cp /home/oldcpu/data/testfile.mkv /media/KINGSTON/testfile.mkv
real    0m45.266s
user    0m0.029s
sys     0m3.740s

Thats 45 seconds for a 1.9 GByte file. That is NOT great speeds for USB-3.0 but frankly I am suspicious of the GNU/Linux driver speeds for VFAT.

Then I copied it from the same USB-3.0 PCI-3 card to one of my USB-3.0 external hard drives (formatted as NTFS)


oldcpu@corei7:~> time cp /home/oldcpu/data/testfile.mkv /media/54BAB88FBAB86F5C/testfile.mkv

real    0m25.487s
user    0m0.038s
sys     0m3.133s

That is 26 seconds for a 1.9 GByte file. Again, that is not great speeds for USB-3.0, but frankly despite recent NTFS-3G improvements, I am suspicious of the ntfs-3g driver speeds (and also a bit suspicious of the USB-3.0 driver speeds (xhci_hcd)).

For the record, my kernel:


Linux corei7 3.1.10-1.9-desktop #1 SMP PREEMPT Thu Apr 5 18:48:38 UTC 2012 (4a97ec8) x86_64 x86_64 x86_64 GNU/Linux

and the ntfs-3g version:


libntfs-3g83-2012.1.15-2.1.x86_64
ntfsprogs-2012.1.15-2.1.x86_64
ntfs-3g-2012.1.15-2.1.x86_64

yes I took a chance and installed the latest ntfs-3g driver after custom rebuilding it for my PC.

Along those lines, I should also note in my dmesg I am seeing many of these errors:


xhci_hcd 0000:05:00.0: WARN: Stalled endpoint

… which does not bode too well for the USB-3.0 driver, … but thats a bit off topic as this thread is not about USB-3.0.

… just to confirm that speed was not a fluke, and to confirm this would work with very large files, I copied this 9.3 GByte file:


-rw-r--r-- 1 oldcpu users 9371439760 Dec  3 05:15 testlarge.mkv

from same USB-3.0 PCI-e card to the same USB-3.0 external hard drive (formatted NTFS) with the updated recent ntfs-3g driver …

This is the result:


time cp testlarge.mkv /media/54BAB88FBAB86F5C/testlarge.mkv

real    2m17.856s
user    0m0.180s
sys     0m25.562s

… which is a slightly slower speed for the 9.3 GByte file (vs the 1.9 GByte file) but still faster than the slow times you were reporting. But its a bit disappointing for USB-3.0 speeds.

Apologies, but I do not know why your transfer speeds are so slow.

Hi!

I plan to install the newer version simply through zypper; I’m not (too much) worried about that, because I’m using the Tumbleweed repositories. (IMO, in “risk” terms, Tumbleweed is a bit above the default repositories, but below the factory ones. I have had problems with factory, but never with Tumbleweed.) I’ll give this a try today if possible, and let everybody know the results. The Tumbleweed version is the 2012.1.15, so it should match what you got. Thanks for the ideas!

Hmmm … its not clear to me that the Tumbleweed kernels you have been using have the interim bug #719416 fix inside … Access Denied (see comment #30). i.e. its a custom fix for that bug report, and it does not close the bug report.

Reading through the bug report, I’m afraid you are right…

After all the updates, I tried copying a 2.6GB file:

> time cp file.mkv /media/HPV165W/

real    4m42.525s
user    0m0.043s
sys     0m7.928s

This is far better than earlier, so I’m hoping the problem is solved!

I’ll try some other files, though, to make sure this isn’t just a fluke.

Thanks to everybody!