Am running XP Pro/SP2. I have a SATA HDD attached via USB. I made a
copy of about 20 GB of data from an internal HDD to the USB HDD.

I wanted a second copy of the data and I wanted that second copy to be
stored on my USB HDD. IYSWIM. So I used XP to make a copy:

source = the USB HDD
target = the USB HDD.

I thought it would be quick but it looked like it was going to take
longer than it had taken to get the data from the internal HDD. (The
copy operation crashed because of a very long file name.)

It made made me think that the copy was not being doing inside the USB
HDD. Seemed the data was being sent from the ext HDD to the USB port
and into the PC and then it was coming back out to the same drive. Is
this correct?
----------

Am running XP Pro/SP2. I have a SATA HDD attached via USB. I made a
copy of about 20 GB of data from the PC's internal HDD to the USB HDD.

I also wanted a second copy of the data and I wanted that second copy
to be stored on the USB HDD. So I used XP to make a copy:

source = the USB HDD
target = the USB HDD.

I thought it would be quick but was really slow. Looked like it was
going to take longer than the first copy from the internal HDD, so I
terminated it.

I thought the copy would be done inside the USB HDD. But it seemed the
data was being sent from the USB HDD to the USB port and into the PC
and then back out to the same drive. Is this correct?

Paul wrote:

> Am running XP Pro/SP2. I have a SATA HDD attached via USB. I made
> a copy of about 20 GB of data from an internal HDD to the USB HDD.

> I wanted a second copy of the data and I wanted that second copy to
> be stored on my USB HDD. IYSWIM. So I used XP to make a copy:

> source = the USB HDD
> target = the USB HDD.

> I thought it would be quick but it looked like it was going to take
> longer than it had taken to get the data from the internal HDD.

Thats because the source is slower with a USB source than with an internal hard drive source.

> (The copy operation crashed because of a very long file name.)

> It made made me think that the copy was not being doing inside the USB HDD.

Correct. It doesnt do that with any type of hard drive.

> Seemed the data was being sent from the ext HDD to the USB port
> and into the PC and then it was coming back out to the same drive.
> Is this correct?

Yes.

And that happens even with a copy made on an internal hard drive too.

Paul wrote:
> It made made me think that the copy was not being doing inside the USB
> HDD. Seemed the data was being sent from the ext HDD to the USB port
> and into the PC and then it was coming back out to the same drive. Is
> this correct?


Yup, file copying is a very high-level operation, done at the OS level
rather than the hardware level. At the hardware level, data on a disk is
organized into sectors (usually fixed at 512 bytes in size). It's the
OS, that further organizes the sectors into files on a file system. You
need the OS to tell the hardware where the file's sectors are.

Yousuf Khan

On Jul 20, 4:13*am, Yousuf Khan <bbb...@yahoo.com> wrote:
> Paul wrote:
> > It made made me think that the copy was not being doing inside the USB
> > HDD. Seemed the data was being sent from the ext HDD to the USB port
> > and into the PC and then it was coming back out to the same drive. *Is
> > this correct?
>
> Yup, file copying is a very high-level operation, done at the OS level
> rather than the hardware level. At the hardware level, data on a disk is
> organized into sectors (usually fixed at 512 bytes in size). It's the
> OS, that further organizes the sectors into files on a file system. You
> need the OS to tell the hardware where the file's sectors are.
>
> * * * * Yousuf Khan

Trying to copy a large file to another location on the same drive is
always slow. This is beacuse there is a lot of head movement
required.

To try and explain this, if the first file is at location 100, and the
copy will be in location 1000, the heads have to read 100, write to
1000, read 101, write to 1001 etc. The heads are moving back and
forth all the time. Large buffers will help, but on 20GB, there will
still be many head movments

When copying from different drives, the heads have to move 100, 101,
102 for reading,and 1000, 1001, 1002 when writing. Assuminmg no
fragmentation, it is nice simple sequential reading and writing. (Ok
there is file system managment as well, but this is optimised).

A second point, on any external USB drive, they can normally be set
for quick removal, or performance mode. Quick removal is slower.
Quck removal mode for FAT32 can be very slow.

Michael
www.cnwrecovery.com

In comp.sys.ibm.pc.hardware.storage Paul <(E-Mail Removed)> wrote:
> Am running XP Pro/SP2. I have a SATA HDD attached via USB. I made a
> copy of about 20 GB of data from an internal HDD to the USB HDD.

> I wanted a second copy of the data and I wanted that second copy to be
> stored on my USB HDD. IYSWIM. So I used XP to make a copy:

> source = the USB HDD
> target = the USB HDD.

> I thought it would be quick but it looked like it was going to take
> longer than it had taken to get the data from the internal HDD. (The
> copy operation crashed because of a very long file name.)

> It made made me think that the copy was not being doing inside the USB
> HDD. Seemed the data was being sent from the ext HDD to the USB port
> and into the PC and then it was coming back out to the same drive. Is
> this correct?
> ----------

What made you think a HDD can copy files in the first place?
It does not even understand what a file or filesystem is!
It addition it cannot copy anything, it can read sectors
and deliver them to the host or it can write sectors the
host has deliverd to it. That is basically it.

> Am running XP Pro/SP2. I have a SATA HDD attached via USB. I made a
> copy of about 20 GB of data from the PC's internal HDD to the USB HDD.

> I also wanted a second copy of the data and I wanted that second copy
> to be stored on the USB HDD. So I used XP to make a copy:

> source = the USB HDD
> target = the USB HDD.

> I thought it would be quick but was really slow. Looked like it was
> going to take longer than the first copy from the internal HDD, so I
> terminated it.

> I thought the copy would be done inside the USB HDD. But it seemed the
> data was being sent from the USB HDD to the USB port and into the PC
> and then back out to the same drive. Is this correct?

Yes.

Arno

In comp.sys.ibm.pc.hardware.storage Ato_Zee <(E-Mail Removed)> wrote:

> On 20-Jul-2009, Arno <(E-Mail Removed)> wrote:

>> > I thought the copy would be done inside the USB HDD. But it seemed the
>> > data was being sent from the USB HDD to the USB port and into the PC
>> > and then back out to the same drive. Is this correct?
>>
>> Yes.

> Which is why it is slower, data is going to and from the USB drive via
> the USB interface, and each direction is contending for USB bandwidth.
> It is may be using the swap file, so increasing the swap file size
> is worth a try, but if using DMA .the swap file may not be involved.

Swap usage is rather unlikely, due to the short turn-around time.
Also any sane copying program will not read data file by file,
but with a fixed (and possibly locked in memory) buffer.

Arno

On or about Mon, 20 Jul 2009 00:15:59 +0100 did Paul <(E-Mail Removed)>
dribble thusly:

>It made made me think that the copy was not being doing inside the USB
>HDD. Seemed the data was being sent from the ext HDD to the USB port
>and into the PC and then it was coming back out to the same drive. Is
>this correct?

Others have pointed out that as far as the device is concerned, it's reading
and writing arbitrary blocks of data, and knows nothing about files. For the
OS to copy a file, it has to retrieve data from the device over the USB link,
then write that data back to the device over the same link.

Quite apart from this obvious fact (obvious to those with a less black-box
understanding of computers), the copy would be slow even with the fastest
internal link for the hard drive, on account of the head movement. When you
copy from one drive to the other, it's like you're tossing a ball between two
people as they walk along separate lines. When you copy from a drive to
itself, it's like there's only one person who's running back and forth between
the lines as he moves laterally along then them, carrying the ball.

The upshot for your case is that you would get much better results copying
from the source drive to the USB drive twice if you want two copies on the USB
drive.

On 07:57 21 Jul 2009, Mike Ruskai wrote:

> On or about Mon, 20 Jul 2009 00:15:59 +0100 did Paul
> <(E-Mail Removed)> dribble thusly:
>
>>It made made me think that the copy was not being doing inside the
>>USB HDD. Seemed the data was being sent from the ext HDD to the USB
>>port and into the PC and then it was coming back out to the same
>>drive. Is this correct?
>
> Others have pointed out that as far as the device is concerned, it's
> reading and writing arbitrary blocks of data, and knows nothing
> about files. For the OS to copy a file, it has to retrieve data
> from the device over the USB link, then write that data back to the
> device over the same link.
>
> Quite apart from this obvious fact (obvious to those with a less
> black-box understanding of computers), the copy would be slow even
> with the fastest internal link for the hard drive, on account of the
> head movement. When you copy from one drive to the other, it's like
> you're tossing a ball between two people as they walk along separate
> lines. When you copy from a drive to itself, it's like there's only
> one person who's running back and forth between the lines as he
> moves laterally along then them, carrying the ball.
>
> The upshot for your case is that you would get much better results
> copying from the source drive to the USB drive twice if you want two
> copies on the USB drive.
>

Which of these two likely to be the limiting factor:

head movement
-or-
rate of data transfer from HDD to USB to PC back via USB to HDD.


ISTR a USB port maxes out at about 30 MB/s in practise. That means 15
Mbps going both ways. And probably less because of contention.

I have no idea what max data rate is for a disk head moving back and
forth in the way a file copy gets done.

In comp.sys.ibm.pc.hardware.storage Paul <(E-Mail Removed)> wrote:
> On 07:57 21 Jul 2009, Mike Ruskai wrote:

>> On or about Mon, 20 Jul 2009 00:15:59 +0100 did Paul
>> <(E-Mail Removed)> dribble thusly:
>>
>>>It made made me think that the copy was not being doing inside the
>>>USB HDD. Seemed the data was being sent from the ext HDD to the USB
>>>port and into the PC and then it was coming back out to the same
>>>drive. Is this correct?
>>
>> Others have pointed out that as far as the device is concerned, it's
>> reading and writing arbitrary blocks of data, and knows nothing
>> about files. For the OS to copy a file, it has to retrieve data
>> from the device over the USB link, then write that data back to the
>> device over the same link.
>>
>> Quite apart from this obvious fact (obvious to those with a less
>> black-box understanding of computers), the copy would be slow even
>> with the fastest internal link for the hard drive, on account of the
>> head movement. When you copy from one drive to the other, it's like
>> you're tossing a ball between two people as they walk along separate
>> lines. When you copy from a drive to itself, it's like there's only
>> one person who's running back and forth between the lines as he
>> moves laterally along then them, carrying the ball.
>>
>> The upshot for your case is that you would get much better results
>> copying from the source drive to the USB drive twice if you want two
>> copies on the USB drive.
>>

> Which of these two likely to be the limiting factor:

> head movement
> -or-
> rate of data transfer from HDD to USB to PC back via USB to HDD.


> ISTR a USB port maxes out at about 30 MB/s in practise. That means 15
> Mbps going both ways. And probably less because of contention.

Indeed.

> I have no idea what max data rate is for a disk head moving back and
> forth in the way a file copy gets done.

Well, for large files with little fragmentation, the 30MB/s speed
will be the mimiting factor. For very small files it will be seek
time.

Some current values for modern 3.5" disks, just to give you an idea.
These are very, very rough approximations:

Linear data transfer rate: 100MB/s (may drop towards end of disk)

Seek time: 5-10ms, depending on distance

Latency: 4.1ms average

You need to add seek time and latency for sector access in
most non-linear cases.

A file copy will do several seeks. Call it 5-10 seeks in addition
to accessing the data.

Arno

On or about Wed, 22 Jul 2009 23:40:00 +0100 did Paul <(E-Mail Removed)>
dribble thusly:

>On 07:57 21 Jul 2009, Mike Ruskai wrote:
>
>> On or about Mon, 20 Jul 2009 00:15:59 +0100 did Paul
>> <(E-Mail Removed)> dribble thusly:
>>
>> Quite apart from this obvious fact (obvious to those with a less
>> black-box understanding of computers), the copy would be slow even
>> with the fastest internal link for the hard drive, on account of the
>> head movement. When you copy from one drive to the other, it's like
>
>Which of these two likely to be the limiting factor:
>
>head movement
>-or-
>rate of data transfer from HDD to USB to PC back via USB to HDD.
>
>
>ISTR a USB port maxes out at about 30 MB/s in practise. That means 15
>Mbps going both ways. And probably less because of contention.
>
>I have no idea what max data rate is for a disk head moving back and
>forth in the way a file copy gets done.

That's a good question.

I just did a couple quick tests on an idle SATA hard drive and two USB drives.

The first part of the test consisted of measuring the base write speed by
creating a 256MB junk file from memory on each drive. That was about 78MB/sec
for the SATA drive, 23MB/sec for one USB drive, and 21MB/sec for the other.

The second part was finding some large files on each drive to copy back to
itself. The results for the SATA drive showed about 40MB/sec, which is pretty
close to exactly half the nominal write speed. For each USB drive, the
results were very nearly exactly half.

The slowest USB drive of the two is an enclosed SATA drive with a native max
transfer rate of more than 100MB/sec.

So thrashing the head drops performance by about 50%, while sticking the drive
in an enclosure drops it by more than 80% in my case, or at best more than 70%
(given the highest USB 2.0 speeds I've ever seen, which were around 30MB/sec).

It's a pity Firewire never really took off. The 400Mbps version gets about
65% of its rated speed in my experience, which implies that the 800Mbps
version would about triple the performance I'm currently getting with USB 2.0.