>
>On Mon, 18 Jan 1999, Jeremy Wohl wrote:
>
>> On Mon, Jan 18, 1999 at 02:43:31PM -0800, Aaron D. Turner wrote:
>> > Performance is going to *suck* with 5 IDE disks, assuming of course you
>> > can actually get 3 IDE controllers to work in the same box.
>>
>> OK, what's the bottleneck here? The track-to-track seeks, bandwidth,
>> cpu use seem to be reasonable on top-line ide vs. scsi disks. The
>> drivers? what?
>
>...And Tom wrote:
> The ATAPI protocol stinks. The biggest problem is the inability to have
>multiple outstanding IOs per channel, and per device. The CPU use is much
>higher for EIDE.
>
Sorry Tom you are mistaken.
Ultra ATA (EIDE) disk drives don't use the ATAPI protocol to do I/O.
ATAPI is an add-on protocol to allow devices like CDROMs to
be attached to IDE cables.
Of course you can have multiple outstanding IOs per device. It's
just that in the ATA case the queue resides in the driver. Considering
the internal latency of any drive (ATA or SCSI) to move from one random
request to another there is little advantage in queuing up the requests
inside the disk drive versus leaving the queue in the driver. In fact,
depending upon how the request arrive at the driver, it could be
argued that it is more efficient to have the queue in the driver where
it can be kept sorted.
If the ATA controller chip is configured to use PCI Bus Master DMA
then the CPU use is nominal. Commanding the ATA controller requires
initializing a scatter-gather table pointer (outl) followed by 6 outb's to
specify the start sector, transfer length and the direction of transfer.
Is that expensive?
Steve.
