Copying To USB Is Very Slow

[Krishna]

Copying files from hard disk to Usb or Usb to Hard Disk is very slow in Ubuntu 10.04..

Is there a way to speed up the process of copying with the installation of additional softwares...

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: nautilus 1:2.30.1-0ubuntu1.1
ProcVersionSignature: Ubuntu 2.6.32-24.41-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-generic i686
Architecture: i386
Date: Thu Aug 26 14:03:27 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
 LANG=en_IN.utf8
 SHELL=/bin/bash
SourcePackage: nautilus

[David Sugar (dyfet-deactivatedaccount)]

Thank you for this report. This may depend on the underlying filesystem used on the USB drive, it's properties, and whether it is a filesystem supported natively or through fuse. Also, not all USB ports on a PC are necessarily the same. Some systems have a mixture of USB 1.0 and 2.0 ports, and USB 1.0 tends to be much slower in base I/O speeds. Finally, any USB drive likely will be slower than a build-in harddisk simply because often you have a USB device that then converts USB to SATA or PATA bus to actually talk to the actual drive. If you can identify the filesystem on the USB drive, it may help better understanding this issue.

[Krishna (krishnab)]

It's USB 2.0 I am using.. But I feel the Ubuntu is slow in copying to USB's... Is there a software to increase speed, and pause the copy in between etc..

[Jeremy Foshee (jeremyfoshee)]

Hi Krishna,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Krishna (krishnab)]

Hi .. Thanks for the info..

I have installed the kernel from the site
https://wiki.ubuntu.com/KernelMainlineBuilds

what should I do next...
Is there a solution now...

[Antonio J. de Oliveira (ajoliveira)]

I have observed this behavior on 64-bit xubuntu, either using thunar, nautilus or just cp to drive. Most of the times USB drives, eithe ext3 or fat perform well, but I have observed extreme sluggishness making the drve totally unusable. Rebooting corrects the problem. This was observed on 2 identical PCs.
It happened to me when I was in the need of finishing a transfer operation in high speed...Next time I will try:

sudo hdparm -t /dev/sdb1

/dev/sdb1:
 Timing buffered disk reads: 54 MB in 3.00 seconds = 17.99 MB/sec

and:

sudo seeker /dev/sdb1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb1 [953867MB], wait 30 seconds..............................
Results: 60 seeks/second, 16.66 ms random access time

to compare with the values I am getting now.

I will try to unmount and mount by hand e.g

sudo mount /dev/sdb1 ~/ext/tmp

assuming sdb1 is the drive shown on:

ls /dev

and

~/ext/tmp

exists (note the ~ is the same as /home/<user>)

I am still to understand the automount system in Lucid, as neither autofs nor autofs5 are installed in my systems. Hal is probably to blame for what we are observing. Will conduct a few trials.

Cheers

Antonio

[Antonio J. de Oliveira (ajoliveira)]

Krishna, please do:

#aptitude search hal

and:

#aptitude search autofs

what do you have installed?

(there is still usbmount and pmount...)

[Krishna (krishnab)]

THis is the output I got for above commands...

)<:~ $ aptitude search hal
The program 'aptitude' can be found in the following packages:
 * aptitude
 * aptitude-gtk
Try: sudo apt-get install <selected package>
)<:~ $ aptitude search autofs
The program 'aptitude' can be found in the following packages:
 * aptitude
 * aptitude-gtk
Try: sudo apt-get install <selected package>

Thanks..

In 10.10 64 Bit, which the os I am using now, has a good copying speed...

Then I experience a long delay in copy at the last percentage... Or sometimes 0 seconds remaining and still copying...

What is the problem with it.. I experience this while copying to USBs..

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu development release http://cdimage.ubuntu.com/daily-live/current/ . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Antonio J. de Oliveira (ajoliveira)]

It is an issue with 10.04, I confirm it. I upgraded to 10.10 and the problem vanished. 64-bit. Don't hide it, it's there.

[shinji2001xyz (shinji2001xyz456)]

Is the bug closed for good? I have horrible transfer rates on any usb device, using any usb port of my PC...

It starts copying fast, then it hangs for a while at 99%

Via CLI with cp, it copies 100% of the file, e.g. a 1.6Gb iso file in 3 min, then hangs for 6 more min !!!!

Is there another bug?

Do I need to upgrade to 11.04 to get it fixed?

I wished it was fixed for good in 10.04 64-bit version...

[Antonio J. de Oliveira (ajoliveira)]

Dear shinji2001xyz:

Do check your fstab for contradictory statements, it was my case, I had an fstab trying to mount sdb1 in ntfs, i was the real source of my problem. On my part I consider this bug closed. I still do use a few lucid servers (32-bit) and those, for the time being, do not exhibit that behavior.

True that updating to maverick immediately cleared the problem.

Cheers

Antonio

[shinji2001xyz (shinji2001xyz456)]

Thanks for your feedback Antonio, I plan to upgrade to 10.10 anyway.

But it's strange that this USB problem appeared one day, and then will disappear with the upgrade.

cheers

[Peng (pengwg)]

This problem may have been fixed by the most recent mainline kernel releases 2.6.38.1 and 2.6.37.5.

In the change log:

Alan Stern (2):
USB: serial drivers need to use larger bulk-in buffers
USB: move usbcore away from hcd->state

I did my test with 2.6.38.1 kernel on Maverick and the copying speed appeared improved. Some one may want to do more test and update the bug report.

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/197762

[Alexander Amelkin (spirit-rc)]

Please fix this bug in 10.04 LTS. That "LTS" stands for "Long Term Support", so please provide it, don't force users to switch to an interim 10.10 version. If fixing this bug requires porting 2.6.38.1 or whatever kernel to 10.04, please do so.

[cnctech (rod-syil)]

Copying to USB external drive is very slow and in most cases stops copying. It would seem this is so for large files.
I have had problems with files over 200MB. Small files copy without a problem. Copying large files 1G or more fails or slows to taking hours to complete a copy. As the copy process goes beyond 200Mbyes the process slows down to almost stoping. I cannot copy a whole directory. I cannot copy any files of more than 200mb without problems.
Clean boot with out running othe programs does not help. I have check drive permissions , but this does not explain why large files fail too.
Test system
D510M0 Intel mother board with 2G ram. Ubuntu 10.04.2 LTS with all up dates. Samsung 320G external drive format 32.

Bottom line copying large files to USB drive does not work.

[riiidaa (rovercity)]

I have this problem on my 10.04 LTS server, with a seagate 1TB usb2 drive I just purchased. (The disk was formatted with EXT4 whilst at home connected to an Ubuntu virtual machine on a Windows host that I then happily copied a bunch of large files to from a Samba share with write speeds approximately 14MB / sec)

Connected the same disk to my server yesterday and immediately hit this bug when trying to move files from the SCSI disk to the Seagate USB. The server is a DL360 G3.

My colleague pointed me at this bug report. I ran the following commands last night after remotely rebooting:

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.3 LTS
Release: 10.04
Codename: lucid

sudo hdparm -t /dev/sda1

/dev/sda1:
 Timing buffered disk reads: 4 MB in 3.93 seconds = 1.02 MB/sec

A woeful 1MB per sec...

This morning I did it again:

 sudo hdparm -t /dev/sda1

/dev/sda1:
 Timing buffered disk reads: 2 MB in 7.44 seconds = 275.24 kB/sec

which is pretty much useless.

What must I do? It seems to move from an LTS to a more recent non LTS release is the thing to do but this goes against my ideals of LTS

[riiidaa (rovercity)]

The status of bug #500069. is Won't fix because it was posted for a non LTS and now defunct series.

This bug 624510 needs addressing, it was posted correctly and affects 10.04 an LTS!

[Mark Tsigalnitsky (markmt1988)]

This is defiantly a known problem across the Ubuntu community. I'm very frustrated with the fact that this bug has been known since 2008 and still has not been resolved. I wish there was something I could do to assist in resolving this problem, but unfortunately I am unaware of what could be causing this. My transfer speeds begin at 60-80/mps and quickly decrease to about 3/mps. Not to mention when reaching 99% after waiting sometimes up to an hour, it gets hung up. I love using Ubuntu and enjoying the freedom to do what I please, but this seems to be a major problem that I run into on a very frequent basis.

[Mark Tsigalnitsky (markmt1988)]

P.S- I'm using Ubuntu 11.04 64-bit.

[Ming Lei (tom-leiming)]

Mark, could you help to collect usbmon during your usb storage performance test?
without this data, it is difficult to figure out what is wrong.

See Documentation/usb/usbmon.txt for instructions.

thanks,

[Igor Zubarev (igor.zubarev)]

Confirm for Ubuntu 11.10 64-bit oneiric. Very sloooooooooooooooooooooow......

[Igor Zubarev (igor.zubarev)]

3 Gb copy 1 hour.

[Ming Lei (tom-leiming)]

Hi Igor Zubarev,

On Sun, Oct 2, 2011 at 2:59 AM, Igor Zubarev <email address hidden> wrote:
> 3 Gb copy 1 hour.

It is very difficult to troubleshoot this problem without usb mon
trace, so could
you provide the trace result according to guide in Documentation/usb/usbmon.txt
or the link[1]?

[1], http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt

thanks,
--
Ming Lei

[Axis Mann (axismann)]

I have the same or similar problem with my MSI G41M4-F motherboard while running Lucid 10.04 I get slow usb copy speed to external hard drive around 3.5 MB/s (thats megabytes per sec). However, running Oneiric 11.10 on same hardware with same USB drive I get good copy speed around 33 MB/s which is almost 10 time faster and what one might expect for a USB 2.0 connection.

[Axis Mann (axismann)]

This is trace I got when I plugged in the USB drive. You need more?

f360ff00 2231146870 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
f360ff00 2231146882 C Ci:3:001:0 0 4 = 00010000
f360ff00 2231146884 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
f360ff00 2231146888 C Ci:3:001:0 0 4 = 00010000
f685ce00 2231146889 S Ii:3:001:1 -115:128 2 <
f685ce00 2233198903 C Ii:3:001:1 -2:128 0

[Ming Lei (tom-leiming)]

On Fri, Mar 9, 2012 at 5:10 AM, Axis Mann <email address hidden> wrote:
> This is trace I got when I plugged in the USB drive.  You need more?

Yes, you need to trace the traffic during the performance test on your
usb mass storage.

thanks,
--
Ming Lei

[Axis Mann (axismann)]

I further observed that the write speed to the external USB drive, for Lucid, is a lot better than the read speed. I'm seeing write speeds around 30MB/s which is ok. However, the read speed continues to be extremely slow. Nautilus was telling me that the file transfer speed was around 5 MB/sec when copying from the external USB drive to an internal SATA drive. I started a capture using the command

  cat /sys/kernel/debug/usb/usbmon/1u > /tmp/1u.mon.out

before connecting the external drive and then beginning the copy of a 5 GB file from the external USB drive using Nautilus to copy the file to an internal SATA drive. After about 100 MB, I killed the trace with the CTRL-C key and then cancelled the copy.

The trace is about 2.6 MB of plain text. How can I get that to you? Surely you don't want me to try to paste it here?

[Axis Mann (axismann)]

Ahhh..maybe I can deliver the trace using the Attachment feature this way?

[nickanor (sostentado)]

11.10, very slow

[Ming Lei (tom-leiming)]

Axis, looks your usb mass storage device has a bad read performance, and
looks nothing mistaken is observed in your trace.

See below traffic captured[1]:

It is a whole process to read 120K data from usb mass storage device, and
about 28ms is taken to get the 120K data from device, so the max read
performance is about (1000/28)*120K= 4MB/sec, which is near to your
observation. (120K is the max single transfer length)

Considered you are sure that writing has good performance, so usb host
controller and its driver should be OK, also all transfers are completed
successfully.

[1],
f6305800 715769963 S Bo:1:003:2 -115 31 = 55534243 5e000000 00f00000
80000a28 00020009 00000078 00000000 000000
f6305800 715770062 C Bo:1:003:2 0 31 >

......

f6305800 715785474 S Bi:1:003:1 -115 13 <
f6305800 715797937 C Bi:1:003:1 0 13 = 55534253 5e000000 00000000 00

On Sat, Mar 10, 2012 at 10:45 AM, Axis Mann <email address hidden> wrote:
> Ahhh..maybe I can deliver the trace using the Attachment feature this
> way?

[Axis Mann (axismann)]

However, as I reported originally, running Oneiric 11.10 on same hardware and reading from same USB drive I get good read speed around 33 MB/s which tends to indicate to me that the read peformance of my USB drive is not the issue.

Here's what hdparm reports for that drive on on Oneiric.

axismann@Hyperion:~$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 2800 MB in 2.00 seconds = 1399.92 MB/sec
 Timing buffered disk reads: 104 MB in 3.01 seconds = 34.54 MB/sec

However, when I try to do the same thing on Lucid, I get miserable read performance.

owner@Pluto:~$ sudo hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads: 2424 MB in 2.00 seconds = 1211.76 MB/sec
 Timing buffered disk reads: 16 MB in 3.09 seconds = 5.18 MB/sec

I did observe and report that the write peformance on Lucid is ok. It's just the read performance that isn't any good on Lucid.

Does that make sense to you that the drive would read at 34 MB/sec on Oneric if it's read peformance were indeed bad?

It seems to me that the evidence indicates a problem with Lucid. The symptom is poor read peformance on Lucid with normal read performance for that drive on Oneric.

[Ming Lei (tom-leiming)]

Axis, could you post the output of 'dmesg', 'lsusb -vv' and 'lspci -vv' on
Oneiric?

Also could you please post the usbmon trace on Oneiric?

[Axis Mann (axismann)]

do you want me to run the dmesg, lsusb, and lspci commands as super user or just ordinary user without administrative priviledges?

[Ming Lei (tom-leiming)]

On Wed, Mar 14, 2012 at 8:11 AM, Axis Mann <email address hidden> wrote:
> do you want me to run the dmesg, lsusb, and lspci  commands as super
> user or just ordinary user without administrative priviledges?

I think just ordinary user is OK.

[Axis Mann (axismann)]

Here is the usbmon trace from the Oneiric instance. I named it differently from the earlier trace I provided for Lucid. I obtained the trace using the same procedure I used earlier. I'll send the output of the dmesg, lsusb and lspci as a seperate attachment.

[Axis Mann (axismann)]

I guess I could have put it all in one attachment. Sorry about that. When I tried to redirect the lsusb and lspci output to a file, I saw some messages that indicated I needed root access so I ran the with both sudo and without. The lsusb and lspci output are named accordingly. I ran dmesg with sudo only although that probably could have been run as a normal user. Also, note that when I boot Oneiric, it's on the USB drive itself so the file transfer trace doesn't include any traffic for mounting the USB drive since it's already mounted. Operationally, when I turn on the computer, it boot's Lucid from an internal SATA hard drive. When I want to test a newer ubuntu release, I turn on the USB drive and reboot using the bios boot order to select the OS on the USB drive rather than Lucid on the interal SATA hard drive. Thus, the usbmon trace doesn't include any traffic prior to the file transfer since the USB drive is already mounted by the time I start the trace.

[Axis Mann (axismann)]

An additional thought/question. Shouldn't you want to look at the dmesg, lsusb, and lspci output from Lucid rather than Oneiric since the problem I am experiencing is on Lucid?

[Ming Lei (tom-leiming)]

On Wed, Mar 14, 2012 at 2:10 PM, Axis Mann <email address hidden> wrote:
> An additional thought/question.  Shouldn't you want to look at the
> dmesg, lsusb, and lspci output from Lucid rather than Oneiric since the
> problem I am experiencing is on Lucid?

Looks the problem is about ehci host controller driver, because the
'csw' completes
very slow on lucid release, but no such thing on Oneiric, see below trace:

Lucid trace:
f6305800 716082026 S Bi:1:003:1 -115 13 <
f6305800 716093942 C Bi:1:003:1 0 13 = 55534253 71000000 00000000 00

Oneiric trace:
f3ea8580 2484657937 S Bi:1:002:1 -115 13 <
f3ea8580 2484657945 C Bi:1:002:1 0 13 = 55534253 26b20000 00000000 00

Just have a quick look at Lucid ehci patches and found most of ehci
unlink/queue patches have been merged to lucid, so could you confirm
that you have updated
to the latest Lucid release? If not, please try 'sudo apt-get update&&
sudo apt-get
dist-upgrade', then redo the test to see if there are any improvements.

Thanks,

[Ming Lei (tom-leiming)]

On Wed, Mar 14, 2012 at 2:10 PM, Axis Mann <email address hidden> wrote:
> An additional thought/question.  Shouldn't you want to look at the
> dmesg, lsusb, and lspci output from Lucid rather than Oneiric since the
> problem I am experiencing is on Lucid?

Also could you post the output of 'lspci -vv -nn' so that I can search
if there are
any quirks for the ehci host controller?

[Axis Mann (axismann)]

I ran the 'sudo apt-get update && sudo apt-get dist-upgrade' command you requested but it appeared like the OS was already updated to the latest lucid release as it reported

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

when finished running the command. I then reran the hdparm command to check read speed but it continues to appear slow.

owner@Pluto:~$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 2434 MB in 2.00 seconds = 1217.46 MB/sec
 Timing buffered disk reads: 16 MB in 3.07 seconds = 5.21 MB/sec

The attached results from the 'sudo lspci -vv -nn command ' were produced by the Lucid instance.

[Axis Mann (axismann)]

An additional fact. When I boot a Lucid Live CD on my Dell Dimension, the same external USB drive that performs so poorly on my Intel G41M4-F motherboard works just fine testing with read speed of approx 30MB/s according to hdparm.

[Ming Lei (tom-leiming)]

Axis, could you try to install the kernel images in the link[1] to see if
it can fix your usb mass storage performance bug?

[1], http://kernel.ubuntu.com/~ming/bugs/624510/

Thanks,
--
Ming Lei

[Axis Mann (axismann)]

I'm not sure I know how to do that. Do I have to learn how to create and use a PPA to do that? How come there is more than one header file?

[Ming Lei (tom-leiming)]

On Fri, Mar 16, 2012 at 4:02 AM, Axis Mann <email address hidden> wrote:
> I'm not sure I know how to do that.  Do I have to learn how to create
> and use a PPA to do that?  How come there is more than one header file?

It is easy, just follow the steps below:

- install
sudo dpkg -i linux-headers-2.6.32-40_2.6.32-40.87_all.deb
sudo dpkg -i linux-headers-2.6.32-40-generic_2.6.32-40.87_i386.deb
sudo dpkg -i linux-image-2.6.32-40-generic_2.6.32-40.87_i386.deb

- reboot

- select 'linux 2.6.32-40-generic' in grub menu and boot it

- test your usb mass storage performance

Thanks
--
Ming Lei

[Axis Mann (axismann)]

Hi, I created a separate Lucid instance to test your changes. I put it on the external USB drive and then verified I could recreate the problem before I installed the kernel images you provided.

I reran the hdparm command to check the read speeds. The results looked reasonable. I was getting approx 30MB/s. I then tested reading and writing from the external USB drive to the computer's internal hard drive and back again to the external USB drive. Those results too looked reasonable. I was getting approx 30 MB/s both ways. That sure makes moving GB size files less painful!

Will I have to reinstall those kernel images you provided if Canonical pushes out another kernel update for Lucid or will your changes be present in any future kernel updates for Lucid?

Thanks.

[Axis Mann (axismann)]

During installation of the kernel image, I got some messages about a memory leak. Is that ok?

[Ming Lei (tom-leiming)]

On Fri, Mar 16, 2012 at 7:47 PM, Axis Mann <email address hidden> wrote:
> During installation of the kernel image, I got some messages about a
> memory leak.  Is that ok?

Looks you can ignore the memory leak message now, so could you make sure
if your usb mass storage performance can be improved after installing the
kernel images I provided?

If so, I will push the changes into official Lucid release.

Thanks,
--
Ming Lei

[Ming Lei (tom-leiming)]

On Sat, Mar 17, 2012 at 8:32 AM, Ming Lei <email address hidden> wrote:
> On Fri, Mar 16, 2012 at 7:47 PM, Axis Mann <email address hidden> wrote:
>> During installation of the kernel image, I got some messages about a
>> memory leak.  Is that ok?
>
> Looks you can ignore the memory leak message now, so could you make sure
> if your usb mass storage performance can be improved after installing the
> kernel images I provided?

BTW, you have to run the test with the change on your Intel G41M4-F, since
you only can reproduce the problem on this machine.

Thanks,

[Axis Mann (axismann)]

Hi, I went ahead and applied your kernel changes to my primary lucid installation which uses the Intel G41M4-F motherboard that I originally had the problem on. This is the same hardware I first tested your changes on except that this time I updated the lucid OS release installed on the internal SATA harddrive rather than the test instance of Lucid that I installed on the USB drive to pre-test your changes. I didn't see the memory leaks I saw earlier duing the test installation. However, I did see some fail messages that I didn't see earlier. Are those normal? Please see attached.

However, on a better note, just as before with the test instance, I now see better USB read speeds on my primary Lucid Installation, where I originally noticed the slow read speeds.

owner@Pluto:~$ sudo hdparm -tT /dev/sdb
[sudo] password for owner:

/dev/sdb:
 Timing cached reads: 2920 MB in 2.00 seconds = 1460.61 MB/sec
 Timing buffered disk reads: 106 MB in 3.02 seconds = 35.08 MB/sec
owner@Pluto:~$

I also copied a 4 GB file to and from the external USB hard drive to confirm that Nautilus reported read and write speeds of approx 30 MB/s.

The problem appears to be fixed.

Thanks for following up on this problem.

[Ming Lei (tom-leiming)]

Hi Axis,

On Sat, Mar 17, 2012 at 1:11 PM, Axis Mann <email address hidden> wrote:
> Hi, I went ahead and applied your kernel changes to my primary lucid
> installation which uses the Intel G41M4-F motherboard that I originally
> had the problem on.  This is the same hardware I first tested your
> changes on except that this time I updated the lucid OS release
> installed on the internal SATA harddrive rather than the test instance
> of Lucid that I installed on the USB drive to pre-test your changes.  I
> didn't see the memory leaks I saw earlier duing the test installation.
> However, I did see some fail messages that I didn't see earlier.  Are
> those normal?  Please see attached.

Looks just some vbox related services return failed. If you can't see such
kind of failures after rebooting, please ignore it simply.

>
> However, on a better note, just as before with the test instance, I now
> see better USB read speeds on my primary Lucid Installation, where I
> originally noticed the slow read speeds.
>
> owner@Pluto:~$ sudo hdparm -tT /dev/sdb
> [sudo] password for owner:
>
> /dev/sdb:
>  Timing cached reads:   2920 MB in  2.00 seconds = 1460.61 MB/sec
>  Timing buffered disk reads:  106 MB in  3.02 seconds =  35.08 MB/sec
> owner@Pluto:~$
>
> I also copied a 4 GB file to and from the external USB hard drive to
> confirm that Nautilus reported read and write speeds of approx 30 MB/s.

Looks it is a good news, but I am still not sure why the commit below
can fix your unlink performance issue.

       commit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream
       [PATCH] USB: EHCI: go back to using the system clock for QH unlinks

So could you help to install the packages under below link to make sure if
there is the performance issue on your G41M4-F with the packages?

       http://kernel.ubuntu.com/~ming/bugs/624510/lucid-40.87-release/

BTW: I just want to double check if the commit above does fix your issue.

Thanks,
--
Ming Lei

[Axis Mann (axismann)]

I don't understand what you are asking. It sounds like you are asking in #51 for me to install the changes you first mentioned in #43 and told me how to install in #45 with the commands

sudo dpkg -i linux-headers-2.6.32-40_2.6.32-40.87_all.deb
sudo dpkg -i linux-headers-2.6.32-40-generic_2.6.32-40.87_i386.deb
sudo dpkg -i linux-image-2.6.32-40-generic_2.6.32-40.87_i386.deb

I already reported back on two separate occasions that I have installed the changes from

 http://kernel.ubuntu.com/~ming/bugs/624510/

on my G41M4-F motherboard. First, on an instance of Lucid that I installed on the USB drive I was testing and then to the instance of Lucid on which I originally encountered the problem. In both cases, it was the same mother board, computer case, power supply, video card, keyboard, mouse, monitor, internal hard drive, and external USB drive. From comments you made in #49, you didn't appear to understand that I already reported having tested my changes on the G41M4-F motherboard in #45

Do you now want me install the changes yet a third time but this time you want me to get the changes
from "http://kernel.ubuntu.com/~ming/bugs/624510/lucid-40.87-release/?"

If you really do want me to install the same thing a third time, do you first want me to back out the previous installation I reported from #50?

[Axis Mann (axismann)]

Correction to comment in #52

From comments you made in #49, you didn't appear to understand that I already reported having tested your changes on the G41M4-F motherboard in #45.

[Ming Lei (tom-leiming)]

On Sun, Mar 18, 2012 at 12:43 AM, Axis Mann <email address hidden> wrote:
> I don't understand what you are asking.  It sounds like you are asking
> in #51 for me to install the changes you first mentioned in #43 and told
> me how to install in #45 with the commands
>
> sudo dpkg -i linux-headers-2.6.32-40_2.6.32-40.87_all.deb
> sudo dpkg -i linux-headers-2.6.32-40-generic_2.6.32-40.87_i386.deb
> sudo dpkg -i linux-image-2.6.32-40-generic_2.6.32-40.87_i386.deb
>
> I already reported back on two separate occasions that I have installed
> the changes from
>
>  http://kernel.ubuntu.com/~ming/bugs/624510/
>
> on my G41M4-F motherboard.  First, on an instance of Lucid that I
> installed on the USB drive I was testing and then to the instance of
> Lucid on which I originally encountered the problem.  In both cases, it
> was the same mother board, computer case, power supply, video card,
> keyboard, mouse, monitor, internal hard drive, and external USB drive.
> >From comments you made in #49, you didn't appear to understand that I
> already reported having tested my changes on the G41M4-F motherboard in
> #45
>
> Do you now want me install the changes yet a third time but this time you want me to get the changes
> from  "http://kernel.ubuntu.com/~ming/bugs/624510/lucid-40.87-release/?"

The kernel image in the link above is certainly different with the one in
the link of http://kernel.ubuntu.com/~ming/bugs/624510/. In theory, it should
be same with your update from the official lucid release. But, as I said, I just
want to make sure if my change does fix the problem.

> If you really do want me to install the same thing a third time, do you
> first want me to back out the previous installation I reported  from
> #50?

No, it is different with before. Sorry, I don't know why you did install the
same images for two times.

Anyway, I'd appreciate it if you can do the install third time, but it
is optional,
of course.

Thanks,
--
Ming Lei

[Axis Mann (axismann)]

* * * W A R N I N G * * *

I ran a diff comparison with the packages at link

http://kernel.ubuntu.com/~ming/bugs/624510/lucid-40.87-release/

with those I previously tested from link

 http://kernel.ubuntu.com/~ming/bugs/624510/

 and found them to be different from the original packages I tested.

If I understand correctly, you've repacked the original changes for official release and want
me to retest to confirm that the problem is still resolved.

The packages located at link

http://kernel.ubuntu.com/~ming/bugs/624510/lucid-40.87-release/

were tested and failed to correct the original Slow USB Read. The read spead reverted
to 5 MB/s after those changes were installed and computer rebooted.

* * * W A R N I N G * * *

[Ming Lei (tom-leiming)]

Axis,

On Sun, Mar 18, 2012 at 4:35 PM, Axis Mann <email address hidden> wrote:
> The packages located at link
>
> http://kernel.ubuntu.com/~ming/bugs/624510/lucid-40.87-release/
>
> were tested and failed to correct the original Slow USB Read.  The read spead reverted
> to 5 MB/s after those changes were installed and computer rebooted.

Exactly, that is just what I expected, and now I am sure that it is
the below commit

      commit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream
      [PATCH] USB: EHCI: go back to using the system clock for QH unlinks

which fixes your performance problem.

Thanks again for your patient tests.

[Tim Gardner (timg-tpi)]

Applied to Lucid 'USB: EHCI: go back to using the system clock for QH unlinks'

[Axis Mann (axismann)]

I don't see the identified changes pushed onto the latest Lucid update. When will that happen?

[Ming Lei (tom-leiming)]

On Fri, Mar 23, 2012 at 3:20 PM, Axis Mann <email address hidden> wrote:
> I don't see the identified changes pushed onto the latest Lucid update.
> When will that happen?

Please update to Ubuntu-2.6.32-41.88 to fix your bug.

Thanks,

[Luis Henriques (henrix)]

This bug is awaiting verification that the kernel for Lucid in -proposed solves the problem (2.6.32-41.88). Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lucid' to 'verification-done-lucid'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Herton R. Krzesinski (herton)]

Axis, or anybody else affected by this bug, can you verify that the kernel 2.6.32-41.88 in -proposed fixes the performance issue?

[Ming Lei (tom-leiming)]

In fact, the patch was in -stable tree for long time, but missed in
lucid kernel.

The patch is to address usb 'disconnect/reset' issue as the blow[1], but it
still may fix Axis's performance issue because the patch removes coarse
SOF timestamp and avoid io timeout.

So suggest to always release the patch.

[1], https://lists.linux-foundation.org/pipermail/bugme-new/2011-April/026993.html

[Herton R. Krzesinski (herton)]

Yes the patch was marked as stable, but it for some reason didn't landed in 2.6.32 stable. Also the change is not simple or straightforward, may introduce regressions etc.

So, if no one tests 2.6.32-41.88 in -proposed, and confirm it fixes this bug soon, soon we likely will revert the change, and this bug will be set to Incomplete (there is still time for testing, it was 1 week but we got more time). We are only releasing the kernel to -updates with the patch if it has confirmed testing with the -proposed kernel.

[Tim Gardner (timg-tpi)]

I tested dd times for a large ISO:

sudo time dd if=ubuntu-10.04.4-dvd-amd64.iso of=/dev/sdb
2.6.32-40-server 18:57
2.6.32-41-server 18:42
2.6.32-40-generic 27.68
2.6.32-41-generic 20:24

Given the improvements, and no noticeable regression, and the fact that this patch has been in Oneiric for awhile, I'm marking this as verified.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.32-41.88

---------------
linux (2.6.32-41.88) lucid-proposed; urgency=low

  [Luis Henriques]

  * Release Tracking Bug
    - LP: #966443

  [ Andy Whitcroft ]

  * [Config] restore build-% shortcut

  [ Tim Gardner ]

  * SAUCE: ubuntu drivers: use UMH_WAIT_PROC consistently
    - LP: #963685

  [ Upstream Kernel Changes ]

  * Revert "Revert "USB: xhci - fix unsafe macro definitions""
    - LP: #948139
  * Revert "Revert "USB: xhci - fix math in xhci_get_endpoint_interval()""
    - LP: #948139
  * Revert "Revert "xhci: Fix full speed bInterval encoding.""
    - LP: #948139
  * bsg: fix sysfs link remove warning
    - LP: #946928
  * hwmon: (f75375s) Fix bit shifting in f75375_write16
    - LP: #948139
  * lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel
    - LP: #948139
  * relay: prevent integer overflow in relay_open()
    - LP: #948139
  * mac80211: timeout a single frame in the rx reorder buffer
    - LP: #948139
  * kernel.h: fix wrong usage of __ratelimit()
    - LP: #948139
  * printk_ratelimited(): fix uninitialized spinlock
    - LP: #948139
  * hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375
    - LP: #948139
  * crypto: sha512 - Use binary and instead of modulus
    - LP: #948139
  * crypto: sha512 - Avoid stack bloat on i386
    - LP: #948139
  * crypto: sha512 - use standard ror64()
    - LP: #948139
  * SCSI: 3w-9xxx fix bug in sgl loading
    - LP: #948139
  * ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR
    - LP: #948139
  * ARM: 7325/1: fix v7 boot with lockdep enabled
    - LP: #948139
  * USB: Added Kamstrup VID/PIDs to cp210x serial driver.
    - LP: #948139
  * USB: Fix handoff when BIOS disables host PCI device.
    - LP: #948139
  * xhci: Fix encoding for HS bulk/control NAK rate.
    - LP: #948139
  * hdpvr: fix race conditon during start of streaming
    - LP: #948139
  * cdrom: use copy_to_user() without the underscores
    - LP: #948139
  * autofs: work around unhappy compat problem on x86-64
    - LP: #948139
  * Fix autofs compile without CONFIG_COMPAT
    - LP: #948139
  * compat: fix compile breakage on s390
    - LP: #948139
  * PM: Print a warning if firmware is requested when tasks are frozen
    - LP: #948139
  * firmware loader: allow builtin firmware load even if usermodehelper is
    disabled
    - LP: #948139
  * PM / Sleep: Fix freezer failures due to racy
    usermodehelper_is_disabled()
    - LP: #948139
  * PM / Sleep: Fix read_unlock_usermodehelper() call.
    - LP: #948139
  * Linux 2.6.32.58
    - LP: #948139
  * regset: Prevent null pointer reference on readonly regsets
    - LP: #949905
    - CVE-2012-1097
  * regset: Return -EFAULT, not -EIO, on host-side memory fault
    - LP: #949905
    - CVE-2012-1097
  * KVM: Remove ability to assign a device without iommu support
    - LP: #897812
    - CVE-2011-4347
  * eCryptfs: Copy up lower inode attrs after setting lower xattr
  * eCryptfs: Improve statfs reporting
    - LP: #885744
  * drm/i915: no lvds quirk for AOpen MP45
    - LP: #955078
  * drm/radeon/kms: fix MSI re-arm on rv370+
    - LP: #955078
  * Linux 2.6.32.58+drm33.24
    - LP: #955078
  ...

[Axis Mann (axismann)]

I confirmed that the latest Ubuntu release for Lucid 10.04 (version 2.6.32-41-generic) fixed my hi-speed USB 2.0 problem. I'm now seeing both read from and write to my external usb drive using nautilus in excess of 30 MB/s. Also, the hdparm command is now showing hi speed read activity on the external drive

owner@Pluto:~$ sudo hdparm -Tt /dev/sdb1
[sudo] password for owner:

/dev/sdb1:
 Timing cached reads: 2776 MB in 2.00 seconds = 1388.33 MB/sec
 Timing buffered disk reads: 104 MB in 3.04 seconds = 34.21 MB/sec

I hope the USB traces and other information I supplied helped to resolve this problem. Thank you for your attention on this matter.

[Ming Lei (tom-leiming)]

On Wed, Apr 25, 2012 at 10:32 AM, Axis Mann <email address hidden> wrote:
> I hope the USB traces and other information I supplied helped to resolve

Of course, without the traces and other information you provided, we
can't figure out the solution. Thanks.

> this problem.  Thank you for your attention on this matter.

You are welcome.

Thanks,

[mesrouilles (mesrouilles)]

On a Fat 32 sdcad

[David Hume (dh08)]

Clicking on "Fix released" reveals nothing.
And there's still no solution in UbuntuMATE 15.04 and 16.04 5 years later.
Specifically 50% copies then there's a 1 to 2-minute delay before the rest copies from disk to usb stick.

[Thadah Denyse (juchuf)]

The issue has appeared on Ubuntu 16.04 with the 4.4.0-28-generic kernel. When doing

sudo hdparm -tT /dev/sde

/dev/sde:
 Timing cached reads: 8598 MB in 2.00 seconds = 4302.13 MB/sec
 Timing buffered disk reads: 56 MB in 3.11 seconds = 18.03 MB/sec

Everything seems fine, but when writing into the USB drive the writing speed falls down to 9.34KB/s

[David Hume (gladesbay)]

This bug has been consistent in all Ubuntu releases 14, 15, 16 and the relevant Mint releases upto and including 18. It never goes away and always it stops around half-way copied. It is soooooo annoying!!

[pleabargain (dennisgdaniels)]

same prob on LTS 16.04
kernel: 4.4.0-72-generic

[Rasitha (rasithapr)]

the bug is still there im using linux mint 18.3 64bit with kernel 4.10.0-38 generic