Question about transfer speeds between HDs, and DMA mode

"Michael Brown" wrote in message
...
Folkert Rienstra wrote:

So it will have to read to ram, then write back out to the same
channel.

So what. An IDE channel can support two drives.

Yes, but not at the same time. Only one request can be active at any point
in time. So your drives will run at exactly half of their potential speed if
you only use one channel. This is the reason why doing any sort of IDE RAID
pretty much requires that you have one device per channel, otherwise you
take a big performance hit.

It doesn't matter if you are doing sequential copies. IDE drives implement
read ahead and write behind, so the host is transfering to/from the cache and
both drives read and write at the same time. Similar argument for ROM to
writer on the same channel. The speed of the channel is enough for two
devices.

Using 2 channels (cables), both will happen at the same time.

Nope.

You're wrong, again. You should actually understand the topic before you
answer with such confidence

You are the one who doesn't understand. You can easily do CD duplication with
both drives on one UDMA-33 channel. This was what the prior poster asked.

"Michael Brown" wrote in message
...
Folkert Rienstra wrote:
"Wes Newell" wrote in message
newsan.2004.07.20.21.10.40.749665@TAKEOUTverizon .net
On Tue, 20 Jul 2004 15:33:29 -0400, ZigZag Master wrote:

I have a Maxtor 200GB (6Y200P0) and a Western Digital 250GB
WD2500JB in a AMD 2500 / Abit NF7-S - 1GB RAM. I am running
Windows XP Pro.

I was wondering how long it should take to copy large files between
the drives.

I have some TV captures that are about 8-12GB. It just seems like
it takes a long time to copy from drive to drive....about 6-8
minutes. Is this normal?

Also, do I have to do anything special to turn on DMA mode? I
think I was using Pinnacle Studio, and it popped up a window saying
DMA mode was not enabled on the Maxtor.

For best performance, make sure the 2 drives are not on the same
channel (cable). If they are on the same channel, this will be a
major
slowdown,

Nope.

Wrong. His drives will only be running at half their potential if they're
both on the same channel.

You are wrong.

as each channel can only perform 1 IO fubction at a time.

Like this would be any different for SCSI or any other bus.

Actually, it is. An ATA bus (current SATA implementations or parallel) can
only have one active request at a time.

So, drives do read ahead and write behind caching...hmm, I wonder why?

A SCSI bus can have requests
outstanding, so there is very little wastage of bus bandwidth (though more
complex electronics are needed).

So it will have to read to ram, then write back out to the same
channel.

So what. An IDE channel can support two drives.

Yes, but not at the same time.

Wrong.

Only one request can be active at any point
in time.

Just like SCSI. Define "active".

So your drives will run at exactly half of their potential speed if

Wrong.

Defrag both drives, pick a huge file, restart the os, and copy the file
between the drives while timing it, then delete the copy. Do this a few
times. Then put one drive on the other channel and do it again. You'll then
know if it makes a difference on your machine.

I suspect that since (most?) drives can't read or write at anywhere near the
rate of the modern 133 interface, it doesn't matter at all.

But I would love to read your results.

I have 2 drives on the same channel that max out at 40 mb/s and down to 25
mb/s on the insides of the platters. They can copy a large file between them
at 30 mb/s.


--
Ed Light

Smiley :-/
MS Smiley :-\

Send spam to the FTC at

Thanks, robots.

"Ed Light" wrote

I have 2 drives on the same channel that max out at 40 mb/s and down to 25
mb/s on the insides of the platters. They can copy a large file between
them
at 30 mb/s.

That's in Win XP Home.

--
Ed Light

Smiley :-/
MS Smiley :-\

Send spam to the FTC at

Thanks, robots.

"Ed Light" wrote in message
news:7VALc.43469$ve2.12065@okepread05...
I have 2 drives on the same channel that max out at 40 mb/s and down to 25
mb/s on the insides of the platters. They can copy a large file between
them
at 30 mb/s.

That's a typical result for two HDs on the same cable doing big file
sequential I/O. There is no interference.

However if both drives were doing intense small record random I/O then there
would be significant interference.

Yes this is my experience also. I did similar real life experiments
too.

Although I would attribute the no cable difference result to waiting
on disk access time to intermix read and writes. I think what happens
is that you (1) quickly purge the buffer on one drive, (2) wait for
another disk revolution, (3) then purge the buffer again. This
sequence intermixed between two drives.

I used winXp as Ed did. Results may be way different for other
operating systems...

Forrest

Motherboard Help By HAL web site:
http://home.comcast.net/~hal-9000/


On Wed, 21 Jul 2004 14:06:11 -0700, "Ed Light"
wrote:

Defrag both drives, pick a huge file, restart the os, and copy the file
between the drives while timing it, then delete the copy. Do this a few
times. Then put one drive on the other channel and do it again. You'll then
know if it makes a difference on your machine.

I suspect that since (most?) drives can't read or write at anywhere near the
rate of the modern 133 interface, it doesn't matter at all.

But I would love to read your results.

I have 2 drives on the same channel that max out at 40 mb/s and down to 25
mb/s on the insides of the platters. They can copy a large file between them
at 30 mb/s.

Eric Gisin wrote:
"Michael Brown" wrote in message
...
Folkert Rienstra wrote:

So it will have to read to ram, then write back out to the same
channel.

So what. An IDE channel can support two drives.

Yes, but not at the same time. Only one request can be active at any
point in time. So your drives will run at exactly half of their
potential speed if you only use one channel. This is the reason why
doing any sort of IDE RAID pretty much requires that you have one
device per channel, otherwise you take a big performance hit.

It doesn't matter if you are doing sequential copies. IDE drives
implement read ahead and write behind, so the host is transfering
to/from the cache and both drives read and write at the same time.
Similar argument for ROM to writer on the same channel. The speed of
the channel is enough for two devices.

The cache and write buffers have (almost) no effect on the situation we're
talking about he multi-gigabyte file moves between hard disks. The write
buffer on the drive will be 100% full all the time, and the read cache will
never have a chance to get ahead of the interface (as the interface is 2-3
times faster than the off-the-platter speed of the drive). The write request
will be sent to the drive, but the interface will stall until there is a
free block in the (write) cache. Likewise for reading. The request will come
in for a number of sectors. From the start of this request to the time when
the drive has finished sending the data, the interface is in use.

A timeline might help. The following assumptions are made:
1) Zero seek time
2) 50mbytes/sec sustained reading and writing (HDD manufacturer mbytes,
1mbyte = 1000000 bytes)
3) Sufficient data hasa been transferred already to fill up the write buffer
on the destination drive (~12mb or so)
4) The drive can transmit as it's read off the platters (ie: doesn't cache
then send)
5) Requests don't take any time to send.
6) Interface is ATA133

If 1, 3, 4 or 5 don't hold, it makes the analysis somewhat more complex, and
decreases the throughput on the bus. So I'm assuming best-case conditions
here. Times are in ms to 3sf.

One channel:
t = 0.000: 64kb (treating kb = 1024 bytes here) read request to drive 1. Bus
becomes allocated to drive 1.
t = 0.010: Drive 1 finishes reading sector 1 off the platters, and has sent
it.
t = 0.020: Drive 1 finishes reading sector 2 off the platters, and has sent
it.
t = 1.311: Drive 1 finishes reading sector 128 off the platters, and has
sent it. The bus is now free.
t = 1.311: 64kb write request to drive 2. Bus becomes allocated to drive 2.
Read request queued in HDD driver for drive 1.
t = 1.315: Drive 2 finishes receiving sector 1 from the interface. Begins
writing to platters. Begins reading sector 2 from interface.
t = 1.325: Drive 2 finishes writing sector 1 to platters.
t = 2.625: Drive 2 finishes writing sector 128 to the platters. The bus is
now free.
So, it has taken 2.625ms to transfer 64kb, giving drive-to-drive copy speed
of very slightly under 25 mbytes/sec. Actually, it's not usually quite this
bad, since some of the time the firmware is successful in reading ahead in
the right way. I was curious about this about a year ago, and wrote a small
assembler/FreePascal program to do the tests (bootdisk somewhat like
memtest86). In a benchmark between two Seagate 80gb drives (2mb cache) I
measured it to copy about 35 mbytes/sec. Two-channel copying was measured at
~50 mbytes sec (this was all done at the start of the drive IIRC). It's
quite possible that Seagate's firmware is just hopeless at reading ahead,
but since I'm not rich enough to have a whole lot of unused hard disks
floating around, I never got around to testing any others. You can probably
do much the same thing in linux doing a dd from /dev/hda to /dev/hdb or
similar (I always choose the hard way to do things ). I can probably whip
up a quick linux bootdisk (or try to find my original program) if you want
to test it yourself.

Two channels:
t = 0.000: 64kb (treating kb = 1024 bytes here) read request to drive 1 on
bus 1. Bus 1 becomes allocated to drive 1.
t = 0.010: Drive 1 finishes reading sector 1 off the platters, and has sent
it.
t = 0.020: Drive 1 finishes reading sector 2 off the platters, and has sent
it.
t = 1.311: Drive 1 finishes reading sector 128 off the platters, and has
sent it. Bus 1 is now free.
t = 1.311: 64kb write request to drive 2 on second channel. Bus 2 becomes
allocated to drive 2.
t = 1.311: 64kb read request to drive 1 on bus 1. Bus 1 becomes allocated to
drive 1.
t = 1.315: Drive 2 finishes receiving sector 1 from the interface. Begins
writing to platters. Begins reading sector 2 from interface.
t = 1.321: Drive 1 finishes reading sector 129 off the platters, and has
sent it.
t = 1.325: Drive 2 finishes writing sector 1 to platters.
t = 2.621: Drive 1 finishes reading sector 256 off the platters, and has
sent it. Bus 1 is now free.
t = 2.625: Drive 2 finishes writing sector 128 to the platters. Bus 2 is now
free.

So, now it's only taking 1.315ms to transfer 64kb, giving a drive-to-drive
copy speed of just under 50 mbytes/sec.

In SCSI, however, data is separated from request packets (as I understand
it, I haven't looked into it as much as ATA, mainly for financial reasons
). Without going into a whole lot of timing detail, the transfer looks
more like:
Send read to drive 1. Bus is freed immediately after transfer. The drive
begins reading data into an internal buffer.
Drive 1 sends a read acknowledge back to the controller, along with the data
(at full bus speed, from the buffer).
Send read to drive 1. Bus is freed immediately after transfer. The drive
begins reading data into an internal buffer.
Send write to drive 2, along with data. Data is buffered into internal
buffer, and the bus is freed immediately after the transfer of the request.
The drive begins writing data onto the platters.
Drive 1 sends a read acknowledge back to the controller, along with the data
(at full bus speed, from the buffer).
Drive 2 sends a write acknowledge back to the controller.
etc etc

With a bit of sensible programming, the writes are buffered on the CPU side
until the drive reports that the request has been completed. Only then is
the next write request sent out, which is transferred at full bus speed into
the write buffer of the hard disk. In other words, all transfers are done at
full bus speed, with no stalling, and the bus is freed immediately after the
request has been sent (unlike ATA). This is the main advantage of SCSI, and
the reason why you can hang a stupid number of devices off a single channel
without having any performance issues.

Finally, I'm not sure exactly how the various command queuing techniques
that are hopefully going to become part of SATA work. I hope that they
operate along similar lines to what I described for the SCSI, as this would
get rid of one of the disadvantages of ATA.

The whole analysis changes, of course, when you add in significant seek
times. The buffers play a much larger role in saving performance (otherwise
the bus is stalled for ~10ms, OUCH!) here. But this wasn't what the OP was
asking about, so wasn't what I was answering about either.

Using 2 channels (cables), both will happen at the same time.

Nope.

You're wrong, again. You should actually understand the topic before
you answer with such confidence

You are the one who doesn't understand. You can easily do CD
duplication with both drives on one UDMA-33 channel. This was what
the prior poster asked.

Actually, the prior poster was asking about copying multi-gigabyte files
between hard disks. CD writers top out at about 9 mbytes/sec, so even mode 4
PIO is nearly fast enough for CD duplication.

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open

Michael Brown wrote:
[...]

Sorry about this post. I missed the x-post to the
comp.sys.ibm.pc.hardware.storage (I "live" in a.c.h.o), and seeing the
unfamiliar name and the non-backed-up responses, I posted with rather more
of snippy attitude than should have. However, I still believe my responses
are still mostly correct (except the one about operating at exactly half
speed, dunno why I said that ...): see my response to Eric Gisin.

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open

A few corrections on reading through it again ...

Michael Brown wrote:
Eric Gisin wrote:
"Michael Brown" wrote in message
...
Folkert Rienstra wrote:

So it will have to read to ram, then write back out to the same
channel.

So what. An IDE channel can support two drives.

Yes, but not at the same time. Only one request can be active at any
point in time. So your drives will run at exactly half of their
potential speed if you only use one channel. This is the reason why
doing any sort of IDE RAID pretty much requires that you have one
device per channel, otherwise you take a big performance hit.

It doesn't matter if you are doing sequential copies. IDE drives
implement read ahead and write behind, so the host is transfering
to/from the cache and both drives read and write at the same time.
Similar argument for ROM to writer on the same channel. The speed of
the channel is enough for two devices.

The cache and write buffers have (almost) no effect on the situation
we're talking about he multi-gigabyte file moves between hard
disks. The write buffer on the drive will be 100% full all the time,

I should have probably mentioned that this was assuming that the hard drive
was typical, not ideal (as below). "Typical" hard drives have slightly lower
write speeds than read speeds, so the write buffer generally gets to 100%
full during "streaming" disk writes. There's a whole great big mess at the
start with buffering and read-ahead on a single-channel setup, but that
usually gets sorted out after a few hundred meg.

and the read cache will never have a chance to get ahead of the
interface (as the interface is 2-3 times faster than the
off-the-platter speed of the drive).

Again, I was talking about typical drives, not theoretical drives. A
theoretical drive would be able to get 2mb (or whatever the buffer size is)
ahead of the actual read point by reading in the data while the write drive
is stalling (either due to being on the same channel or because writing is
marginally slower than reading). However, my tests seem to indicate that
this does not happen, or at least it does not happen as well as it should
(eg: the drive might not automatically seek ahead to the next track,
creating a bursty dataflow).

[...]

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open

"Michael Brown" wrote in message
Folkert Rienstra wrote:
"Wes Newell" wrote in message newsan.2004.07.20.21.10.40.749665@TAKEOUTverizon .net
On Tue, 20 Jul 2004 15:33:29 -0400, ZigZag Master wrote:

I have a Maxtor 200GB (6Y200P0) and a Western Digital 250GB
WD2500JB in a AMD 2500 / Abit NF7-S - 1GB RAM. I am running
Windows XP Pro.

I was wondering how long it should take to copy large files between
the drives.

I have some TV captures that are about 8-12GB. It just seems like
it takes a long time to copy from drive to drive....about 6-8
minutes. Is this normal?

Also, do I have to do anything special to turn on DMA mode? I
think I was using Pinnacle Studio, and it popped up a window saying
DMA mode was not enabled on the Maxtor.

For best performance, make sure the 2 drives are not on the same
channel (cable). If they are on the same channel, this will be a
major
slowdown,

Nope.

Wrong. His drives will only be running at half their potential if they're
both on the same channel.

as each channel can only perform 1 IO fubction at a time.

Like this would be any different for SCSI or any other bus.

Actually, it is. An ATA bus (current SATA implementations or parallel) can
only have one active request at a time. A SCSI bus can have requests
outstanding, so there is very little wastage of bus bandwidth (though more
complex electronics are needed).

So it will have to read to ram, then write back out to the same
channel.

So what. An IDE channel can support two drives.

Yes, but not at the same time. Only one request can be active at any point
in time. So your drives will run at exactly half of their potential speed if
you only use one channel. This is the reason why doing any sort of IDE RAID
pretty much requires that you have one device per channel, otherwise you
take a big performance hit.

Using 2 channels (cables), both will happen at the same time.

Nope.

You're wrong, again.

You should actually understand the topic before you
answer with such confidence

LOL, what can I say, one has it or one doesn't.

Guess again in what camp you are.


[...]