If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
"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. |
#22
|
|||
|
|||
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 |
#23
|
|||
|
|||
"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. |
#24
|
|||
|
|||
"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. |
#25
|
|||
|
|||
"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. |
#26
|
|||
|
|||
"- 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. |
Thread Tools | |
Display Modes | |
|
|