Question about transfer speeds between HDs, and DMA mode

"Ron Reaugh" wrote in message
"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.

On dual reads.
Not with one read and the other write or with dual writes.

Folkert Rienstra wrote:
[...]
LOL, what can I say, one has it or one doesn't.

Guess again in what camp you are.

If you're referring to tact, I'd say I very definately fall into the latter
Although I don't think my tone was right, I still stand by (most of) my
original comments (see my longer reply to Eric Gisin). They're based on both
reading of the specs and a substantial amount of testing (though admittedly
a lot of it not directly related to large-file copying[*]). If you or Ron
have something to contribute other than single-word responses or personal
attacks (though I regretfully admit I fired the first shot for this one)
then I'd be interested to hear them. Otherwise, I don't see much point in
continuing this thread.


[*] At one point in time, I was doing the planning for an MP3 player (as
many people have) and completed about half the IDE interface before I lost
interest due to cost reasons (I picked an overly powerful DSP that required
a rather expensive PCB layout). I did a substantial amount of testing with
low-level ATA stuff, since I was hoping to run both a (normal, desktop)
CDRom drive and a (laptop) hard drive off a single channel. The idea was to
buffer the file from the CDRom into the more shock-resistant hard disk, and
play it from there. The issue I ran into was that due to the continuous
needs of the DSP, and the effectively zero buffer on the microcontroller,
things stuffed up at the end of the song as the CDRom drive was stalling the
bus sufficiently to break up the stream of data from the HDD to the DSP.
This got me curious as to exactly how stalls affected the bus, and one part
of that was the test I did with the Seagates.

--
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
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.

It appears about normal from what usually comes from your part of the world.

However, I still believe my responses are still mostly correct

Not in that post.

(except the one about operating at exactly half speed, dunno why I said that ...):

Maybe because that is what you really think and why you had to correct yourself?
Twice.

see my response to Eric Gisin.

Which because of the sheer size of it and the odd linebreaks nobody might
read. And when you use mbytes (millibytes) when you mean MB (MegaBytes)
and that drives read and send sector for sector to the interface or read sector
for sector from the interface then I won't even bother to read further.

"Michael Brown" wrote in message
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.

Yes, it does. That is exactly the situation where 2 drives on a channel
do not sit in each others way:
Sequential reading which caches ahead and writing that doesn't hog the bus.

The write buffer on the drive

Write buffer?

will be 100% full all the time,

What write buffer?

and the read cache will never have a chance to get ahead of the interface

Gee, wonder what read-ahead caching is for then when it can't do anything.

(as the interface is 2-3 times faster than the off-the-platter speed of the drive).

That is why it is called a cache, a place where the data can be held until the
host requests it the next time that the bus is free.

The write request will be sent to the drive, but the interface will stall until there is a
free block in the (write) cache.

Pure nonsense.

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.

So what?
That is to the host. The host then sends it to the destination.
The action is serial whether single channel or dual channel. The interface runs
at twice the speed a single drive needs so running the action in series doesn't
loose them any transfer speed when run from read ahead cache to write buffer.
When the source drive reads 128kB to the transfer buffer that is transferred
to the host and then send to destination, it reads another chunk to the readahead
cache. The destination drive accepts the data in its buffer and then releases the
bus immediately. While the destination drive is writing from it's buffer the next
command is send to the source drive which then already finds it's requested data
filling the cache.

So as Eric said:
"so the host is transfering to/from the cache and both drives read and write at the same time".

[gibber snipped]


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" wrote in message
...
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.

That's flat false. The drive's onboard read and write caching are CRITICAL
to such an operation.


The write
buffer on the drive will be 100% full all the time,

Just NO!

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).

Wacko.

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)

NO, what HDs have either a 12mb or 12 MB buffer?

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.

Drivel ignored.

"- HAL9000" wrote in message
Yes this is my experience also. I did similar real life experiments too.

Although I would attribute the no 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.

A command is always for a contiguous part of data so there is no waiting for
revolutions other than as part of the access time directly from the start of
the command. Commands are limited to a maximum of 128kB (256 sectors).

This sequence intermixed between two drives.

If you mean 1) for the read and 3) for the write, then yes.
The system however doesn't need to wait for the write to finish, so the
read drive can get its follow-up command while the write drive is writing.
Of course the write drive isn't available until it has finished the writing.
Because of the commands are for contiguous data there is only head and
cylinder switches to deal with after the initial access seek and latency.


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

For OS related overhead only.


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.