Page 17
(Part 5)
SCSI vs. IDE Bus Mastering for DAWs, Part 5
by D. Glen Cardenas and Jose M. Catena
Cont. from Page 16; Back to TOC

  DAW Considerations

We just want to start out this section by quoting a few lines from some of the documents encountered while researching this article.

"For most people, IDE bus mastering is not worth the effort and problems, and I now do not bother with it on new installs of Windows 95. This may be somewhat controversial, but in my opinion it is overrated as a potential system improvement, given how much effort it requires."
Charles M. Kozierok - "The PC Guide"

"Now SCSI, the traditional I/O powerhouse, is facing challenges from the recently released Ultra DMA interface standard. Yet, benchmark tests on Ultra DMA drives show limited performance improvements over previous generation ATA drives."
Thomas W. Martin and Andy Scholl - "SCSI Remains the I/O Interface of Choice for Workstations: An analysis comparing SCSI and Ultra DMA"

"The conventional wisdom held that...SCSI disks would pull ahead thanks to features like command-tag queuing...Yet our most recent round of tests showed that SCSI and EIDE disks performed almost identically in a variety of desktop environments, even in multitasking scenarios and even with multiple hard disks installed - precisely the kind of situation in which we'd expect SCSI to shine."
Nick Stam - PC Magazine On Line - PC Labs On Line

"We've done a fair amount of performance profiling lately and to our surprise, we found SCSI drives to be very "bursty" as compared to EIDE/ATA drives. This means that there are higher system latencies when the SCSI controller and it's device driver grab the processor and bus. As a real-world example, with one particular system we have audio performance latencies of about 40 ms with an EIDE drive and with the same system, a SCSI drive required much larger audio buffers, about 160 ms latency, to avoid dropouts."
Rob Ranck, Gadget Labs, Inc. - Taken from the Cakewalk Audio news group.

These comments need to be put a bit into perspective. The first comment by Mr. Kozierok may be a bit dated. After all, when Windows 95 came out, it didn't support bus mastering at all. One needed to hunt down the driver and install it. Sometimes it wouldn't work. Sometimes the drive or chip set simply wasn't up to the challenge. After OSR2, Windows 95 installed the proper drivers by default most of the time, but sometimes Windows wouldn't see the Intel chip set and so wouldn't install them. NT4 was a bit of a problem too, but all of these service packs (what are they up to now - SP5 is it?) makes keeping up with NT a bit of a zoo anyhow, and there is no "DMA check box" in NT. You must run a utility to enable UDMA and sometimes even that falls short leading to direct hacking of the registry. With Windows 98, it's been reduced to simply going to the drive dialog under Device Manager and clicking on the DMA check box and rebooting. That's about it. Windows 2000 is even simpler. Just install Windows and start tracking.

As for the comments from Mr. Martin and Mr. Scholl, well, first remember that this paper was for the SCSI Trade Association so how objective can you expect them to be. Second, they made their tests using 10,000 RPM SCSI drives against IDE drives of unknown rotation speed, likely 5400 given the numbers they reported. It seems strangely conspicuous that they specifically listed the RPM rates of the SCSI drives in their tests but made no mention of the IDE drives. In a test of "one" SCSI drive against "one" IDE drive both simply streaming data, there should be little difference if the rotational speeds and access figures are equivalent for both drives. If you want to compare just the interface, the drives must have the same guts in order to apply any meaning to the results. This was clearly not the case here.

This brings us to the comments by Mr. Stam with PC Magazine and the post by Mr. Ranck of Gadget Labs. After careful review of the data at hand, it seems clear that for the specific function of a DAW, which is unique as compared to a server on one end and a desktop workstation on the other end, there is little advantage to using SCSI, and perhaps even a bit of a disadvantage. This goes against conventional wisdom to such an extent that if it were not for the facts as we have been collected them, we too might have thought differently. When it comes to "raw" track count per dollar, some systems might do better with SCSI, particularly if they go with 10,000 RPM drives and will be using more than 4 drives and/or a CD ROM. Others might do better with EIDE, especially in systems using only one or two drives and taking CD data from a remote (LAN linked) system. For those in between, it's a toss-up!

DAW Disk Benchmark
There may be a lot of disk performance benchmark tests out there, but the only one that seems to pin-point drive performance as it relates to the DAW is DSKBENCH written by this article's co-author, José Catena. It is available for downloading from the SESA Inc. web site at http://www.sesa.es by clicking on the DOWNLOADS link in the left hand frame. Unzip the package, read the docs and then move the EXE file to your WINDOWS directory or in some other directory that is in your DOS PATH. To use it, open a DOS window and at the prompt, log on to the drive you wish to test. At the next prompt, type DSKBENCH and the program will start to run. If you wish to make a record of the resulting analysis, add the ">" redirect command at the end and send the output to a text file of your choice, such as this:

DSKBENCH > C:\TEMP\RESULTS.TXT

You don't need to use upper case type. It is used here to make it easier to read. In the above example, the program will run without printing anything to your display, but will instead write everything to a text file called RESULTS.TXT that will be created in your C:\TEMP folder. You can send it to any folder you wish, of course.

Here is an example of what you will get by running this program:

DskBench 2.11
(c) 1998, SESA, J.M.Catena (admin@sesa.es, www.sesa.es)
Timer Check = 990 (should be near 1000)
CPU Check = 50.40 % (should be near 50.00 %)
CPU index (relative to Pro 200 MHz) = 0.900380
Open = 4 ms
Write = 43105 ms, 5.94 MB/s, CPU = 7.88 %
Flush = 283 ms
Rewin = 0 ms
Read = 39995 ms, 6.40 MB/s, CPU = 5.31 %
Close = 193 ms
BlockSize = 131072, MB/s = 4.45, Tracks = 52.94, CPU = 6.06 %
BlockSize = 65536, MB/s = 3.18, Tracks = 37.85, CPU = 3.74 %
BlockSize = 32768, MB/s = 2.00, Tracks = 23.73, CPU = 3.67 %
BlockSize = 16384, MB/s = 1.10, Tracks = 13.10, CPU = 3.47 %
BlockSize = 8192, MB/s = 0.58, Tracks = 6.87, CPU = 3.40 %
BlockSize = 4096, MB/s = 0.30, Tracks = 3.53, CPU = 3.51 %


Go to Page 18 (Part 5); Back to TOC