On Mon, 30 Aug 1999, Andy Poling wrote:
> On Mon, 30 Aug 1999, Mike Black wrote:
> > But this is doing disk "reads" not "writes". It shouldn't need to read from
> > both disks.
>
> It does read balancing. That gives the best performance for an optimized
> configuration (in this case that would mean the two disks split across two
> IDE busses).
>
>
> > Read performance will usually scale close to to N*P, while write performance
> > is the same as on one device, or perhaps even less. Reads can be done in
> > parallel, but when writing, the CPU must transfer N times as much data to
> > the disks as it usually would (remember, N identical copies of all data must
> > be sent to the disks).
>
> This is in the abstract, and probably assumes an optimized configuration.
>
>
> > I should expect at least the same performance (when disks are on the same
> > bus) -- that's why I'm confused. I would actually expect better performance
> > given that the limit is the disk i/o speed and not the data bus. If disks
> > were on seperate buses I would expect better performance.
>
> I don't know much about IDE, but I don't think it will do well when getting
> pounded with requests for both disks (due to read balancing). It doesn't
> have a capability analogous to SCSI's command tag queueing to make a shared
> disk I/O bus practical. My understanding of IDE is that each command must
> completely finish before another can be begun.
Remember, IDE has a master/slave control system, you can only
talk to one drive at a time, no connect/disconnect, batch
commands/data, disconnect, batch the other drive, repeat. Just
connect master write these, <wait till finished>, go to other drive,
write these, <wait>, repeat, and that the IDE interface basicly sucks.
>
> Add in some overhead for using both devices, and I'm really not surprised
> it's slower than the single disk.
>
> -Andy
>
>
---
As folks might have suspected, not much survives except roaches,
and they don't carry large enough packets fast enough...
--About the Internet and nuclear war.
