Comment 166 for bug 197762

This is completely not flamebait, promise, I have been doing nothing but
bragging on the latest build of Ubuntu, but I loaded Windows 7 back on this
same exact machine, only difference was the OS, and suddenly I get transfer
speeds of 25Mb/s or higher consistently even on extremely large transfers.
On Ubuntu 9.04 it would never get above 15Mb/s and would quickly drop to
nearly half of that and eventually stop altogether if the transfer was a
very large one that had to be sustained. My point is, for all the nay
sayers who say it's people's hardware....it's not, unless it's that Ubuntu
is not playing nice with certain hardware configurations. This is obviously
the case, but it is not a hardware issue at all when a simple change of the
OS completely fixes the issue.

On Tue, Jul 14, 2009 at 6:58 PM, epv <email address hidden> wrote:

> > (cp bigfile /media/disk/ &) ; sleep 10 ; time echo foo >
> /media/disk/bar
>
> > If the time is really in seconds as you seem to suggest it is
> > interesting I'd say. On the other hand, if what you describe is due the
> > low performance of the underlying device then it is expected behaviour
> > (the low performance of the device might be due to a bug though).
>
> # (cp /dev/zero /media/disk/bigfile &); sleep 10; time echo foo >
> /media/disk/bar
>
> real 0m5.647s
> user 0m0.000s
> sys 0m0.004s
>
> # time echo foo > /media/disk/foo2
>
> real 0m3.534s
> user 0m0.000s
> sys 0m0.000s
> # time echo foo > /media/disk/foo3
>
> real 0m4.589s
> user 0m0.000s
> sys 0m0.000s
> # time echo foo > /media/disk/foo3
>
> real 0m16.913s
> user 0m0.000s
> sys 0m0.000s
>
> Imagine that! I wasn't lying.
>
>
> >> The reports of "Fast at
> >> first, then slowing down" are of course because of the buffer cache
> >> making it look like it's initially "fast" but access to the underlying
> >> device is always very slow, whether you are writing to it with gvfs, cp,
> >> dd, buffer, or whatever.
> >
> >Yes, and?
>
> "and" so the arguments of "it's fast at first, then gets slow" from naive
> users are
> spurious, which I'm sure you realized.
>
> >> In addition, it's only writes that are slow, and they're vastly slower
> >> than could be explained by a crappy USB device- in my case around 100 -
> >> 200 kbytes/sec on a device that under a Hardy install writes at several
> >> mbytes/sec.
> >
> > If Hardy was fine then you should open a new bug report with the proper
> > details (once again, see [1] or Theodore's comments).
>
> There has been a lot of unhelpful or misguided information posted to this
> bug,
> but be careful not to discount the good with the bad. It's fairly clear you
> either
> don't believe there's a problem or aren't interested in it, which is fine,
> but it
> might be both more helpful and more civil to just say so, rather than being
> rude
> to people who are trying to help with whatever means they have available.
>
> eric
>
>
> ** Attachment added: "iostat output during "cp /dev/zero
> /media/disk/bigfile"
> http://launchpadlibrarian.net/29027766/iostat-output
>
> --
> file transfers on USB disk are very slow
> https://bugs.launchpad.net/bugs/197762
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in gvfs: Invalid
> Status in “gvfs” package in Ubuntu: Invalid
> Status in “linux” package in Ubuntu: Confirmed
>
> Bug description:
> When transferring large files (800meg) or even medium-size files (200meg),
> the transfer rate decreases constantly. It starts at around 4meg/sec and
> goes down to even less than 800kb/s. When I cancel the download and start it
> over again, the transfer rate comes back up to 4meg/sec.
> I am using Nautilus on Ubuntu 8.04 (hardy heron)
>