Re: Dumb question: Which is "better" SCSI or IDE disks?

Leonard Zhang System Administrator ISD RVIB (
Sun, 6 Dec 1998 20:42:25 +1000 (AEST)

I think currently spinning SCSI hard disks on the world, either in servers
or workstation, either in Unix/Linux or NT, is 50-pin old guys, no DPT disk
cache or RAID. My comparison is base on this current real world. Not on
the most up-to-date technology.

At least Adaptec are still manufacturing and selling 16 bit SCSI card for
about $A100.

No one denies SCSI's performance, expecially when you want hook up over 4
devices. Those persons who asked the question do not have enough bucks in
their pockets. My comparison is based on this ground. Everybody wants a
Ferrari, but not everybody can afford. They buy Daiwoo not because they
don't like Ferrari.

DPT cache + RAID, not including SIMM, or error correction RAM is about $A2000

If the disk assembly is the same, the date output from the physical disk is the
same either in SCSI or IDE. It depends on how many sectors/bits can pass under
the aligned head. It depends on how fast the disk is spinning, and how many
sectors the manufacture can squeeze in a cylindar.

If the disk assembly is the same, the MTBF is the same either in SCSI or IDE.
The reliability is the same.

If the disk assembly is different, it is another story.

Maximun data tranfer rate for 8 bit ISA bus is 1.38MB/s, 16 bit is 5.5 MB.
The IDE interface of current mother board with built-in IDE is PCI.

Somebody attributes the smart functions of controller card to SCSI hard disk
itself, others just think that the CPU can not do anything except waiting,
IDE disk to get data ready after issuing disk read command.

High data transfer rate of SCSI can only be envisaged in the situation when
several disk activity happens at the same time, especially there are quite a
lot of devices on a same bus.

The bottle neck for disk access is in getting out data from the cylinda, not
on the data tranfer rate. Suppose, disk spins at 6000 rpm, the head right
over the cylindar, and standard 63 sectors per cylindar, in this idea
situation, data rate is < 3.2 MB (not including track seeking time.)
The data transfer rate becomes critical only in the situation, when several
disks get data ready, waiting for transfering.

If you can manage to hook up all your devices in IDE, switching to SCSI may
not get real benefit.

For those get flamed by my previous mail, my good advice to them is to
excercise their NETIQUETTE.


On Sat, 5 Dec 1998, Rik van Riel wrote:

> On Sat, 5 Dec 1998, Leonard Zhang System Administrator ISD RVIB wrote:
> > 1. Some hard disk manufactures are using same disk drive
> > (physically) to make SCSI and ATA. They only change the PCB board.
> And together with that they change the cache and add far
> superior firmware than the crap they put on the IDE disk.
> > 2. SCSI-1 and SCSI-2 have 8 bit data bus, while ATA have 16 bit data
> > bus.
> Irrellevant and not always true. SCSI utilizes the bus much
> more efficiently (disconnect/reconnect) so the effective
> bandwidth is usually more with SCSI.
> > 3. ATA got disk cache built in as well.
> But it is usually far less cache and ATA doesn't provide
> the logic infrastructure to actually use it in an intelligent
> way (although IDE write caching has improved things a little
> bit). You lose another data point for the fact that IDE
> cache firmware often is almost braindead.
> > 4. Some low end of SCSI host card is only 8 Bit card.
> Some low end IDE drives are slow -- what's your point?
> We are comparing the equipment of TODAY. It would be
> total nonsense to compare IDE stuff from today with
> 1991's SCSI controllers...
> The way you are comparing IDE and SCSI is just too biassed
> to be taken seriously -- please make a more balanced
> judgement next time...
> regards,
> Rik -- the flu hits, the flu hits, the flu hits -- MORE
> +-------------------------------------------------------------------+
> | Linux memory management tour guide. |
> | Scouting Vries cubscout leader. |
> +-------------------------------------------------------------------+

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at