Interface Access Speed
At this point, not much else need to be said about the interface. To make that point, look at the charts again. Look at the data throughput figures. See anything interesting? You should! If you are using an IDE interface set up for bus mastering and burst transfer rates of 66 MBytes/sec, then you will never be able to get any of the drives listed to come all that close to taxing the interface. In fact, even if you could force the 15,000 rpm SCSI drives to talk to an IDE interface at the same sustained data throughput rates they boast for SCSI, it still wouldn't come all of the way to 66 MBytes/sec. Likewise, a SCSI controller running under bus mastering and offering a burst rate of 80 MBytes/sec wouldn't break into a sweat with the highest throughput drive. In fact, a 40 MB/sec controller wouldn't be all that taxed using most of the drives listed. As shown from the charts above, the buffer transfer rate is in the neighborhood if 1.5 times higher than sustained transfer rate (note that the Seagate U Series 5 seems to defy this formula, so don't bet your pay check on the results). Therefore, from this logic, the Cheetah's 48.9 MB/sec internal transfer rate would translate to something like 32.6 MB/sec sustained throughput. That wouldn't even saturate a UDMA 33 interface!!! In fact, only the Quantum Atlas 10K II and the Fujitsu MAH/MAJ series might saturate a 40 MB/sec SCSI interface with the IBM 75GXP series likely to swamp a UDMA33 interface. As for those SCSI drives, how their advertised internal burst rates of around 60 MB/sec would relate to the REAL WORLD of day-to-day DAW activity is hard to tell. Except for IBM and some of the Quantum and Seagate drives, the sustained rates aren't listed by most manufacturers because if they did list them, their drives wouldn't be quite as impressive any more!

From the point of view of interface speed only, it's a wash! Remember, in a DAW, you are interested in getting the highest throughput from one drive; period! You don't care if you can get high burst throughput from six SCSI drives all at once because that's not how you're going to be using it. Keep your eye on the ball. Sustained throughput is what need to be looking at.

SCSI is a very complex interface, and as such, it has a complex command set. The CPU must do more work to set up a SCSI transaction than it must do to set up an IDE transaction. As a result, in the specific world of the DAW, that is, a single user system not engaged in multi-tasking and multi-drive I/O, SCSI can be a bit slower than IDE. Remember, SCSI shines the brightest when you have a bunch of devices operating simultaneously. Your average DAW isn't one of these situations.

Another interface enhancement that holds no advantage for real time data streaming is cache. Disk controller cache is great for burst operations and random file access, but when data is being streamed constantly through the controller, there is no need for cache. Any cache would be overrun in the first seconds of streaming and never get a chance to refill again. For DAW use, ignore any advertised cache advantages.

Something important to keep in mind is the possible conflict that attaching devices of differing interface characteristics has on overall system performance. The autoinsert notification for CD-ROMS can hurt performance a bit because the system will periodically access the CD-ROM to test for the insertion of a disk. It is a good idea to disable autoinsert notification by un-checking that box in the Device Manager. At one time, attaching a fast disk drive as a master and a slow CD ROM drive as a slave on the same IDE channel would pull that channel's overall performance down to the level of the slower device. Early PIIX controllers put severe limitations on the configuration of IDE modes. There could be only two modes available. So, if both devices couldn't operate at the fastest mode supported by the controller, either both would run at the speed of the slowest, or one of them would run at PIO mode 0 regardless of its capabilities. The first PIIX imposed this limitation even across channels. The PIIX3 removed the limitation across channels, but not across devices in the same channel. The latest controllers with UDMA support (PIIX4 and PIIX4E) have removed these limits completely, and the mode can be configured independently for each device. This should not be an issue any longer. However, the software drivers may not all be taking advantage of the hardware improvement (We can't confirm if the drivers shipping with Win98SE take advantage of this improvement in channel mode selection, but Win2K does for sure). Even though this may be a dead issue, it doesn't hurt to avoid connecting a hard drive and a CD ROM on the same IDE channel unless the CD ROM does support UDMA (has a DMA checkbox in Device Manager like the hard drive) and it is enabled.

Lastly, if you want to use UDMA66 transfer rates and your motherboard doesn't support it, you can buy a PCI UDMA66 controller board and go that route. Simply disable your second internal IDE port and use the freed IRQ for the new interface. However, as we will see in the nest part of this article, even the average IDE drive running at 33MB/sec will likely give you more raw tracks than you will ever need, so don't hurt yourself trying to go for the fastest drive on earth just because it's out there. Those tracking at 24/96 rates will need to be a bit more mindful of drive speed and so should consider ONLY the UDMA66 or 80 MB/160MB SCSI options with the fastest, highest throughput drives. Even so, if you look at the drives with the very highest throughputs, there are both IDE and SCSI drives that tie at the top rates.

Cost
There is no secret that SCSI is more expensive than IDE. Not only are the drives more expensive, even for drives that compare equivalently with IDE, but you must also buy either a SCSI controller or a mother board with built-in SCSI support and that will set you back several bucks compared to a mother board without SCSI. At some point you need to justify the added cost if you want to go SCSI from scratch. Here are two. First, the SCSI interface only requires one IRQ and address space in order to operate all devices connected to the SCSI controller. IDE requires an IRQ and address space for each port and each port is good for only two devices. Do the math: 1 IRQ for 15 drives on SCSI, 2 IRQs for 4 drives on IDE. If your system is a resource hog, that may be enough to send the argument over the top toward SCSI. Not only is SCSI a better steward of your system's resources, but it isn't likely that you will run out of space on a SCSI bus any time soon even with 4 drives, a CD ROM, a JAZZ drive, a scanner, and a CDRW writer hanging off of your controller. On the other hand, if you plan to keep your DAW free of extraneous devices and uses and just do audio, then an IDE solution would seem better as you will not be taxing system resources, will not need to go beyond the 4 drive limit and will gain a bit if speed from using the less complex interface. On top of that, it's cheaper! After all, if you want to reach or beat the performance of the current fastest IDE disks, you need ultra-wide SCSI or better and one of the fastest SCSI disks. That translates into a rather large initial investment. Below is a chart listing drives by size and how much some internet sites are charging for them. As you would expect, these prices can and do change daily. However, all of these prices were taken during one day and should reflect the relative prices of the drives. Also on this chart is the max disk to buffer throughput. As mentioned before, this isn't the same as sustained throughput, but these figures were given for all drives in the chart and serve as a basis of comparison. The chart may surprise you. Some drives that have low throughput figures may be rather expensive. This may be because the buffer is larger or there may be more heads in this unit or some other reason. When looking over the drives in the list, keep in mind that a lot goes into pricing a drive. Many of these reasons have nothing to do with using them in a DAW.

Go to Page 16 (Part 4); Back to TOC