> You might be surprised. Thanks for the URLs, Jan. Yeah, I know (from testing in other environments) that the Classic bias of SCSI over IDE doesn't apply in all situations anymore. I guess it just took me aback that Adaptec would be such a bad PCI neighbor. It's not really justified from a server perspective since modern servers often have multiple GigE interfaces [most of mine have three with two on-board, for example], and it's important to allow bus cycles for those cards to keep network performance high. I do know that you need to ensure the following things to get good performance and reasonably low CPU utilisation out of IDE storage: 1) You can't use more than one drive per IDE channel. In a contention scenario for the master/slave, I/Os get deferred for a shocking amount of time. Unlike SCSI, IDE doesn't support disconnected multiple transactions over the same "bus". With IDE, a given I/O has the channel for as long as it takes to complete. It's VERY bad on performance to mix very slow devices (such as CD-ROMs) with fast ones: they hold a lock on the bus during all operations, and CD-ROMs these days are fast about spinning down discs. 2) You need to ensure 80-wire cabling is used and that you're getting UDMA/100+ timings out of the controller. While it *IS* true that the transfer rates are going to be limited by the mechnical transfer rate limits, what the articles neglected to mention is that transfers in and out of the drive's cache [very effective during writes] occurs at the interface limit if it can be satisfied purely by the on-drive cache. This lets the I/O burst more effectively and get off the bus faster. Also, new drives these days can sustain greater than 70MBytes/second, but I understand that throughput isn't a technical requirement for DAW use. 3) Good/correct IDE drivers for the chipset. With Linux at least, you have pretty good control over this: just make sure you build your kernel with the IDE chipset driver compiled into the kernel statically [it needs to activate prior to the mounting of /]. 4) And lastly, you should verify the IDE tunings are optimised with hdparm. You can check on the settings by: hdparm -v /dev/hda [replace /dev/hda with any other drive you wish to check]. You should see 32-bit I/Os, Unmask IRQs, MultiSect = 16, and DMA set. If not, you can set them up with: hdparm -c1 -u1 -d1 -m16 /dev/hda You can put this in your system startup script to do this for you automatically. With these settings on a recent (1999 or newer) motherboard, with a recent drive, you should see excellent IDE performance. But still... even my old 10K and 15K RPM U-160/U320 drives blow the pants off my newest IDE drives with almost zero CPU utilisation. But that is for a server application (on P4 SuperMicro systems with onboard U160/U320 dual channel SCSI hardware), and it's quite possible that if I tried doing audio on that hardware, I'd be in xruns city. Cheers, =MB= -- A focus on Quality.
