The first part of the readout is just to make sure there isn't something drastically wrong with your CPU timing system. As long as the numbers are close, don't worry about them. The CPU index is a comparison of the relative processing power of your CPU to that of a reference standard - in this case, a Pentium Pro 200 MHz. The above readings were taken on a Pentium MMX 166 MHz and so reports in at only 90% of the Pro 200's power.

The disk performance numbers start with a simple sequential write and then read to an uncached 256 MB file. First is the file open time, in milliseconds. It should be at or near zero. The file write time in milliseconds is a true sustained transfer rate. CPU usage shows how much of the processor's time needed to be spent on setting up the transfers. Under bus mastering, this figure should be quite low. With PIO transfers, the CPU percentage will usually be in the 90% range. File flush time in milliseconds should be 0, as the writes were uncached. A non-zero figure shows that the controller is ignoring the "un-cached file" flag and is using the controller cache anyway. The rewind time should be zero as well, as this operation is simply a software pointer adjustment. The file read time in milliseconds is also a true sustained transfer rate, and CPU usage is again the amount of processor time occupied with performing the read. This value is very useful in comparing overall disk performance objectively. The CPU usage value is also very important, particularly for audio applications. With low CPU usage percentage values, we have more CPU cycles free for mixing, real time effects and other processing functions. Bus master drivers usually offer very low CPU usage values (typically below 2%). PIO mode wastes much more CPU bandwidth. File close time in milliseconds rounds out the sequential access part of the test.

The lines that follow contain measurements performed by accessing 8 files in rotating alternation using different block sizes for each read. This shows how larger read sizes dramatically improve performance . The files are each 16 MB long . BlockSize is the size used for the block read for each file. The test is run at 128K (131072 bytes), 64K (65536 bytes) and so on down to small 4K blocks. For each block size we get a total transfer rate in MBytes/sec that includes all overhead for doing an 8 file alternating read operation The track number is the total number of 44.1 KHz, 16 bit mono tracks that can be transferred. This assumes a DAW with no real time effects and that the software is written to effectively utilize the systems performance abilities. Finely we have CPU usage figures to show the processor overhead during the file transfers for that block size.

We have asked some of our friends to report their DSKBENCH numbers for various drives and mother boards. Click HERE to link to a chart of the results. You will note that we have recorded results only for the transfer rates and CPU usage figures for the 256 MB sequential write and read, and for the block tests only as far as the 32K buffer size as the other sizes are of marginal use.

Looking at DSKBENCH results, you can see how the total throughput decreases dramatically as the block size gets smaller. That's because of the larger time being wasted in seeks. Note that even at 128 K blocks, the throughput is much smaller than for sequential access, and the difference is because of the added seeking times.

Notice the entry for a DeskStar 5 drive on a Asus Super-7 motherboard. This is a rather poor performance spec for the sustained write throughput. The system is badly configured. That disk should read about 10 MBytes/sec instead of the 0.33 that is listed. This needs to be looked at! Also note that as a rule, reports for VIA chipsets show higher CPU usage that PIIX chip sets. This is shown here, too, although there are few entries for VIA among this data and it's a good bet in one case that bus mastering isn't engaged on this system.

Many folks have become skeptical of bus mastering results because of the way Intel has cheated on the reporting of performance using its bus mastering drivers. Standard benchmark programs that attempt to measure disk performance under business or server conditions were obtaining ridiculously over inflated performance figures due to Intel's behind the back use of memory for disk cache even after being instructed by the software to disable any caching. With other bus mastering drivers following the rules and Intel's not, this made it seem that Intel was the only company that knew how to write good drivers. This has been discovered and taken into account with newer benchmark programs including DSKBENCH, which uses the "flush" time to detect any underhanded activity, not that using cache would improve the results of streaming tests like the kind that DSKBENCH performs anyway.

CPU Power Bottleneck
Let's be realistic about this. Let's say you would like to get 50 tracks of 16 bit, 44.1 KHz audio to play and/or record at the same time on your system. Will you ever use 50 tracks of raw audio voicing at the same time in one project? Now keep in mind, this isn't to say that you will not have many projects with 50 or more tracks in use, but how many total tracks of audio will be voicing AT THE SAME TIME? How many will be archived takes? How many will be short clips that will always fall in between other short clips? When was the last time you even considered using 50 tracks of solid audio? When was the last time you had to close-mic the Mormon Tabernacle Choir <g>?

Now granted, as a good friend, David Hallock, mentioned in response to this question, sometimes he likes to double or triple up on a few tracks, move them slightly out of phase and mix them to fatten the sound, but never to such a point that it would add up to 50 simultaneously voicing tracks at any given time (Dave also notes that he usually will mix those tracks to a final stereo sub group mix anyway).

However, if you go to 24 bits per track, that might limit you to 32 tracks on the same system, and at 96 KHz on top of it, 16 tracks. Now we're talking some limitations. For those of us that wish to use 24/96 recording, there are some tough choices to be made. However, it stands to reason that at those requirement levels, an improvement in drives will amount to an even smaller gain in track count because each track is so incredibly demanding that you must have nothing short of a miracle to gain another track through tweaking. Again, is there any advantage of one drive over another once you get to a certain point? For this kind of production, you need the absolute fasted rotational speeds and highest sustained throughput. At the present time, only drives like the Quantum Atlas 10Kor IBM Ultrastar SCSI with 10,000 rpm rotation speeds, the new Seagate Cheetah SCSI spinning at 15,000 rpm and the Fujitsu MPF-AH series IDE will measure up. Perhaps when Maxtor gets their line of dual processor UDMA66 IDE drives that promise sustained throughput of 50 MBytes/.sec on the market there will be some more choices. For now, 10,000 and 15,000 rpm SCSI and Fujitsu IDE are about the only choices that will grant you any REAL improvement over the rest of the newer high speed drives available on the market. Be prepared to pay THROUGH THE NOSE for them!

So why not recommend these drives for EVERYBODY? With the notable exception of a very few situations, almost all digital audio production utilizing streaming of multiple tracks in real time will use some real time (likely Direct X) effects. As a result, the number of tracks in a given project will be limited more by the amount of CPU power available for real time effects processing and track mixing than by the drive's ability to stream the data. If you want proof, simply load your most demanding, highest track count project into the streaming application of your choice and hit PLAY. Now look at the drive LED. Is it lit 100% of the time? Not likely! The drive is not being taxed to the point where it must maintain a constant flow of data. There is a resting period, short as it may be, between the bursts required to keep the I/O buffers full. Now, in all fairness, without a fast drive and some minimal optimization, there will be a reduction in track count due to the drive even with effects in use. This goes without saying, even though we've spent a lot of room here saying just that! However, this situation where the user has decided to ignore common sense and set up his DAW as carelessly as possible aside, we're more limited by the CPU than the drive in all cases. A drive that dumps data like a bat out of hell will not improve the situation and only cost you money that would be better spent on a faster CPU or more RAM.

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