On Wed, 2003-02-19 at 10:31, Jonathan Bartlett wrote:
> > While your statement is correct I did want to clarify that IDE and SCSI
> > were lumped together and they should not be. SCSI and IDE performance
> > expectations differ because their bus technologies are dramatically
> > different. IDE has some serious performance issues with multiple disks
> > per channel. A single disk can effectively tie up an IDE channel for
>
> Actually, IDE has performance issues even with only 1 disk per channel.
> The SCSI command set allows disconnected operations, so that the kernel
> can send commands (get block xxx, get block yyy, get block zzz) and keep
> sending commands while the drive processes the answers. With IDE, it is a
> synchronous transmission - get blox xxx, wait until disk processes,
> receive block xxx, get block yyy, wait until disk processes, receive block
> yyy. SCSI disks can also reorder the requests and service them based on
> how quickly it can get to each one.
>
> Even on one-channel-per-disk, SCSI wins out.
>
> Jon
>
Agreed. I think we are saying the same thing. You just happen to go
into more detail. :P My point being, if you use IDE, you should be
attempting to use a disk per channel. BTW, on a different note, IBM
created some IDE drives which allow for command tagging which allows for
multiple outstanding IDE commands, however, I have no idea what the
availability of said drives and drivers are. I'm actually fairly
ignorant on the exact device details. You wouldn't happen to have the
skinny of those things would ya? They still being made?
Your comments really serve to enforce that IDE stinks and stresses that
IDE should not be used where serious database performance is needed.
Needless to say, I think we all already understood that. ;)
Regards,
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting