IDE versus SCSIIDE versus SCSISome of you readers may know that i'm an active member of Adaptec's CDR List. Every now and then, some heavy debates and sometimes even flame wars start appearing on the newsgroups and this list. The SCSI fans will start summing up the advantages of SCSI, and start telling everyone that IDE is crap. Then others reply that their IDE system works fine, and costs only half the money. Of course, both parties have a point. So i wrote this summary, to get some fables out of the way, and place some true facts on the WEB instead. Read through the list of claims, to get an impression. Note that most are neither true nor false...
At the end of this page, there's a nice summary of commonly used terms.
Since IDE/ATA is mostly a stripped-down version of SCSI, this must be true.
This is more true than it should be. If you look at harddrives, the only difference between IDE and SCSI is the interface card that is connected to the moving parts. The more expensive SCSI card can add some to the price of the unit, but is no justification at all to double the price.
This is not definitely true. The origin of this fable lies in the past. There used to be a large gap between high-end drives and low-end "consumer" drives. The high-end drives were fast, reliable and only sold with SCSI interfaces. The consumer drives were slower, less reliable, and only sold as IDE units.
Nowadays, things have changed a lot since technology evolved further. The gap has been filled, which means that now you can buy high-end units with an IDE interface, but also low-performing unreliable consumer drives with a SCSI interface. Only the top-high-end of the market, like 10000+rpm drives are still exclusively sold with a SCSI connector. As for the "normal" devices, the actual drives are usually identical for the IDE and SCSI versions. Seagate for example is notorious for building drives that even perform worse in SCSI than in IDE.
This is partially true. Just like SCSI, other devices on the same controller must shut up while one device "talks" to the controller. So if the device can talk faster, the other devices can grab the controller earlier too. The rate at which a device talks to the controller is called the "burst transfer rate".
Since not every device is talking all of the time, the slowdown only occurs if at least two devices want to talk at the same time and there is not enough bandwidth available to accomodate both.
For any kind of bus, no matter if it is SCSI or IDE or USB or ISA or PCI or RAMBUS or whatever, only one and one device only can be transmitting data over it at a certain time. (When two devices attempt to "talk" at the same moment, we call that a "collision", and both must abort the transmision and find ways to solve their differences). It is the "time" that is being shared on the bus, not the transfer rate. Each device on the bus can talk at a different speed, as long as the one it's sending data to can handle that speed. So if you connect a 4MB/s device on a UW3 chain, your UW3 harddrive will still be capable of transferring 80MB/s. If you put a PIO mode 0 ZIP drive on the IDE together with a UDMA66 harddisk, the harddisk will still be able to reach the 66MB/s burst transfers.
Now suppose we have a scanner on the bus. The scanner is capable of transmitting 2MB/s over the line. Now suppose the scanner has a large amount of data (let's call it an image) to transfer, in total 10 MB. With the 2MB/s capacity, it would take the scanner a total 5 seconds to transfer the data over the bus. Of course, it would divide the data into much smaller chunks (like 16kB each), and send these one at a time. Otherwise it would occupy the bus for 5 seconds in a row, and other devices on the same bus might consider that rude.
Now take a harddrive. We've got this really neat UW drive capable of transferring a blazing 40MB/s. Suppose this harddrive has a file to transfer of 80 MB total. You may have calculated already that the total transfer would take 2 seconds to complete.
Now suppose the scanner and harddisk are on the same bus together. To please both, the controller will have to talk to the scanner for a total 5 seconds, and it will have to spend 2 seconds talking to the harddisk, totalling 7 seconds. In the end, it will have transferred 10+80=90 MB in 5+2=7 seconds. If you look at the average speed of the bus, it has dropped to 90/7 or about 13 MB/s. This is the performance hit in using multiple devices on the same bus.
However, there's a fault in this calculation that some of you may have seen already. The harddrive we talked about may be able to transmit 40MB/s over the SCSI bus, but it is not able to retrieve data that fast from its rotating platters. The transfer from platter (called contimuous transfer rate) is usually much lower. Let's assume we have a (not so good) harddisk that can transfer 10MB/s continuously when reading data sequentially. The data coming from the platters is put into the cache of the harddrive, and whenever there's enough in the cache, it is sent at 40MB/s to the controller. Now to transfer the 80MB file, the harddisk will need 8 seconds. The harddisk will only be talking during 2 seconds total, divided over that 8 seconds. During 6 seconds, the SCSI bus is doing nothing. So during the "idle" period of the harddisk, the scanner can kick in and transfer some data too. Since the scanner will only need 5 seconds, there's (even after connecting the scanner) still one second of silence on the bus. To summarize, the scanner does not slow down the harddisk at all in this case. Other scenario's to consider how much harddrives of this type you could connect to a single bus, such that they don;t slow each other down even when they're all running? (the answer of couse is 4).
So in order to calculate if attaching another device will slow down the rest (if everyone's talking simultaneously), you'll need to know BOTH the max burst transfer rates, AND the contiuous transfer rate. Calculate the quotient of (contiuous transfer)/(burst transfer) for each device. Add up these numbers. If the total is above 1, your performance may drop. If the sum is below 1, you will not notice a performance hit.
Harddisk A: 10MB/s continuous, 40MB/s burst
Harddisk B: 20MB/s continuous, 40MB/s burst
CD-ROM C: 2MB/s continuous, 10MB/s burst
8xCDR D: 1200kB/s continuous, 4MB/s burst (writing)
The ratio's are A: 1/4, B: 1/2, C: 1/5, D: 3/10
For example, a bus with two drives, one of type "A" and one of type "B", a C and
a D would have a "saturation" of 1/4 + 1/2 + 1/5 + 3/10 = 1.25, so it would be
too much, and you might see lowered performance if you're using them all at the
same time.
A bus with a A,C,D would be 0.75 saturated.
A bus with B,C,D would be 1.0 saturated, on the edge...
There can be troubles with buses that implement multiple standards. In order to remain compatible with older versions, the whole bus must sometimes be restricted to the "lowest common denominator".
A case where this happens is with differential SCSI. If you have a differential capabable harddrive and controller, they'll be able to talk using different signalling levels and methods. But is an "older" device is attached to that chain that doesn't understand differential SCSI, it pulls the "diff-sense" signal down and all devices on the chain are being forced into non-differential mode, also restricting burst transfer rates.
A solution provided by card manufacturers is to put two connectors on the card, and have the differential capable chain on one side, and the non-differential on the other.
SCSI has a feature called "disconnect". This feature does not exist for IDE devices, and this could well be the one and only advantage of SCSI over IDE. However, since only 2 devices share an IDE bus, there will not be many devices to suffer from this. This disconnect feature is what Adaptec seems to call "multithreaded".
Adaptec also makes some references to "Industry standard benchmarks". I regrettedly do not own such programs, but fortunately i own Adaptec's very own SCSIBench program. Under NT, you can use it also to benchmark IDE devices. Guess what, the results clearly show that my IBM deskstar 14.4 (7200rpm, UDMA-33) definitely IS capable of transferring 33MB/s to my system. Also they conveniently forget to mention that "doubling the maximum transfer rate to 33 MByte/sec buys little as the limitation still remains the drive" is also valid when you're talking about SCSI.
That's a misunderstanding. Each adapter, whether SCSI or IDE, needs only a single IRQ. On a PCI system, multiple cards can occupy the same IRQ, so nowadays, there's little limit to the number of PCI devices you can plug in. However, by default the primary and secondary IDE controllers take up a reserved IRQ each, so on a SCSI-only system, disabling unused IRQs frees up some resources. The real advantage here is not that SCSI needs less IRQs, it's that you'll need fewer SCSI controller cards because you can attach more devices to the same card.
Both SCSI and IDE have their pros and cons. IDE has some limitations that make it more suited for a consumer market than SCSI. And before you decide, remember that you don't have to choose. You can run the best of both worlds in a single machine.
Basically, if you can find a unit that suits your needs in terms of performance, and it's IDE, you should go for it, as you'll get the best value for your money. But if you've run out of IDE connectors already, you'll want to consider adding a SCSI card and go the other way.
The main advantage of SCSI over IDE is the number of devices you can connect to a single controller. With IDE, the limit is a mere 2 devices per controller. For SCSI, the limit is up to 8 UW devices plus up to 7 UW or non-UW devices, thus totalling at least 7 devices. So if you plan to add a lot of devices, SCSI is probably the way to go, allthough nothing prevents you adding 5 IDE controllers to your system.
Another reason to move to SCSI could be that you can put them in an external case easily. SCSI cards have an external connector that allows you to attach devices located outside the computer case. Though it is possible to have external IDE devices, this is not common practice.
Personally, i like both. Thus i have a PCI SCSI adapter in my machine that attaches to my CD writer and CDROMs, and I also have three cheap IDE drives connected. I must admit that SCSI is better than IDE, but the price difference is in my opinion no way justified. For high-end heavy multitasking environments, SCSI is currently he only way to go. But i still like the IDE RAID controllers.
Basically the low-end part of SCSI. The alternative is Synchronous transfer,
which allows much higher data rates. This is very similar to how a parallel
port talks to your printer. In async. mode, the device and controller transmit
byte-by-byte, thus it looks as follows:
Device puts data on wire
Device signals controller data is ready
Controller reads data
Controller signals the device that the byte has been received
Next byte of data is transferred.
ATAPI (ATA Programming Interface) is the protocol used by (E)IDE drives. In fact, the debate is not IDE vs SCSI, but ATA vs SCSI. In practice, ATA is a stripped-down version of SCSI, designed to make devices cheaper.
The burst transfer rate is the rate the controller and harddisk "talk" to each other. Not to be confused with the continuous transfer of a harddisk.
Busmastering is, in short, DMA for PCI. A device on the PCI bus can take control of the memory bus, allowing it to read or write to system memory. Up until the Intel 440FX chipsets, there were only few busmastering IDE controllers, but starting with that, all motherboards nowadays have busmastering IDE controllers built-in. Busmastering SCSI cards are also very common, and inexpensive compared to several years ago.
The continuous transfer rate is the average speed at which a harddrive can deliver sequential data to the system. This is always (much) less than the burst transfer rate. The continuous transfer rate is dependent almost exclusively of the physical setup of the drive. Determining factors are drive rotation speed, the way the sectors are spread on the surface and the number of platters (writable surfaces). Whether the drive is IDE or SCSI should have nothing to do with it, but there are often minor differences between IDE and SCSI here due to overhead, cache size, and other minor issues.
Normally, signals are sent through wires using a reference "ground" and a single line that is either +xV or 0V (usually, x=5). An improvement for long flat cables was to make alternating wires (signal0 - ground - signal1 - gound - etc.), which isolates them better. Differential signalling uses a two-wire per signal system. There need not be a common ground, but each pair of wires forms an isolated signal/ground pair. Only the voltage difference between the two wires matters. Since both wire pick up roughly the same interference from their environment, this delivers a much better quality signal, allowing higher data rates. This technique is also commonly used in (professional) analogue audio/video transfers.
SCSI has a feature called "disconnect". Normally, a device gets a command from the controller, fetches or stores the data, and then sends back a response. If storing or retrieving takes a while, the controller is kept busy waiting for the device to finish this operation, and other devices will not get any attention. This starvation can be prevented by doing a disconnect. The device will disconnect itself, signalling the controller, and others can talk to the controller again, and when the device finishes its business, it reconnects to the controller.
Direct Memory Access. Data is transferred from an expansion card like a soundcard, SCSI or IDE controller, or any other type of board to the system memory without any intervention by the CPU. Early MFM drives made use of DMA a lot. Because PIO was faster on these mostly ISA systems, the DMA mode was abandoned when RLL and IDE came into play. When VLB and PCI arrived, DMA was at least as fast again, and so DMA made a come-back for IDE. On PCI systems, DMA has been implemented with busmastering.
Stands for Enhanced IDE. The enhancement is the addition of DMA modes, and the increase of burst transfer rates.
Integrated Disk Electronics. Is the interface (controller and cable) commonly used for harddrives and CDROMs. The term indicates that most intelligence like sector addressing, data encoding and decoding is done by the device itself instead of by the controller. IDE controllers are therefore cheap, which is a reason for their success. Even SUN is placing IDE drives in their ultrasparc workstations nowadays.
Interrupt request. This is the way expansion cards an other devices signal the CPU that they want attention. On a standard PC, only 16 IRQs are available, and many have been reserved already. Luckily, devices can share IRQs. For PCI cards, sharing IRQs is standard.
32-bit interface for computers. Can be used for virtually any expansion card. The main advantage over ISA and VLB is that the PCI busses can be identified, meaning that the system can actually see each individual slot, each has its own signalling lines. This is what allows PCI cards to share IRQs (PCI steering) so easily.
Programmed Input/Output. Data is transferred from an expansion card like a soundcard, SCSI or IDE controller, or any other type of board to the processor (CPU) only. The processor can then move the data to memory. This method of transferring data is faster than DMA on ISA systems, because on ISA systems the DMA must be done by a DMA controller chip which is notoriously slow. This is the reason this method is being used on many devices. The method is very CPU-intensive. On PCI (also AGP, VLB) systems, DMA transfers are about equally fast (sometimes faster) because the DMA controller is no longer used for these kind of systems.
Small Computer System Interface. A communication protocol for computer devices like harddrives, scanners and CDROMs. There are many implementations, but the basis is the same.
Alternative mode for asyncrhonous. In sync. mode, the controller and device agree on a fixed data rate. The device then puts data on the bus at this fixed rate. Since they don't have to synchronize using data ready/data acknowledge signals, the rate at which the devices talk can be much higher.
VESA Local Bus. One of the earlier 32-bit interfaces for computers. Replaced by PCI later, but provided well-performing harddisk and video interfaces for mostly 486 class machines.
Mail
me
Visitors so far:
Back
to index