In response to our recent Tech Tip on SCSI drives (see inSync 5/24/00) and why they are often recommended for audio/video recording one of our loyal inSync readers has provided more depth of information. Jim, the author of what you will read below has written before and is very knowledgeable and helpful with these types of technical issues. Nothing he writes below changes anything we said in the previous tip, but it does provide some more depth of information for those who are curious. Since you are only getting 4 issues of inSync for the same price as your normal 5 issues this week I’ve decided not to edit his writing so everyone can enjoy the whole ball of wax.
Hello (again). I seem to have become a self-appointed SCSI and disk drive consultant to Sweetwater (as I have had a few of these messages “published” before). Please feel free to use as much/little of this as you want.
Audio Tracks on Separate Drives and Busses
There are two very significant reasons to record audio tracks to separate drives (and, for that matter, separate disk busses). These are:
A disk rotates, and has a moveable arm containing the recording/playback heads. Data are recorded on a series of circles (or cylinders) by these heads onto a one or more platters (or tracks). Rounding out the terminology, data are written into fixed-length blocks or sectors, typically 512 bytes each.
The fastest way to access a disk is by reading or writing sequential blocks (when you run out of blocks on a track, the drive switches to the next track — when you run out of tracks the head arm moves on to the next cylinder). Randomly accessing sectors on a track is slow because the drive has to rotate around to the appropriate sector. Randomly accessing cylinders on a disk is VERY slow because of the required arm movement. Average disk random access time is calculated by adding half the maximum head movement time to half a rotation time.
The point of all of this is that a single well-optimized application will pre-allocate a large space and read/write sequentially. If several applications access a disk at once, inevitable random access will occur, moving the arm around, adding significant delays. As audio streams, the drive, even though very fast, may get to the required location too late to move the data. You can actually “hear” arm movement on a drive — the more you hear, the slower it’s transferring data.
By the way, some drives periodically pulled the arm all the way out to recalibrate the drive. Newer drives don’t do this (for a while the phrase “audio ready drives” or some such was used to charge extra for this change). Nevertheless, even new drives may move the arm to retry I/O during error recovery.
All of this is relevant when burning CD’s from disk images, and when recording or playing back video.
Some “real world” numbers: A wide, Ultra-2 SCSI bus theoretically runs at 80 megabytes per second. A “top of the line” drive, transferring large blocks of data sequentially, will run at about 37 MB/sec. The same drive, transferring random small blocks, will run at UNDER 1 MB/sec. — sometimes as slow as 200KB/sec. Stereo 96K/24-bit audio requires at lest 576KB/sec.
The cable connecting several disks together (the “bus”) is also shared, and can only transfer one disk operation at a time (well, mostly true — Fibre channel can transfer in both directions simultaneously).
This means that the bus is a shared resource and is also subject to degradation from other application activity. This is why many disk controllers allocate a bus to each (or a small number of) disks.
In all fairness to the applications, in many cases, the performance is only as good as the operating system, device drivers, and file system design allow.
Why SCSI?
As you rightly said, there are slow SCSI devices, and fast ATA devices, and so on. Generally, newer gear outperforms older gear — this includes the SCSI interface card, the CPU, the motherboard as well as the drives.
Here are some of the advantages to SCSI drives:
The SCSI protocol, together with modern PCI-based “higher-end” SCSI controllers off load most of the data transfer work from the CPU, eliminating application processing contention from interfering with the data transfer.
If a high-end SCSI subsystem “hogs” resources, it is either very poorly designed (unlikely on any product from established vendors), or the motherboard chip set or PCI bus is out of date. The whole point of high-end SCSI subsystems is to minimize system overhead.
Having said that, the WHOLE system will only run as fast as its slowest component. Also, not to frighten anyone, but I’ve seen some “brand-X” motherboards fail under high PCI data transfer loads (this probably isn’t an audio issue, but could be a video issue).
SCSI supports more drives per bus — this can be a blessing or a curse.Typically cited transfer rates for ATA, SCSI, and Fibre Channel are mostly baloney, because data can only transfer as fast as the disk drive is capable (see the stuff about rotation and arm movement above). You can approach published “theoretical” maximum transfer rates by running multiple drives at once, letting one transfer while others are moving to the appropriate data blocks.
However, if your application is well designed, one drive on a bus could actually block transfer from another.
SCSI drives are typically slightly more reliable, because they were designed for the server market rather than the consumer market. They cost slightly more, too.
SCSI subsystems are generally added to a system by adding a PCI card to a system with internal drives. This, almost by definition, eliminates the issue of “sharing” the drives with the OS or other applications.
As you also implied, there are fewer SCSI implementations and thus fewer cases for vendors to test. SCSI standards (from a device driver standpoint) are a bit more general than some other protocols.