[ILUG] ide cd writer

[Paul Jakma]

On Wed, 11 Jul 2001, Colm Buckley wrote:

> I've used IDE and SCSI systems extensively over the past few years,
> and they both have merits.  Chief among IDE's merits is cost of
> purchase; the mass-market economics of the controllers and drives have
> really driven costs down.

definitely.

> However, cost of purchase isn't the only cost associated with a
> system - my experience of IDE is "it's only cheaper if your time is
> free".  Modern SCSI systems "just work", and you don't have to waste
> time messing around and worrying about whether DMA is on, or which
> transfer mode your controller is in.

true.

> Unlike IDE, the slowest device on the bus doesn't hamper the whole
> bus.

but why is this?

In SCSI you have disconnects and bus arbitration. presumably in IDE,
this doesn't happen, and if the controller sends a command to a CDROM
(eg give me this block) it has to wait for the CDROM to finish the
command before it can talk to anything else.

however, you can still run one IDE device per bus.

> Unlike IDE, more than one device can be active at a time.  Transfers
> between devices need not involve the controller at all.

this is is extremely extremely rare. i doubt it would happen under any
conditions in linux.

> Unlike IDE, devices can be dynamically added and removed.

this is nice yes.

> Unlike IDE, commands can be queued up at the controller and the CPU
> need not become involved until they're all finished.

IDE has command queueing now aparrently as of UDMA66, iirc.

> In a situation where you have both a large data flow *and* intense CPU
> activity (eg : a big compile), SCSI really wins - the constant
> mode-switching which the CPU has to do to cope with IDE really hits
> performance.  Example, my machine ogma (fairly modest PIII/500) takes
> about fifteen minutes to compile the kernel on its EIDE drive (ATA66,
> DMA enabled), but only eleven on its SCSI drive.

this one i don't understand in a sense. i see this too in practice.
Given that IDE is so so much simple than SCSI, it must follow that the
interface to an IDE controller is a lot lot simpler than to a SCSI
controller.

And a very simplistic wc of the source code confirms this, the line
count for a SCSI host driver is an order of magnitude bigger than for
eg,

wc -l ide-dma.c ide-features.c hd.c piix.c -> 2412

 15067 sym53c8xx.c
 12242 aic7xxx.c

and that's being generous to SCSI cause i'm only counting the host
specific c code.

So there shouldn't be that much involved in asking an IDE controller
for a block of device y. whereas in SCSI you have to work out a whole
bunch of stuff, the tags, ordering, etc..

the transfer itself: The IDE controller can do PCI bus master
transfers to memory.. so that shouldn't be a factor.

bus speed: IDE is actually ahead in this dept. eg UDMA66 is 66MB/s
(no?) and is common. SCSI is at 40MB/s for SCSI-3 wide / Fast20. or
you could compare it to Fast40 wide SCSI at 80MB/s. But then you have
UDMA100.

Fast80 SCSI at 160MB/s for wide exists isn't that widespread yet.

The disks themselves: well nowadays they're identical except for the
bus interface - except for the very new and high-end SCSI disks.

So in theory IDE should be faster.

> Basically, people who go on and on about how SCSI is better are
> sometimes just snobs repeating what they've been told, but at other
> times (like this), they're speaking from real experience.  I wouldn't
> use IDE on a machine where disk I/O or ongoing maintenance was going
> to be anything other than an trifle.

i don't why, but i agree. i'm a scsi snob too. :)

i just don't understand why a bus designed to be simple can possibly
be slower than a bus designed to be jack of all trades - even in
simple situations such as multiple IO to one device on a single bus.

how did they fsck up so badly with IDE?

>             Colm

--paulj