Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.periphs.mainboard.abit,comp.sys.ibm.pc.hardware.storage (
More info?)
Eric Gisin wrote:
> "Michael Brown" <see@signature.below> wrote in message
> news:%AtLc.3097$N77.226298@news.xtra.co.nz...
>> 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 here: 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
an.2004.07.20.21.10.40.749665@TAKEOUTverizon.net...
Facebook
Twitter
Instagram