[conspire] Re: conspire Digest, Vol 18, Issue 9

[Ross Bernheim]

On Tuesday, November 9, 2004, at 06:15 PM, 
conspire-request at linuxmafia.com wrote:

> I've never considered using IDE RAID, for the same
> reason I don't use IDE
> drives in a high-performance computer. IDE data
> transfer requires the CPU
> for the entire transfer. A SCSI controller is actually
> a separate (slave)
> procesor. It receives a data request from the CPU.
> then it handles the
> transfer independently, using a DMA channel to send
> the data to RAM;
> when the data transfer is complete the SCSI controller
> interrupts the CPU
> to signal completion. The performance gain from SCSI
> is more pronounced with
> larger data transfers. I haven't seen benchmarks for
> IDE vs. SCSI, but I
> suspect performace is about equal for small transfers.
>
> Theoretically, IDE RAID could be implemented using a
> slave processor just
> like SCSI. The IDE slave processor would do all the
> work, transferring data
> directly into RAM using DMA. I'm guessing that IDE
> controllers have a more
> limited instruction set than SCSI, which prevents IDE
> protocol from
> supporting such architecture. If true, this approach
> would require extending
> the IDE/ATA specification, probably not a bad thing to
> do.

The situation is this. We only have 4 client machines on
the network. Files are mostly small. We need to share
the files so that we don't have problems of differing
versions of the files. We won't be banging on the
server very hard at all. Cost is a consideration. Boss
does not want a Windows based server for security
and maintenance reassons. IDE performance is
more than adequate for our use.

I agree that SCSI performance is better, but the 25 dollar
computer we got does not have it and the cost of a SCSI
controller and disk drives would have run up the budget
considerably.

> There seems to be a decline is SCSI use. Three factors
> have contributed to this:
> 1. Improved IDE performance.  2. Cost considerations.
> 3. Use of Firewire for external devices.

> IDE has gotten faster and is significantly less
> expensive than SCSI. System
> manufacturers who use to offer SCSI internal hard
> drives in low-end servers
> are now offering IDE instead, even in mid-range
> systems.
>
> Proponents of Firewall (correctly) point out that SCSI
> is not hot-swappable and
> Firewire is. The vast majority of external SCSI
> devices were utilized by users
> of Apple computers. Apple Computer was a long-time
> champion of SCSI, until that
> company ended up with the patent for Firewire. Many
> peripheral manufacturers were
> no doubt delighted that Apple started offering
> Firewire instead of SCSI.
> This development has led many to think that Firewire
> is good and SCSI isn't.

Apple developed Firewire, they didn't end up with it.
There are several other reasons Apple moved to Fierwire
  besides those you stated. First is a much smaller and less
expensive connector and the ability to have power on the
connector for external devices. This means that it is easier
to add to a laptop. Less clutter as a peripheral may not need
a separate power cable and power supply. Second is the
lower cost of cables. Third is the removal of setting addresses
on peripherals and the elimination of terminators that have
to be added to the end of the SCSI chain. Then add in the
extended cable lengths that can be used relative to SCSI.

For throughput, SCSI in its highest performance configuration
is still the king. But SCSI has not got the future speed increases
available that Firewire has. Firewire is now at 800Mb with future
increases planned into the multiple GHz range and into fiber
optic cabling.

At this point, IDE, Serial ATA, SCSI, and Firewire all have a place.
It is a matter of choosing the right one for a particular task with
a given set of constraints.

Ross