Subject: Re: [linux-audio-user] Ardour, Jack, and 2.6 kernels + XRuns with the Audiophile 24/96 M-Audio
From: Malcolm Baldridge (linux-audio_AT_paypc.com)
Date: Tue Jun 01 2004 - 23:07:32 EEST
> 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.
This archive was generated by hypermail 2b28 : Tue Jun 01 2004 - 23:03:35 EEST