D. Glen Cardenas

SCSI vs. IDE pt. 2

Fri, 01 Sep 2000 00:00:00 GMT

Many things will affect the performance of digital audio software in general, and multi-track production software in particular. The performance of the disk drive being used to store the audio data is only the beginning. Naturally, this component must be of optimum efficiency in order to allow real time streaming at a high track count. However, this isn't necessarily always going to be the limiting factor in a DAW's performance. There are other places to look as well.

Modems: Having a modem plugged into a DAW's PCI bus can lead to conflicts, particularly if the modem is a voice modem. Some production software will attempt to configure the modem as a sound card. While more "aware" programs such as Cakewalk will report a modem upon finding it and allow you to ignore it as part of the sound system setup, other programs may not, and could default to a lower bit depth or sample rate as a result. Many DAW users agree that an external modem connected to one of the computer's serial ports is the safest way to go here.

Video: Likewise, using a fancy accelerated 3D "gamer's" style video card can cause significant degradation in system performance due to the high demands of the card on system timing. The fact is that DAW software is not graphic intensive and doesn't require a high performance video card unless you intend to do A/V production. If that is the case, follow the recommendations of others in the field who are using the same kind of motherboard/processor configuration as yourself and choose a video card accordingly.

Windows Settings: Sometimes turning down the hardware acceleration slider (from Control Panel double click the "Display" icon, go to the "Settings" tab and click the "Advanced" button. The slider is in the "Performance" tab) will improve performance, though it can also disable your video card's higher resolution/color functions.

Specificity: You may want to consider maintaining your DAW separate from all non-DAW operations and use another computer for internet activity, game playing and business applications. Your DAW might then contain only the sound cards, video card and an Ethernet card to allow transfers to and from the DAW and the separate system containing the CD recorder, internet access, back-up space, etc.

Simplicity: You may consider not even putting a CD drive in the DAW. You can access the CD ROM on the other system over the Ethernet as effectively as if it were a local drive. To prevent the Ethernet LAN from consuming system time, you can re-boot your system when you wish to do very demanding streaming production and at that time decline (hit ESCAPE) when asked for your network password. When your production load is not so demanding or when you want to move files around, re-boot and enter your network password to sign on to the LAN. All of this may seem a bit extreme, but it doesn't hurt to consider it.

Testing: If you wish to use one system for all of your computing needs as well as a DAW, then you will want to consider carefully each choice you make in terms of devices and software you install. After any changes you make, test your system fully for potential conflict with your sound equipment and production software. This way, if something causes trouble, you can quickly pin it down to a single item.

Screen Savers: As a general rule, do not load or configure any screen savers or activate the power saver functions of your DAW. These features consume resources and at the oddest moments. Screen savers were important in the days of monochrome displays due to screen burn-in. However, modern color monitors are not subject to this problem, so don't bother with them. Do not use a background virus scanner, although you will want to have one loaded to perform scans on demand from time to time.

2 Drives or Not 2 Drives?

There has been some debate as to the proper allocation of disk space in a DAW. For one thing, many feel it is important to keep the software and data on separate drives for fear that the system might bog down if required to access different parts of the same drive for software while data is streaming.

When you have a large executable plus DLLs, (simply) running the program doesn't always ensure that all of the bytes (for that program) are loaded into physical memory. Some "pages" of the code can remain on disk, and will be paged in on demand when certain areas of the program are executed for the first time.

For an example of this, watch what your disk does the first time you open the Staff View in Cakewalk. Then watch it again the second time you open the Staff View. Also, every program has "resources" (text, menus, dialog boxes, etc) which live on disk, paged in on demand. So unless the DAW prevents the user from manipulating the UI during playback, it is not true in general that the only disk access you'll get during streaming is from the data files.

Of course, there are ways to be clever and force things to get paged in ahead of time. This is actually easier to do under NT than on Win9x, but on a system with not a whole lot of RAM this isn't a good idea.

Ron Kuper
Chief Technology Officer, Cakewalk Music Software

The key word in the above statement is "RAM". If a DAW has sufficient RAM, then the user can open the views they intend to use during streaming before streaming starts. Those resources are then pre-loaded into memory. As for the dialogs and menus and so on, it must be understood that cranking around in the program while doing very demanding streaming isn't a very good idea anyway, even if the disk access for those resources is negligible.

The simple fact is, once a digital production program is running and streaming data, the drive shouldn't have to access the disk for more software. All the software it needs should be in RAM. With a bit of planning and prudent use of the UI during streaming, this shouldn't become an issue. Therefore, there is no drive access conflict.

Aside from being able to back up one drive to the other to guard against loosing your data to a sudden disk crash, the best reason to use two drives isn't to keep the data and software separate, but being able to put the partition holding your streaming data at the very front of a drive. This has advantages as we will discuss below, and has a much higher impact on overall performance than having the data and the software on two separate drives.

Virtual Memory

Ron Kuper also offers the following observation, "Another process which can hit the disk unexpectedly is virtual memory compaction and/or cache cleanup. Windows can decide to do this during 'idle' time. What constitutes 'idle' time? It's up to the O/S."

With the virtual memory wild card in mind, many have advocated that disabling the Windows virtual memory will provide a boost in performance because the system will no longer attempt to use the swap file on the disk, removing this possible conflict during streaming. This is not a good idea. Again, if you have the proper amount of RAM in your system to load the software you need and to buffer the data as it streams, then virtual memory will not need to swap at all.

Although preventing errant housekeeping tasks is almost impossible, you can minimize the effects. For advice on optimizing the virtual memory system, read the article Virtual Memory Optimization by José Catena. There is also good advice there on how to change your Windows cache settings to enhance performance. This article is required reading for anyone wishing to fine tune their system.

Other Tweaks

Another simple tweak that helps is setting the "System Type" and "Read Ahead" optimizations. To get to them, open Control Panel and from there double click on the "System" icon. Go to the "Performance" tab and then click on the "File System" button. There is a box that allows you to select the use to which your PC will be put. The "Desktop" setting is the default and will likely be the setting you see when you look here. Changing that to "Server" gives higher priority to disk I/O, which usually helps a bit with disk intensive applications such as those found on a DAW.

You will also see a "Read Ahead" optimization slider. By default, this should be set to maximum (64 KB) We recommend that you leave it there. It might be worth noting that some audio programs recommend resetting it or even set it automatically to the minimum, but this usually results in very little improvement for those programs and noticeable degradation for others. It might be wise to check this setting from time to time to see if it has been tampered with, especially if you notice a sudden drop in performance of your system after running a new program for the first time.

Some drive optimization tricks can make a big difference. If you share a disk for audio and other data or applications, you can partition the drive such that your audio data is concentrated at the front of the disk. This area has as much as 60% faster access performance than the back of the disk. On a single drive system, one might partition (for example) a 10 gig drive with 10 MB as a C drive boot partition only, which then points to the E drive where the operating system is installed, then a D drive partition of 6 gig for audio. The back partition, the E drive, would hold Windows itself and the application software. Of course, a better option is to dedicate a drive to only audio data.

It is also true that streaming is more efficient using large cluster sizes, not the default 4K clusters generated by the Windows FAT 32 partitioning system. You can force the issue by applying the /Z:64 switch to the FORMAT command. This switch will tell FORMAT to build each cluster out of 64 sectors thus generating 32K clusters (each sector is 512 bytes). Better still, use a program like Partition Magic to reset the cluster sizes without having to reformat the drive or destroy your current data. As a side note, if the partition in question is 2 gigabytes or smaller in size, it can be partitioned using FAT 16 instead of FAT 32. For more information on optimizing your disk system, read Hard Disk Optimization by José Catena.

Finally, 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.

Application Design

Certain multitasking schedule and synchronization issues can degrade file I/O performance because audio buffer processing is a very high priority task. It can take a significant amount of available time, particularly with heavy real time effects loads. This can be minimized if disk I/O is done through bus mastering or at least DMA, and the application has been designed to optimize disk I/O throughput.

As a general rule, the ratio between audio buffer size and file buffer size is critical for such optimizing. The larger the file I/O buffer, the better. The smaller the audio buffer, the better. The file I/O buffer size should be large enough so that the typical time required to transfer a file buffer to/from disk is significantly larger (4 times or more) than the time required to playback an audio buffer. If the time ratio is low, the performance penalty will be large, and if it's below 1, it will be dramatic.

As a consumer, it is up to you to judge your application software wisely and invest in an application that has a good track record overall, and a commitment to customer support. If the software can't take advantage of the high disk throughput you've invested so much into, then you've shot yourself in the foot.

Contents
	Introduction
>>>	Other Factors
	About SCSI
	About IDE
	Bus Mastering
	Bus Mastering and DMA
	UDMA Bus Mastering
	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 3

Fri, 01 Sep 2000 00:00:00 GMT

The SCSI interface is an old timer. Before there was IDE, there was SCSI. It was used not only for disk drives, but scanners, printers and even to interface the PC with synthesizers and automated sound and light boards. For a long time, SCSI was the only really high performance disk interface, and in early versions, high performance was a whopping 5 MBytes/sec. WOW! Remember, that was in the time before the PC-based DAW, before Windows and before a person could buy a PC with more than 1 meg or RAM. Here's a quick rundown on SCSI.

The History of SCSI

In 1980, SCSI amounted to a proposed interface whose specifications occupied little more than 20 pages. Compare that with the more than 600 pages used to describe the interface standard today. In 1985, a group of manufacturers got together and started pressing for ANSI to define SCSI. This came to pass in 1986 with the publishing of the first SCSI standard, now referred to as SCSI-1. This new interface standard consisted of a controller card, often called a host adapter, that interfaced the PC to a bus capable of driving up to 7 devices with a combined throughput of 5 Mbytes/sec.

Not far behind SCSI-1 came SCSI-2. This new standard removed some of the instructions from SCSI-1 and replaced them with an enhanced set of instructions as well as many low level enhancements. At this point, the concept of the "Wide" SCSI bus was introduced allowing for 16 and 32 bit data paths between the host adapter and the expanded array of now up to 15 devices. Along with the wide bus, the "Fast" SCSI allowed for bus speeds of up to 20 MBytes/sec using the 32 bit bus. The addition of active termination made for better data integrity.

The SCSI-2 standard was rounded off by the addition of Command Queuing. This feature allows up to 256 separate commands to be stored in the controller. The host adapter can then send several requests to the same device before it processes the first one. Command queuing is defined in SCSI at the device level. That is, each device will support command queuing only as far as the designers want to take it for that device and the maximum number of queued commands is optional for each device in the bus (4 is a very common number). At a different level, the host adapter can queue commands to be sent later when the device can accept new ones (also optional). In both levels of command queuing, one thing that advanced devices or controllers can do is "out of order" processing of queued commands, optimizing overall times by reducing head movements.

Ultra SCSI, although not a new standard, has nevertheless become the de facto state of the current art. Ultra SCSI is seen as a stepping stone between the current generation of parallel bus devices and the new proposed SCSI-3 standard designed to, among other thing, introduce a high speed serial SCSI protocol such as the Fibre Channel. In fact, SCSI-3 amounts to a sum of separate standards as defined by different interested parties. As a result, the direction of SCSI seems to be the breaking up of the standard into smaller packets designed to address various individual projects while keeping the efforts coordinated under the general umbrella of SCSI.

It is intended that this aspect of SCSI-3 will accelerate the development of future SCSI implementations. Another place SCSI-3 is hoping to go is the removal of the current 15 device limit imposed on wide SCSI. The plan is to offer a "2 phase" addressing system that sends the higher order selection bits in the first phase and then the final selection bits in a second addressing phase. As a result, up to 255 devices on a narrow SCSI bus or 1023 on a wide bus could be accessed.

The SCSI Standard

Because Ultra 2 SCSI is now the norm among SCSI systems, we will focus on its implementation for the balance of this discussion. Ultra 2 SCSI currently allows transfer speeds of up to 80 MBytes/sec over a 16 bit bus with 160 Mbytes/sec becoming popular on high-end systems. The new higher speeds available in Ultra SCSI are due in large part to improvements in the processing speeds of the controller's chips. Ultra SCSI calls for a doubling of internal clock speeds for the controller electronics and thus the data transfer cycle times are now much shorter. Add this to the quicker execution of SCSI commands and the throughput has become impressive, even for multiple-drive server implementations.

That's not even the best part. The best part is that in order to take advantage of these higher burst transfer rates, there need be no change in the operating system or the SCSI drivers that command the controller. From a system point of view, the enhanced throughput is free! In fact, there is little change needed in either hardware or firmware of the peripherals themselves to become Ultra 2 SCSI compliant. How this will pan out as SCSI reaches for the 160 Mbytes/sec grail is uncertain, almost surely requiring some sort of major change in the hardware. Still, the impact on the system designer is promised to be minimal.

There is a price to be paid for these higher data transfer speeds. That price is data integrity. In order to prevent the higher data speeds from being consumed by transfer retries, the SCSI cable must be kept to a length limit of 1.5 meters. This doesn't offer any real obstacle in the average PC implementation, including DAW implementations. The place where this really starts to hurt is in large server arrays, RAID arrays and video-on-demand systems. Under these conditions, it isn't convenient to cram 15 drives into a single tower. The use of outboard drive bays can often tax the cable length specification to the point of non-compliance.

In order to address this issue, a type of SCSI bus called "Low Voltage Differential" or LVD has been introduced. A differential bus provides a second set of data lines being driven with the opposite electrical polarity as the original lines. If a "one" bit is represented by +5 volts in the standard data line, that same "one" bit is echoed on the supplemental data line as -5 volts. Thus, there is a higher overall voltage swing to represent the data, there is redundancy in the transmission paths and any outside noise that might enter the lines will be canceled out at the receiving end. The result is a boost in cable lengths to 25 meters. Another feature being offered by the new generation of Adaptec Ultra160 LVD host adapters is both CRC (Cyclic Redundancy Checking) and Domain Validation which scans the system for proper configuration. These adapters limit cable length to 12 meters.

SCSI Implementation	Bus Width (bits)	Burst Speed (MB/sec)
SCSI-1	8	5
Fast SCSI	8	10
Fast Wide SCSI	16	20
Ultra SCSI	8	20
Wide Ultra SCSI	16	40
Ultra 2 SCSI LVD	8	40
Wide Ultra 2 SCSI LVD	16	80
Wide Ultra 3 SCSI LVD	16	160

Something to keep in mind before you run right out and snag an LVD drive: in the past, you could not mix normal SCSI and LVD SCSI drives on the same bus. You needed a host adapter that specifically supported LVD and unless you were ready to accept 2 SCSI adapters in your DAW or upgrade to an adapter that had both a normal and a LVD connector, you either had to dump all of your current SCSI devices and replace them with LVD devices, or close your jaw and not worry about that side of the cutting edge.

However, many modern SCSI LVD drives can be switched to run on a single-ended bus and some even auto-switch from single to LVD depending on how they sense the bus they're connected to. Before you buy, be sure of what you're getting. Many "super fast" SCSI drives are LVD and may not be switchable. Mixing the two bus formats can result in a lot of smoke and no SCSI!

Setting Up SCSI

There's really no point in installing a SCSI host adapter that is not:

1) A PCI card. Trying to get DAW performance from an ISA SCSI card is like trying to pull an elephant through a toilet seat. Don't bother!

2) Configured for bus mastering. Although it is possible to still buy a PIO-only SCSI adapter, and at not exactly a modest price either, don't even think about it. If you're going to be spending the extra money to go SCSI, do it right.

3) Ultra SCSI. There is no point in going all the way to the ocean with your bathing suit on and not jumping into the water. If you want to implement SCSI on your system, do so with an eye to the future. Besides, the entry level for an Ultra SCSI host adapter is no more than $80 or so with Ultra 2 Wide running about $180. Take a look at the price comparison charts on the COMPARING DRIVES page.

Perhaps if you are thinking of building a DAW from the ground up, the wise choice for implementing SCSI is to do it at the motherboard level. Several good motherboards support SCSI right on the board much the same way motherboards support IDE. Just plug your SCSI controller cable into the SCSI port on the motherboard and then run the other end to your drive(s).

Don't forget to terminate the cable at your last SCSI device. All signals on the bus must be terminated with resistors at the bus ends to avoid electrical reflections. This is achieved either by a switch on the device (not always present) or by placing an external terminator block on the connector of the first and last devices on the bus. Often, the first device will be the host adapter itself.

Installing the SCSI drivers is best left up to Windows, which will see the SCSI controller and set up the drivers for you through Plug And Play. SCSI adapters are either PIO, DMA, or bus mastering, and the user can't choose the mode. If you have a bus mastering SCSI adapter, the driver only works in bus mastering mode. SCSI configuration is somewhat more complex, as there are many configurable options such as disconnect strategy, SCAM, LUN, BIOS emulation, etc. All of this should be explained in the adapter installation guide.

It should be noted that some users have reported problems using some host adapters with some motherboards and chip sets. MVP3 and Aladdin V chipsets have fallen into question, although there seems to be no problem using a motherboard with the workhorse Intel BX chip set. There have also been comments made about some AGP cards being so power hungry that on some motherboards they rob the PCI bus of the needed juice to reliably run high-end host adapters. Not-so-high-end adapters may not complain about the chip set or video card's appetite.

Contents
	Introduction
	Other Factors
>>>	About SCSI
	About IDE
	Bus Mastering
	Bus Mastering and DMA
	UDMA Bus Mastering
	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 4

Fri, 01 Sep 2000 00:00:00 GMT

IDE, or more formally, IDE/ATA, is the most common system for connecting a hard drive to a PC.

In modern systems (to which this discussion is limited), they plug directly into the motherboard through a 40 pin cable. Most motherboards offer 2 separate IDE channels and thus 2 connectors on the board. Each connector can support 2 IDE devices, be they disk drives, CD drives, tape drives, removable drives and so on. If a channel has 2 devices on it, one must be designated a master and the other a slave. This is done simply by moving or removing a jumper on the drive itself.

As a result of this configuration, any system can have 4 IDE devices connected to it. Using an external controller board connected to the PCI bus supporting 2 additional channels, up to 8 devices and be supported on a PC. This is the limit, and attempting to add 4 more devices with an extra controller will consume more interrupts and other system resources. This contrasts with modern SCSI which can have up to 15 devices on a controller and occupies the same amount of system resources regardless of the number of devices connected up to that limit.

The History of IDE

IDE replaces older interfaces such as ST-506 and ESDI. Through the years, many changes have been made to the IDE standard as defined by ANSI.

The original standard, call simply ATA called for 2 devices on the same channel configured as master and slave. It also defined PIO modes 0, 1 and 2 and DMA single word modes 0, 1 and 2 and multiword mode 0. However, this standard had problems. Often drives by different manufacturers wouldn't work if combined on a single channel as master and slave. ATA-2 added the faster PIO modes 3 and 4 (mode 4 being the common default PIO mode for modern PCs), faster DMA multiword modes 1 and 2, the ability to do block mode transfers, Logical Block Addressing or LBA, and improved support for the "identify drive" command that allows the system to interrogate the drive for manufacturer, model and geometry.

The terms "Fast ATA and Fast ATA-2" are the inventions of Seagate and Quantum. They are not really standards and only denote drives that are compliant to all or part of the ATA-2 standard. ATA-3, however, was a real standard that improved reliability and defined the SMART feature in disk drives. It was followed by the current Ultra ATA or UATA. UATA also goes by many other names like UDMA, DMA-33/66 and ATA-33/66.

UATA isn't really a new standard, and UATA drives are still backward compatible with ATA and ATA-2 systems. Ultra ATA is the term given to drives that support the new DMA modes that provide up to 33 MB/s (UDAM-33) or up to 66 MB/s (UDMA-66) transfer rates with 100 MB/s just over the next hill. Both UDMA versions support CRC error checking that assures data integrity through the IDE cable, which was a source of serious problems in previous standards. Note that the UDMA-66 standard calls for an 80 conductor cable instead of the 40 conductor cable used up to and through UDMA-33.

EIDE or Enhanced IDE is a designation created by Western Digital to describe its newer line of high speed drives. It really isn't a standard at all, but just a marketing tool. However, it has taken on common public use to refer to all high speed drives and the systems that support them.

Contents
	Introduction
	Other Factors
	About SCSI
>>>	About IDE
	Bus Mastering
	Bus Mastering and DMA
	UDMA Bus Mastering
	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 5

Fri, 01 Sep 2000 00:00:00 GMT

By default, IDE disk drives transfer data to and from the system using a protocol called "Programmed Input/Output" or PIO. This technique requires the CPU to get into the middle of things by executing commands that shuffle the data to or from RAM and the drive. Thus, the CPU is tied up doing the work of fetching and stuffing. Also, the time overhead involved in putting data in the cache, reading each byte into the CPU, sending it out to the cache again and then routing it to its destination puts a top end to the speed of the transfers.

In typical desktop systems this isn't much of a problem. The system doesn't have much to do during these transfers anyway, so who cares? Even if a user has several applications open at once, seldom is more than one actually doing anything, and during disk I/O, the application will likely be idle anyhow.

Now suppose you have an activity known as "streaming" going on which is pulling lots of data from the drive in real time while the application doing the streaming is simultaneously attempting to process the data as it arrives. Wow! Now we have a problem. The CPU really does have lots to do while data is being transferred and so getting tied up actually DOING the transfers cuts into application processing time.

In all fairness, even at the fastest rate, a disk drive couldn't pump enough data to or from memory fast enough to cause modern high speed CPUs to break into a sweat. Even at this high demand level, there is time to shuffle data, process that data, shuffle it back, service interrupts, update the screen, send a byte to the modem, and so on.

Enter the DAW

Now we have a whole new ball game. Not only is the digital audio application trying to stream data and process in real time, but it needs to stream multiple files for multi-track mixing at the same time and still supply CPU horsepower to real time effects like reverbs and compressors. This forces a limit on the number of tracks in the mix and the number of real time effects that the project can sustain when attempting to perform real time production.

Under this load, even a Pentium 500 will fall short of the goal if it has to worry with PIO along with all of this other processing. If you want to mix more than 6 or 7 tracks using more than a few parametric EQs and one reverb, you will need to free up some major CPU cycles!

The answer is to put the load of data I/O someplace else so the CPU can just go to RAM and expect to find the data already there and process it. This is the idea behind DMA or Direct Memory Access. Using DMA, a system splits the responsibility of data communication among several intelligent sub-systems so each can do a specialized job very well.

DMA may seem like a new idea, but actually it has been around since before the first PC was ever designed. In the PC, sound cards, floppy drives and even SCSI controllers have been using DMA on the ISA bus for a long time. This method requires the ISA chip to referee the DMA transfers between the devices and RAM and thus is called "third party" DMA.

However, the ISA bus is slow. This doesn't bother low-throughput devices like the floppy drive and simple sound cards, but to make DMA effective for high speed disk drives, the ISA bus is useless. The world had to wait for the development of the "local bus" to get the job done. This local bus technology is being implemented today on newer motherboards by the PCI bus.

With PCI, third party DMA is fast enough to become a useful disk access alternative to PIO. Another ability of the PCI bus is the ability for a device connected to it to take control of the bus and perform the transfers without the use of a DMA controller chip. This is referred to as "first party" DMA or more commonly, bus mastering. Using bus mastering, the peripheral device can access system memory the same way as the CPU itself.

Just about everything on the PCI bus (and its offshoot, the AGP connector) can use bus mastering if the designers wish it to. This includes Ethernet controllers, sound cards, Win-modems, display adapters, and so on, although due to little demand for high speed data transfer by these adapters, most of them still stick to PIO. It's important to understand that disk controllers are the bus the master devices on the PCI bus, not the drives themselves. However, for most disk controllers to be operated in bus master mode, they require that the drives themselves at least support multiword DMA mode 2 so the data handshaking controls can be implemented between the drive and the bus mastering controller.

Bus mastering, being an advanced form of DMA, demands very specific motherboard chip set support as well as specific support from the hardware attempting to use it. The operating system must also be able to support it by loading special "bus mastering aware" drivers. This may sound rather complicated, and it is. However, the gain in data transfer speeds and CPU overhead reduction associated with bus mastering is such that there is no way modern digital audio applications could perform acceptably without it.

Luckily, Intel and Windows support it on the board and in the system and most if not all SCSI and IDE controllers can operate using it. Don't think that these manufacturers went through all of this trouble just for us musicians. Be assured, they didn't. This improvement was to facilitate network server applications. However, we can also reap the benefits of this technology.

A Shaky Start

Most all modern SCSI controllers connect to the PCI bus and use bus mastering. This has been SCSI's largest advantage in terms of DAW performance, but that all changed with the advent of IDE's entry into PCI bus mastering. For the record though, from this point on, we will limit the definition of PCI bus mastering to a system whereby the IDE controller transfers data to and from the drive using an enhanced DMA protocol. It is usually referred to as Ultra DMA (or DMA-33/66) or Ultra ATA (UATA or ATA33/66).

In the past, there were a lot of problems getting this to work. The Intel drivers shipped with many motherboards were "behind the curve" in terms of functionality when compared to the Intel drivers installed with Windows. Also, Windows 95 didn't start off supporting bus mastering. Upgrading to 95B was necessary to provide this feature. The same goes for NT4. Service Pack 3 must be installed to provide bus mastering. Many people were tempted, not knowing any better, to install the drivers shipped with the motherboard during setup because, well, they were shipped with the motherboard! It seemed the thing to do.

Unfortunately, these drivers gave poor performance, and sometimes none at all. Even after discovering the mistake and attempting to remove them from Windows, they wouldn't de-install cleanly. This left no alternative but to wipe the drive and re-install Windows and all of the software that came after it. Not fun! As it turns out, just using the native Windows drivers seems the way to go.

There was some early confusion as to which drives would or would not work under bus mastering. In that there are currently 2 types of Ultra DMA in common use, UDMA-33 and UDMA-66, one needs to check the specs. With UDMA-33, this isn't much of an issue any more as almost any disk drive manufactured in the past 2 years is capable of multiword DMA mode 2 or better transfers and thus will run under bus mastering. The same can be said for current motherboards. Most using the Intel 430 FX, HX, VX, TX or 440 FX, LX, EX, BX, GX Pentium chip set will support bus mastering as well as those using the VIA chip set. Naturally, the Intel 810, 820 and 840 chip sets support bus mastering, but this chip set family is plagued with problems in the memory department and so at this point, a DAW using a motherboard with either of these three chip sets is a dicey matter.

Make sure that both the motherboard and disk drive support the newer UDMA-66 if you want this higher performance transfer feature. UDMA-33 will use the same IDE cable between the drive and motherboard as the older PIO system, so if you currently have a newer drive and motherboard but don't use bus mastering, usually all you need to do is go to Windows and switch it on. As mentioned above, UDMA-66 uses a different cable and chip set, so you must make some real effort to upgrade to UDMA-66 from PIO or UDMA-33 even if the drive supports it. If your current motherboard isn't UDMA-66 capable, you can get a separate IDE controller board designed for UDMA-66 which plugs into your PCI bus to get UDMA-66 up and running on your current system.

What is the big deal with the new cable, you ask? As it turns out, the cable is 80 conductor instead of the usual 40 conductor. Both ends still have 40 pin connectors. Huh? Here's the deal. The extra 40 wires are grounds and lie in between the other 40 signal lines acting as shielding. This reduces crosstalk on the lines and enhances reliability. UDMA-66 drives will not function at 66 MB/s without this 80 conductor cable, and will default back down to 33 MB/s if they sense a 40 conductor cable. On the other hand, using an 80 conductor cable on a UDMA-33 drive will likely enhance its performance too, due to the more reliable connection and thus fewer transfer retries.

As one example of the kinds of things that can go wrong, this is an experience Glen, one of this article's authors, had setting up his new DAW.

When I set up my first DAW system 2 years ago, I picked up one of the new Western Digital 13 gig drives and tried to set it up for bus mastering. When I tried, the stupid thing kept defaulting to DOS mode! Nothing I did helped until a friend suggested I poke around on the WD web site for clues.

I hunted for quite some time until I came across an obscure reference to the fact that all of these new drives were being shipped enabled for UDMA-66 by default. If a user wanted to use UDMA-33 instead, they needed to download this little program that will talk to the drive and tell it to switch modes. Fancy that! I downloaded and ran the utility. Within a few moments I had bus mastering running and a benchmark reading of 3.53% CPU usage for streaming transfers and an estimated track count of over 80 tracks of digital audio.

I understand that these drives are no longer being shipped with UDMA-66 as the default. I wonder if my letter had anything to do with that!

To make things a bit more livable, almost all UDMA-66 drives made today will auto-switch between 33 and 66 depending on the abilities of the controller and the cable. Incidents like the one described above are now, hopefully, a thing of the past. After all, drive manufacturers WANT you to buy these new drives regardless of whether or not you can use the enhanced throughput. This way, they only need to make one type of interface for their drives. Again, this isn't to make our lives easier, but theirs.

That Voodoo That You Do

Another example of things that go "bump in the night" is from a series of posts on the PC-DAW news group where a fellow tried to enable bus mastering in NT4 only to be told by the Microsoft utility he was running that there were no such drives in his system. Between convincing his system that he has the authority to hack the registry and finding drivers that would work, he got it set up but still an air of mystery hangs over his system because it simply didn't follow the rules during set-up.

When you have to resort to shaking chicken bones over the tower and smoking chunks of cactus to make things work, you know you're dealing with Windows.

A drawback to using Bus Mastering and CD ROMs is that if you put a CD drive on a bus mastering channel, you must be sure it is Ultra DMA compatible. This is a good reason to never put a hard disk from which you will be streaming data and a CD drive (player or recorder) on the same IDE channel unless you are sure the CD player is Ultra DMA compatible.

Contents
	Introduction
	Other Factors
	About SCSI
	About IDE
>>>	Bus Mastering
	Bus Mastering and DMA
	UDMA Bus Mastering
	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 6

Fri, 01 Sep 2000 00:00:00 GMT

What is the difference between regular DMA and bus mastering?

Plenty!

Bus Mastering Logistics

First, let's look at bus mastering again but from a DMA point of view. A bus is a data transport. Bus mastering is a very advanced means of transporting data to and from devices and/or memory using the PCI bus as a conduit.

A device that issues read and write operations to memory and/or I/O slave devices is considered the master, although a master device can have slave memory and/or I/O ports available to be accessed by other masters. For example, an Ethernet controller must convey data it receives from over the LAN and must also access data to send over the LAN as a bus master, but acts as a slave when the CPU, acting as a master, programs it to initialize and to specify where it must get and put data.

Only one bus master can own, or "drive" the bus at a given instant, and the bus is responsible for arbitrating bus master requests from the various bus master devices. A bus master device will request access to the bus, which is granted immediately providing no other master has it at the moment. If another master device has been granted access, the new one must wait until the first one completes its single or burst transfer, or the bus arbiter times out and yanks the access away in favor of the new requesting master, whichever happens first.

If an operation is interrupted by a timeout, it is resumed when that issuing master receives its turn again. The CPU is a bus master device, and is always present. The Intel PIIX family of IDE controllers found in all modern Intel chipsets for the x86 family are bus master devices. The SoundBlaster Live! is a bus master device that accesses main memory through the bus to read samples. There are many peripherals which use bus mastering on the PCI bus to free the CPU from actually doing every transfer, for example, video cards, network cards, SCSI controllers, other storage devices, and so on. Note that bus mastering transfers do not require and therefore do not tie up the DMA channels like normal DMA devices do.

DMA Logistics

Normal DMA is controlled by a chip. The DMA chip itself is a bus master device. It can be programmed by the CPU to perform transfers from memory to I/O, or I/O to memory (some also allow memory to memory, but is not in the case with the PC, although two DMA channels can be used to do that given some fancy driver footwork). Therefore, the DMA system acts as a bus master to perform the programmed operation while the CPU can be doing something else. The DMA controller sends a signal to the CPU when the transfer is complete.

DMA is used to perform transfers without CPU intervention to or from peripherals that don't have bus master capabilities. DMA issues accesses similar to standard bus I/O accesses, but with the addition of handshaking lines DMA_Request and DMA_Acknowledge. These signals are present on the bus for each DMA channel. A slave device must handle these handshaking lines to be able to be operated through DMA. Obviously, this is a much simpler system than having to support all the complex and necessary logic in a bus master device.

The main limitations of a DMA capable slave compared with a bus master peripheral, are:

1) The DMA slave is passive. It is the CPU which must specify the transfers to be done. The bus master device can perform transfers by its own initiative without restrictions.

2) DMA can only transfer blocks of contiguous memory content, and only one block for each programmed transaction. The bus masters can access memory or I/O following any pattern without restriction.

3) In the case of the PC, the DMA device can only transfer blocks of up to 64 KBytes, and always on 64 KByte boundaries, which limits its utility. In older PCs, the DMA system could only access the first megabyte of memory. Later it was extended to the first 16 megabytes and currently the DMA device can more often access all memory, but always within 64 KByte boundaries for each operation.

4) DMA is generally slower, although there are new faster modes and burst timing modes achieving considerable throughputs. These modes must be specifically supported by the slaves in order to used them. The original Intel 8237 DMA controller was extremely slow. So slow that disk transfers were more efficiently done by the CPU using PIO mode 4 because DMA would become the bottleneck. In the best theoretical case (that was never meet) it could only transfer 4 MB/s. The reality was more like 1 MB/s.

Contents
	Introduction
	Other Factors
	About SCSI
	About IDE
	Bus Mastering
>>>	Bus Mastering and DMA
	UDMA Bus Mastering
	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 7

Fri, 01 Sep 2000 00:00:00 GMT

So how do you get this so-called Bus Mastering to work anyhow?

First, let's make sure your ducks are in a row. You must have the following squared away:

1)

A motherboard with the proper chip set for bus mastering. The 430 FX, HX, VX, TX and 440 FX, LX, EX, BX, GX chipsets from Intel will support UDMA bus mastering as well as the VIA chip set and some other competing chip sets.

2)

A disk drive that is Ultra DMA compliant. Most new drives are.

3)

Windows 98, Windows 95 OSR2 or above, or Windows NT with service pack 3 (at least!) installed.

How can you tell if you have this condition met? If you have Windows 98 installed, you're ready to rock. If you are running Windows NT and don't know if you have service pack 3 installed, then you aren't the one to be messing with NT and you need to call in whoever it is that normally administers your system. If that's you and you still don't know what I'm talking about, sell your system and buy a Windows 98 system. You'll be better off. Otherwise, NT users please skip ahead to section 6) below. Windows 2000 users can skip to step 7).

For those of you still running Windows 95, open Control Panel and double click on the SYSTEM icon. You will see a box with the Windows logo and a heading "System" beside it. The system will shows "Microsoft Windows 95" on one line. If you see "4.00.950b" or "4.00.950c" on the second line, you're good to go. If you see "4.00.950" or "4.00.950a" on the second line, then you should upgrade to OSR2 or OSR 2.5 or Windows 98. If you're stubborn, you can also download the Intel bus master driver for your version of Windows 95 from Intel at:

http://developer.intel.com/design/chipsets/drivers/busmastr/index.htm

However, there's a catch! If you install this driver and later upgrade to Windows 98, you MUST un-install this driver prior to the upgrade. This driver was never meant for Windows 98 and your system will likely go nuts if you leave this driver in place. If the driver is already on your system and you are going to upgrade to Windows 98, you can download the driver install program and use it to un-install the driver first, then do the upgrade.

4)

Now you need to see if Windows has properly identified your motherboard chip set. You may need to run the Windows 95/98 INF Update utility. To see if you do, you must first know the chip set on your motherboard. Get out the book that came with it and see what it says. Next, open CONTROL PANEL and double click on the SYSTEM icon to get the box with your system version number. Now look at the following chart to see of you need to even go any further with this process.

	Operating System
Chip Set	4.00.950	4.00.950a	4.00.950b	4.00.950c	4.10.19998
430FX	NO	NO	NO	NO	NO
430VX	YES	YES	NO	NO	NO
430HX	YES	YES	NO	NO	NO
440FX	YES	YES	YES	YES	NO
430TX	YES	YES	YES	YES	NO
440LX/BX/EX	YES	YES	YES	YES	NO
440GX	YES	YES	YES	YES	YES

Table taken from Intel document "Troubleshooting Common System Configuration Issues"

If you fall into a NO category, then skip to part 5) below. If you got a YES, again open CONTROL PANEL and double click on the SYSTEM icon. With the System box open, click the Device Manager tab and make sure the "View Devices by Type" button is checked. Click on the "+" box next to "Hard disk controllers". If you see a list of controllers like this:

Primary IDE Controller (single FIFO)

Standard Dual PCI IDE Controller

Standard IDE/EIDE Controller

and that's it, well, you need to run this utility. You can get it from:

http://developer.intel.com/design/software/drivers/platform/440.htm

Be sure to read everything there including the README text to make sure you know what's going on.

5)

Open CONTROL PANEL and double click on the SYSTEM icon. Select the Device Manager tab and then click on the "+" box next to "Disk Drives" to expand the list of hard drives on your system. Double click on the first IDE disk entry in the list. You will get a new control box related to that drive. Click on the "Settings" tab. You should see a check box labeled "DMA" in the center of the right side. If this box is grayed out, you have some troubleshooting to do. If it's not grayed out, check the box and then click OK at the bottom. Now double click on the next IDE entry if you have more than one IDE drive. Do the same thing for this one and any other ones you have. Click on the "+" box for your CD ROM also and follow the same procedure. If your CD ROM is UDMA compliant, you will have a DMA check box for it (them) as well. Check these boxes also. Now all of your drives will be running bus mastering once you reboot.

6)

To activate bus mastering on Windows NT, you must run a utility called DMACHECK.EXE in the support\utils\i386 directory. If it's not there, download it from:

http://support.microsoft.com/support/kb/articles/Q191/7/74.asp

Run DMACHECK and it will show you if DMA is enabled on either IDE channel. If not, click on the ENABLE radio button for all of the DMA compatible devices on your system that you wish to activate. This should be all of your hard drives and any CD ROM drives too. Any other listed devices, well, that's up to you. After the selections are made, reboot and run the program again. It should tell you that all of the devices you selected are now enabled for DMA protocol. If this operation failed, there's some good advice from the web. Go to:

http://www.arstechnica.com/tweak/nt/udma.html

Be prepared to do some registry hacking! It may come to that. At least this document will give you a fighting chance, so check it out even if you don't think anything went wrong. You may have been fooled by DMACHECK!

Users of Windows 2000 have an easy time of it. Bus mastering is installed and activated by default so you need do nothing to use it.

7)

Now it's time to run a benchmark test that will focus on your system's performance under DAW conditions. José has written a benchmark test that accurately simulates multi-track digital audio streaming called DSKBENCH.EXE which can be downloaded here on ProRec.

This program is run from a DOS shell and will report record and play throughput in MB/sec as well as an estimated number of 16-bit 44.1KHz audio tracks you might expect to be able to stream simultaneously with that drive under real conditions. For details on using that benchmark, continue to the section DAW Disk Benchmark.

Contents
	Introduction
	Other Factors
	About SCSI
	About IDE
	Bus Mastering
	Bus Mastering and DMA
>>>	UDMA Bus Mastering
	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 8

Fri, 01 Sep 2000 00:00:00 GMT

When it comes to picking a drive for a DAW, you have a bit of a job ahead of you.

We looked at the two contending controller formats in the last sections, but that's just an overview. What about the specifications? What do you need to know about a drive's performance in order to make an intelligent choice regardless of which format you're interested in?

As it turns out, the specifications of both the drives and the controllers can lead you quite clearly to the best choice so long as you don't lose track of what you're after. You want a disk for a DAW - not a file server - so many of the drive specs and controller advantages don't apply and others will count more heavily. On the other hand, you're not just going to be typing email or surfing the net on this system either, so not "just any old drive" will do.

Decision Criteria

To an extent, the drive format you have already committed to will be a big factor. If you don't want to support a large number of drives and CD devices, IDE will look like the best path to follow and SCSI will be much less appealing. If you already have SCSI, then the choice is clear.

If you are building from scratch, you should at this point have a good idea what CPU you would like to run, how much RAM you will need, what you feel is right as far as video, sound, and perhaps LAN cards go, and if you want an internal modem. Your choice of motherboards and disk system are now at issue.

Should you spring for SCSI and should you get a motherboard with built-in SCSI support?

Is IDE the best way to go?

Does it really matter?

We can't answer these questions for you, but we will give you better tools for reaching that decision yourself with less dependence on the common DAW disk superstitions, misconceptions and other people's unfounded prejudice.

Care and Maintenance is Still Important

Just for the record, no amount of care in picking a drive will offer you advantage if you don't do a few simple optimizing steps on your own.

For one thing, defragment your data partitions often. Keeping large file access sequential will allow your drive's performance qualities to shine. Also, store your data in the front tracks of the drive (first partition) or as close to the front as you can. As the track numbers get higher and the tracks get closer to the spindle, the "zoned formatting" of your drive will result in fewer sectors per track as you move toward the spindle. The more data you can pull from a single track, the faster the throughput. The outer tracks with the higher sector count will hold more data, thus offering up to 60% faster read/write throughput compared to the inner tracks.

For another thing, if you are using FAT16 partitions for your system, consider reformatting the data partition as a FAT 32 drive with the /z:64 switch. Assuming you've already fdisk'ed the drive as a FAT32 device, the proper format command is:

format d: /z:64

to format the d: drive. Replace the d: with the drive letter you wish to format. FAT32 with the /z:64 switch will remove the 2.1 gig partition limit while still giving you the large cluster sizes. Note that Windows NT cannot use FAT32 formatting, and NTFS uses small cluster sizes. Therefore, under Windows NT you need to format your audio disks as FAT16 disks or suffer a modest performance hit from NTFS.

However, Windows 2000 (NT 5 by another name) users need not suffer the constraints of NTFS because W2000 supports FAT 32. Keep in mind that if you're already a W2000 user and have already formatted all of your drives to NTFS, Windows cannot "un-do" an NTFS format back to FAT. You're stuck with it unless you're willing to either FDISK your audio data partition and reformat it or use a third party program like Partition Magic to make the switch.

That said, let's look at the guts of a hard drive.

Contents
	Introduction
	Other Factors
	About SCSI
	About IDE
	Bus Mastering
	Bus Mastering and DMA
	UDMA Bus Mastering
>>>	Comparing Drives
	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary

SCSI vs. IDE pt. 9

Fri, 01 Sep 2000 00:00:00 GMT

In comparing IDE and SCSI it is important to understand that both types of drive are, from a "between the shells" point of view, the same.

Inside the Drive

Hard disks have a sealed case with one or more platters of magnetically coated media, a small synchronous motor designed to rotate the platters at a precise speed, and an actuator with one or more arms attached, each with a read/write head at the tip. The platters hold the data in the form of concentric tracks, each split like a pie into many sectors. Each sector will hold 512 bytes of user data as well as error correction information and other alignment information.

The actuator is designed like a speaker voice coil, extending or retracting along its throw path depending on the strength of an electrical signal in the coil which will force it very precisely to any location. The arms attached to the actuator are thereby positioned to various places above the spinning platters where the heads can pick up or lay down streams of magnetic information.

The heads float on a cushion of air at a distance of about 10 microns above the platter surface. The platter's rotation produces that cushion of air. In contrast, a particle of smoke is about 100 microns in size, or 10 times the head gap. For this reason, these drives are manufactured in very closely controlled "clean room" conditions, are sealed at the factory against any interaction with the outside environment and sold with the expressed condition that the user never, for any reason, open the drive casing.

The drive also has a circuit board to control the mechanism and coordinate the transfer of data to and from the platters in a specific format. Aside from the data and power connectors, that's about the whole story. It stands to reason, therefore, that the physical properties of these moving parts hold the key to a drive's access speed and data throughput.

In reality, this is more the case than is commonly believed, and for that matter, commonly disclosed by the drive manufacturers. So many drives are advertised with little more than their data storage capacity and interface burst transfer speed. Neither of these factors relates directly to a drive's usability as a DAW storage system. To get the real story, you must dig into the drive specifications, usually available only on the maker's web site and even then only after linking past several pages of ad hype and chest pounding.

The drive actually performs two distinct operations in order to read or write data, those being head positioning and data transfer. Let's start with head positioning. To perform this act, the drive must:

1) receive a request to position the heads to a specific location on the platter.

2) select the proper head to access the requested platter.

3) wait for the requested sector on the track to rotate into position for access.

All of this positioning and the buffering of the data to be written or that is finally read must be controlled by the drive electronics. Although the electronics is quite fast by all accounts, there is still a certain amount of overhead associated with this activity. It is referred to as... you guessed it, Controller Overhead. Sometimes this spec will be listed for the drive and is usually the same over a given product line or at least a given model range. It is expressed in milliseconds (thousands of a second), or "mSec".

Understanding the Specs

The act of locating and positioning to a specific track is called "seek" and is likewise measured in mSec. It can come in three flavors. A seek can cause the heads to ramp from one end of the drive, say the outer most track, to the other end, the inner most track or vice versa. Obviously, this end-to-end movement represents the worst case as far as seek time. It is specified as the "full stroke" seek time. Another case is the head having to move only one track over, most common in reading data from a large file that extends from one track to another. This is called "track-to-track" seek time and represents the best case. The last is a measure of the average time required to perform a series of random seeks to various tracks and is referred to as "average" seek time.

Here is another factor, but one that is seldom specified. Given that the heads are at the end of long arms that are being swung along an arc by the actuator, and considering that the track being hunted is very narrow and separated from the adjacent tracks by fractions of microns, once the actuator has stopped, the head will require a finite amount of time to stop jiggling around and hover precisely over the target track. This time is called "settling" time. If you look at a drive's track-to-track seek time and then its full stroke seek time, it will be obvious that it takes a long time for a head to move just to the next track as compared to the head moving across a thousand tracks. In other words, it doesn't take a thousand times longer to move the head across a thousand tracks. This is because a good portion of that seek time is really settling time and is determined by a pre-programmed delay in the drive electronics.

Once the seek has taken place, the drive must wait for the target sector to rotate into position under the head. This delay is called "Rotational Latency", and "average latency" is given to be one half the time it takes the platter to make one full rotation. It will be the same for all drives running at the same rotation speed. There isn't much you can do about it. However, the faster the rotation speed of a drive, the less time it takes the target sector to rotate into position. Faster is better.

It is important to note that drives are formatted with what is called "track skewing" where by the sectors of adjacent tracks are not laid out next to each other, but are offset along the arc of the track. It's designed so as to be more likely that the next sequential sector in a read or write operation will be ready to rotate under the head after the amount of time it takes the head to move to the next track has elapsed. Because the rotational latency number is specified for new, random accesses, we can't speak properly of the latency spec as it simply doesn't apply to the sequential access case.

As the drive reads a large file that extends beyond the capacity of a single track, the drive will switch heads to the same numbered track of the next platter to continue reading or writing. This wastes less time than doing a track-to-track seek after filling every track. In technical terms, all tracks of the same number on all sides of all platters is referred to as a single "cylinder".

Therefore, if a drive has 4 platters making for a total of 8 "heads" or sides of platters and each side has 1400 tracks, then the entire drive has 1400 cylinders and each cylinder is then made up of 8 tracks that all line up under each other. The more platters there are in a drive, the more often the heads will be switched from platter to platter during a long read or write, exactly the sort of thing that will happen in a DAW. The heads are switched electronically and thus are not subject to mechanical delays except for rotational latency, and track skewing helps here too.

You might think that the more platters, the better. In rough terms, yes.

However, it is even better if each platter is so large that a track has many more sectors and thus will hold more data before the heads need to be switched or sent seeking the next track. Therefore, the important spec in this area is lowest number of heads for the same amount of storage space. Drives with higher capacity platters are the clear winners here. This spec is sometimes given as the "areal density" or the number of bits per square inch that the magnetic material can hold. Even if this number is not given, you can make a good guess by taking the storage capacity of a drive and dividing by the number of heads in the drive (that is, the number of PHYSICAL heads, not the number reported by DOS). If you compare this figure among drives, you will have a good guide even if areal density isn't listed.

Now let us review and prioritize:

1) In DAW streaming access, we must read or write small chunks of data for each audio track, and so random seeks are the majority. The average track seek time holds a lot of weight, although it will be reduced if all data accessed is inside a relatively small part of the disk. The lower this average seek time, the better.

2) The higher the areal density, the more data will be throughput before the head will have to switch platters or move to another track. Therefore, the higher the capacity-to-head ratio, the better.

3) Finally, rotation speed is a big factor in increasing throughput. If other factors are held constant, the faster a drive can spin, the better.

Contents
	Introduction
	Other Factors
	About SCSI
	About IDE
	Bus Mastering
	Bus Mastering and DMA
	UDMA Bus Mastering
	Comparing Drives
>>>	Media Access Speed
	Drive Specifications
	Interpreting the Specifications
	Interface Access Speed
	Comparing Cost
	DAW Considerations
	DAW Benchmarking
	CPU Bottlenecking
	Conclusions
	References and Glossary