Download Speed with Kubuntu Karmic 64bit

[Reinhold Rumberger]

On Friday 29 January 2010, Steven Vollom wrote:
> On Thursday 28 January 2010 09:52:57 pm Billie Erin Walsh wrote:

<huge snippage>

> > Upload/download speeds are more dependent on the internet paths,
> > server speeds on the other end, and server loads on the other
> > end.
> 
> Dear Billy,
> 
> I don't think I posted 'download or upload' speeds.

Ever read the e-mail's subject? With a subject like that, confusion 
is pre-programmed.

> I am talking
> about transferring data from one drive to another, or one
> partition to another on the same drive.  I am trying to learn why
> transfer speeds vary so much when making data transfers
> internally.

(I haven't read the whole thread and am hoping that this isn't too 
redundant.)
OK, here are the basics:
During a copy, the available RAM will be used as a buffer. While 
there is free RAM, the copy operation will seem to progress at the 
speed the source drive can be read from.
There is also a difference depending on whether the source drive and 
the target drive use the same BUS or not - if they aren't, the 
operation will be a lot faster.
Then there's the matter of how much free space there is on the drives 
- writing to a pretty full drive can be very slow...

If you're using KDE (and I'm assuming you do, seeing as you're 
posting to this list... ;-) ), there will be a huge difference 
between copying large and small files. Since KDE starts a new copy 
operation for every file and does a lot of "useless" work in between 
operations (for progress information), copying a large amount of 
small files will take much longer using the KDE copy than using the 
cp command.
Obviously, copying a large amount of small files will always be 
slower than copying a large file of the same size as all the small 
ones put together. This is due to having to write meta-information on 
every file, which is quite time-consuming. This can be improved by 
using a file system that is optimised for handling small files 
(ReiserFS is one of those, IIRC).

> My thoughts are that perhaps the drives are slowing
> down and have to be spun again to get them up to speed, but that
> did not make sense when speeds spiked and went to, let's say,
> 180mbps for just a moment.  You would think the speed would
> remain at the higher speed for a second or two.  In fact there
> are times when the higher speed remains for a few seconds.  When
> that happens, a 1.5gb transfer takes only about 10 seconds. When
> it first happened it was very exciting, even though it does not
> happen very often, but many times it will remain stable at about
> 120 to 130mbps for a complete transfer, which is still very fast.

This is partially due to the buffering mentioned above. Also, 
obviously, the target drive's write speed is a limiting factor.

>  Still at other times, I have seen it go to 40mbps for a brief
> moment, then return to 60mbps to complete the transfer, but those
> slower speeds are not common at all.  100+ is common.

This suggests that a read or write operation is taking place on one 
of the drives, temporarily slowing down the transfer.

<snip> 

> I have read that ext4 is not stable;

That is incorrect. It isn't tested as thoroughly as its predecessors, 
but it most certainly is stable (there was some patch in the Ubuntu 
9.04 kernel which rendered deleting unstable, but that was an 
exception).

> sometimes I have unexpected
> problems with my computer.  I have wondered from time to time if
> those unexplainable problems could have to do with data transfer
> speeds created by ext4 file systems.

Ext4 may perform somewhat less than optimal at times due to a lack of 
optimisation, but apart from that: nope, problems would most likely 
cause the operation to fail rather than to slow down. Hardware 
problems on the other hand... ;-)

> I really don't know how to
> find that out either.  Most people seem to warn against the ext4
> file system, but they don't use it, so I don't understand how
> they would know.

There is a lot of theory behind the inner workings of a computer, and 
you don't always need to use something to be able to apprehend 
problems.
Also, not using something because it's not well-tested is a *very* 
valid reason and the one I've come across most often.

  --Reinhold