Traditionally, SCSI drives give high sequencer track counts while IDE drives are more affordable but perform less well. Can you obtain better Mac sequencer performance and save money by using multiple IDE drives? We present some evidence...
Owners of computer-based sequencers have known for a couple of years now that although SCSI drives give the best performance (and therefore better sequencer track counts), IDE drives do the job well too, if not quite as well as SCSI models — although at the upper end of the IDE specification there are drives which come close to competing with their SCSI cousins. However, in addition to coming installed as the standard system drives on most new PCs and Macs, IDE drives are much more affordable to buy separately. Because they are now used more widely in general computing applications worldwide, their price is kept low.
So I began to wonder — is it possible to put together a high-performance Mac recording system based around affordable IDE drives and make up any performance shortfall compared to a SCSI-based system by using multiple IDE drives working together? With this premise in mind, I began some tests to find out.
|Manufacturer||Seagate||IBM/Hitachi (see note)||Western Digital|
|Model name||ATA V Plus||180 GXP||WD1000JB|
|Interface||ATA/ATAPI-6 supporting||ATA/ATAPI-6 supporting||ATA/ATAPI-6 supporting|
|Maximum quoted sustained data-transfer rate (MB/s)||44||56||-|
|Quickbench-measured sustained read rate (MB/s)||41||64||42|
|Average seek time (ms)||9.4||8.5||8.9|
|Spin speed (rpm)||7200||7200||7200|
|Noise (bels)||3.3 (high performance)||3.0 (idle)||3.5 (idle)|
|Buffer Size (MB)||8||8||8|
|Note: When the drives were supplied for review, the company was called IBM, but during the course of writing IBM and Hitachi's Storage Technology Business's have combined to form a new company, namely Hitachi Global Storage Technologies. The drive formerly known as the IBM Deskstar is now the Hitachi Deskstar, but is exactly the same drive.|
The latest Power Macs now come with three IDE drive busses as standard, one rated at ATA33, one at ATA66 and one at ATA100 (see the 'ATA & IDE — What Does It All Mean?' box later for more on ATA). The ATA33 buss (which is an ATA buss running at 33MHz, as the name suggests) is set up for use with optical drive(s) and the layout of controller and power cables facilitates this. The ATA66 and ATA100 busses are intended for use with hard drives, and again the controller and power cables provided line up with the supplied drive mountings. In theory, you have all the connections you need to add extra drives to your system.
With two or more drives in a system serving up data (in this case audio), it is possible to create two types of 'RAID array'. RAID is simply an acronym standing for 'Redundant Array of Inexpensive Disks'. There are many types of array, all of which use a collection of disks to create a single storage volume. The disks can operate independently of each other and the volume can tolerate the failure of a drive without losing data. The most basic type of RAID is Level 1 (known as a 'mirrored' RAID array), which provides 'redundancy' by writing identical data to two (ideally identical) drives. In this scenario, if one drive fails, the other takes over and no data is lost. Hence it is used for data security and not to increase performance (although a slight increase is usually noted).
The second common RAID type, Level 0 (or a 'striped' array) shares data between two drives using mini-partitions (stripes) on each drive, therefore theoretically doubling the performance available from a single drive, since the load on each is halved. Technically, this is not a RAID array at all, because no redundancy occurs, and the failure of one drive results in complete data loss.
So, with the intention of creating high-performance volumes, I used tools available in Mac OS X (in Disk Utility) to set up RAID Level 0 arrays on two internal drives in some of the various permutations offered by the multi-buss Power Mac.
Mac OS 9 requires a separate application to achieve the above and, unlike OS X, which requires no additional hardware to be present except the drives themselves, also requires the use of a PCI card that adds the equivalent of two IDE busses to the system. These are known as ATA RAID cards, and there are several on the market. Most are manufactured by Acard and rebadged, as was the one I assessed, the Alchemy ATA RAID 133 PCI card from Miglia. I also used various drive software, such as Lacie's Silver Lining Pro (which is generally bundled with Lacie's hard-drive products), Charismac's RAID Toolkit, and the imaginatively named SoftRAID (by SoftRAID!), which was originally written to format SCSI RAID systems, but is fooled by the ATA RAID card into thinking that it is dealing with a SCSI setup. OS X can of course also create RAID arrays using drives connected to RAID cards.
It's also possible to set up Firewire drives in RAID arrays, and this was another approach I tried. Miglia sent me an MTR Mediabank, an empty housing which contains two Firewire controllers and power supplies for two drives (although it can also be supplied with drives pre-installed). Although modern Power Macs have two Firewire sockets, these are not really separate ports, as they are controlled by the same buss. The exception to this is those Power Macs with the latest, faster Firewire 800 standard, where the 800 socket can be used with older-style 400 hardware using the appropriate adaptor, and is controlled by a separate buss to the 400 sockets. To create a second Firewire buss on the Dual DDR 1.25GHz Power Mac that I used for the tests, I installed a Keyspan Firewire card so that each Firewire controller in the MediaBank had its own buss.
In each case, I ran several tests. I used Quickbench from Intech software (www.intechusa.com/QB.html), a well-respected benchmarking program, to obtain some comparative transfer-rate data, but, as has been pointed out many times in the past, software benchmarks are not necessarily a reliable indicator of real-world performance from a specific application.
As a standard, I chose to use Logic Audio as my sequencer package for track-count testing throughout, more due to personal familiarity than anything else.
My first test was the 'large files' test, as used in previous SOS test articles (see www.soundonsound.com/sos/Mar02/articles/Firewire1.asp for more details). In essence, this consists of running steadily increasing numbers of continuous tracks (like a conventional multitrack tape recorder) until Logic flags up its 'Hard Drive Too Slow' warning — at which point I noted the maximum possible track count. The files themselves are recorded at 24-bit 96kHz resoution, and played back at the 96kHz sample rate.
The folder which contained these large files was 1.09GB in size and, as a test of combined read and write capability, was copied from each drive back to the same drive.
The next test was the 'small files' test, utilising tracks made up of separate audio files a 16th note in length, with 16 to a bar. The absolute length of each file is determined by the fact that the song used for 'construction' ran at 120bpm, so each file is 0.125 seconds long, or 12,000 samples. More details of test song construction can be found at the above-mentioned March 2002 SOS article.
In my testing for previous SOS articles this song was played back at 120bpm (eight files per second per track) but due to enhancements made to Logic in the interim and the increased performance of the disk drives on test this month, this test no longer posed a severe enough load on the hardware. Therefore I increased the tempo to 480bpm (four times the original speed, or 32 files per second per track). Again, the files used were 24-bit, 96kHz recordings played back at 96kHz.
To ensure a level playing field, each drive was initialised before use by Disk Utility in OS X, with the 'Install OS 9 Drivers' option ticked (see screenshot below). The data was copied each time from a Lacie PocketDrive rather than constructing the song as required, partly to save time and partly to ensure that the bits were laid down on each disk in the same order each time.
Disk Utility had many uses during these tests. One which proved invaluable was its ability to mount and unmount drives and partitions. With several drives present, each with identical data, it was often difficult to predict which drive Logic was using (without looking in Logic's Audio Files window and checking View/Get Info). Making unused drives invisible to Logic removed this potential point of confusion.
The first test was to ascertain the best configuration for a second internal drive. One of the Western Digital WD1000JB drives (known henceforth as WDC — see the box for the spec of all the drives on test) was used as the second drive in each case. In Table 1 the system drive is on the ATA100 buss and in Table 2 it is on the ATA66 buss.
Although instinct would suggest that the ideal setup would have the rarely accessed system drive on the technically slower ATA66 buss and the heavily used audio drive on the superior ATA100 buss, the figures do not bear this out. It appears to make no real difference to Logic which way the drives are connected. The Quickbench figures for the WDC do show an improvement when it is connected to the faster buss, but strangely only for write speeds. As if to underline the flakiness of benchmarks, the Quickbench figures for the other drives in the same positions do not always follow this pattern, and refuse to show any great advantage for either buss.
I was prepared for the fact that drives sharing the same buss should not perform quite as expected, since the buss can only deliver one read/write instruction at time. However, I was disappointed to note that performance did not increase when the drives were on separate busses. What this probably indicates is that the system drive is accessed very infrequently during audio playback, and makes few interrupts to the audio drive.
The data partition on the system drive outperforms every second drive in all the Logic tests, as in every hard drive test I have ever done. Indeed, with Logic the system drive always performs better than any other drive in the setup, for a reason I have not yet discovered. I would suppose that since the ATA specification finds it hard to allocate information simultaneously to two drives on the same controller, a single drive doing both jobs (audio files and OS/application) would be easier for the system as a whole to control, even if there are several ATA busses.
My next test was to find out which of my contenders was the best-performing drive. IBM (now Hitachi), Seagate and Western Digital supplied pairs of drives. IBM/Hitachi sent the 180GB version of their well respected 180GXP model. Seagate sent the Barracuda ATA7200.7 in 120GB form and Western Digital sent the WD1000JB in 100GB form. The 'JB' stands for 'Jumbo Buffer', but in fact all three drive types supplied had an 8MB buffer.
Although I had no conclusive evidence from the first test to support my hunch as to the best position for the second drive in a two-drive system, I attached the system disk to the ATA66 buss and one drive from each manufacturer in turn to the ATA66 and ATA100 busses in turn, as shown below.
Table 4 shows that the Seagate has a slight edge over the WDC in the small files test, which supports their claim of a marginally faster seek time (as shown in the 'Drives On Test' box), but the sustained data-transfer rate (when reading) is identical, confirmed by Quickbench, which results in equal performance with large file track counts. Both are beaten by some margin in all Logic tests by the IBM/Hitachi Deskstar. Although seek time is fairly similar, the data-transfer rate (both quoted and as measured by Quickbench) are in the order of 25-33 percent better than the other two drives. There is an argument that since Power Macs have used IBM Deskstars as system disks for some time now, driver structure may be favourable as a result, but this is pure conjecture; in fact, the most recent range are supplied with the same model of Seagate drive on test here as their system disk!
My next challenge was to see whether two additional drives could be successfully configured as a RAID pair, and if so, which position of the several combinations possible gave the best performance. Theoretically, given previous experience with SCSI RAID, this should give extremely high performance at a fraction of the cost. But read on...
Continuing to act on my unproven hunch that the system drive should be controlled by the ATA66 buss, I tested a pair of WDCs (for no particular reason other than they arrived first for review) in RAID Level 0 array with both drives on the ATA100 buss, and then with one drive on each buss.
In each case Disk Utility (OS X) was pressed into service to select the drives and configure the array (see screenshot, below right). Perhaps not surprisingly, with both drives on the same buss, the performance suffers, as you can see from Table 6 above. Now both drives are attempting to make multiple read/write requests simultaneously, and the buss is forcing them to take turns, as only one can be processed at a time. With a drive on each buss, performance increases dramatically, nearly matching that of the data partition on the system drive. For purposes of comparison, the Deskstar pair and the Seagate pair were also tested in these same positions (see Tables 7 and 8).
Unfortunately, the figures for the Seagates and Deskstars in RAID 'across the busses' do not back up the findings for the WDCs, and a distinct instability was noted during operation. With both drives on the same buss, both Seagates and Deskstars performed as poorly as the WDCs.
I cannot therefore recommend this configuration for creating RAID arrays, where any device has to share a buss with any other device, as a stable solution for high performance. I alluded near the start of this article to the third buss on a Power Mac, the ATA33 buss. For the purposes of testing I disconnected and removed the Superdrive from the TA33 controller and power cables, and substituted the system drive, also adding a Deskstar on each of the other two busses. If this were to be chosen as a working system then the System disk would need to be mounted below the Superdrive in the spare optical drive bay using appropriate brackets.
The Quickbench results are near enough the same, but the practical tests are revealing. Large file track count goes up by 10 when the system disk is not sharing IDE bandwidth with one of the data drives, but small file count decreases dramatically. Also, folder copying is much faster. These figures go some way to showing improved data-transfer rate at the cost of seek time. Although stability has improved, 'internal' RAID is still not a viable option compared with the use of a simple second drive, even with three busses in operation.
Another possible approach is to install a dedicated RAID controller card, to which end my next test was directed. When using two IDE busses in a Power Mac, a third is necessary in order that neither drive in the pair is sharing a buss with the system drive. The Miglia Alchemy ATA133 card shown on the next page provides two further busses (hence its RAID nomenclature) each theoretically running at up to 133MHz, depending on the specification of the attached drives.
Installation is a cinch in a Power Mac, just as with any other PCI card, but finding a tidy path for the controller cables was tricky with the graphics and other cards in the way; I had to make sure that no cables snagged or got crimped when the G4's door was closed.
Tables 9 and 10 compare the performance of a single Deskstar drive connected to one of the Alchemy's ATA133 controllers with the same drive connected to the internal ATA100 buss, and with the data partition on the system disk controlled by the Mac's ATA100 buss. Where the second drive is on the ATA100 buss, the system disk was on the ATA66 buss, but in all other cases it was on the ATA100 buss (and of course this has already been shown to make precious little difference!). Tests with this setup were repeated under OS X and OS 9. For the record, the performance of the data partition of the system drive under OS 9 was also noted.
Two clear points can be made on viewing these figures. Firstly, no advantage is gained by attaching a drive with an ATA100 interface to an ATA133 controller. Secondly, performance increase under OS X is marked, especially for continuous files.
In order to assess the RAID capabilities of this card, I tried two different setups. Under OS X I used Disk Utility to create a striped RAID Level 0 array between the two Deskstar drives, one connected to each controller on the Alchemy card. With the same connections made I also used Lacie's Silver Lining Pro and SoftRaid to set up RAID Level 0 arrays in OS 9 (see below).
Table 11 shows that, despite the promise of separate controllers, something is holding this setup back in terms of performance using audio applications. Presumably the fact that the card is PCI and therefore still subject to the restrictions of that single buss would be the root cause of this (each drive is, in fact, still taking turns to respond to read/write instructions).
Table 12, which shows Quickbench results for the same setup, contains some impressive figures across the board (though strangely not as high as for RAID arrays without a controller card — see Table 8). Again the difference between benchmarks (theoretical performance) and applications (actual performance) should be noted. Note that Silver Lining Pro allows the RAID array to be set for these two situations. In this case, it makes no notable difference to performance.
The final connection configuration solution I tested was of great interest after my experiences testing Firewire drives in SOS August 2002 (Power Macs dating from before January 2003, as noted previously, do have two Firewire sockets, but these are fed by a single buss, so in order to create a second buss I installed a Keyspan FPCI3 Firewire PCI card.
The Mediabank is essentially a hard drive housing with space for two IDE drives, containing two Firewire (Oxford 911) controllers and two power supply connections, along with a small fan to dissipate the heat created by confining two high-performance drives in a small space. You can purchase a Mediabank with drives already fitted, but I chose an empty housing for review, since I was simultaneously testing pairs of suitable drives. Squeezing the two Deskstars, chosen as the highest-performing drives in other tests, was no easy task (and the other drives would have been the same since they were of equal external dimensions, although at this point the exposed circuitry of the Deskstars was a worry — the other two brands were completely enclosed), and Miglia would do well to include some pictorial documentation as to how best to arrange the cables, since everything becomes an almost impossibly snug fit once the drive pair is positioned (see picture, above).
The drives are 'piggy-backed' using two supplied mounting plates, whose fixing screws are left slightly loose until the drive assembly is fitted in the casing. Once I had found the appropriate arrangement for each cable I tightened the screws and slid the case cover back on. The MediaBank has a very smart and hi-tech appearance, and with the Deskstars on board is, aside from its performance potential, a compact way of achieving 360GB of desktop storage (though not perhaps as tidy as putting them inside the Power Mac!). Just for the record, Tables 13 and 14 compare the performance of each Firewire buss under OS X and OS 9 using a single Deskstar drive.
Again, Logic performs better under OS X than under OS 9, and the Keyspan Firewire buss gives better performance than the internal buss (although the file copy and Quickbench figures gives a less distinct picture).
Tables 15 and 16 below show the performance of RAID arrays set up under OS X using Disk Utility, and under OS 9 using Charismac RAID Toolkit, as supplied with the Mediabank. Unfortunately, despite my enthusiasm for the concept and this product, both sets of figures are disappointing, especially those under OS X, and although the Quickbench figures are better than for single drives, the Logic track counts are worse. Miglia's technical support noted that they have had conflict problems with certain video-capture cards (video being their main market) but have no experience as yet with audio devices. The fact I was using a MOTU 896 Firewire audio interface for these tests may indeed have some bearing on RAID performance, although I had previously noted (in SOS August 2002) that the Firewire interface caused no degradation to track count.
ATA/IDE is cheap partly because it is the pre-eminent way to connect drives to computers, and partly because of its design. SCSI drives are of more complex design, a higher-reliability specification and offer the benefits of the SCSI interface, that is possible longer cable lengths, faster interface speeds up to 320MB/s, multiple command-queueing for more use of buss bandwidth and multiple drives on a single buss. Of course, all of this comes at a price premium. Some ATA drives, such as the Hitachi, also offer ATA command-queuing capability, but currently this is not supported widely in the industry by the controller and chipset manufacturers, although there are development projects underway.
So, surprisingly, despite the promise of the various setups on offer, the best combination of performance with Logic Audio is achieved when using a single drive in addition to the system disk, and where each drive has a unique controller. No RAID solution tested here offered me any advantage in terms of audio performance — in fact in several cases the performance is worse (despite benchmark figures that predict the opposite). If one were to specify the 120GB version of the Hitachi 180GXP (as opposed to the 180GB version on test), then the best performance solution is also the cheapest — now, how often does that happen?
Suppositions that might be teased from this evidence could be as follows. Firstly, the ATA interface design is not the limiting factor on drive performance when running audio applications, or indeed any application. The mechanical and electronic design of the drive (that is, the real media transfer rate and how the drive prioritises tasks) combined with how they interact with other factors in the system is much more likely to affect 'headroom', since multitrack audio data very quickly saturates any buffers/caches available. Secondly, Logic Audio requests data in such a way that appears to work well with single IDE drives, but not with multiple drives in RAID array. RAID striping only works well when the total system architecture from drives to memory is not bottlenecked at any point. For example, even if you have a 100MB/s drive on a 50MB/s Firewire interface, the drive will never be able to deliver more than 50MB/s. Also, a poorly implemented RAID (using software or hardware) can create data-processing overhead which negates any theoretical gains, and again this is dependant on the way the application accesses data.
At the end of the day, while the IDE RAID concept may not have worked out, it's nice to know that you can obtain what amounts to 60 tracks of 24-bit, 96kHz audio-recording capability for just under 100 quid, with little point in spending further on multiple drives. That's quite a bargain!