Subject: Re: [linux-audio-user] 2nd harddrive overhead
From: Malcolm Baldridge (linux-audio_AT_paypc.com)
Date: Fri Aug 27 2004 - 02:52:44 EEST
> I have two hard drives, hda and hdb, both UDMA66. hda has the ext3 root
> partition, a swap partition, and a FAT32 partition. hdb just has one
> 10Meg FAT32 partition.
>
> When I stream a .wav file from the FAT32 partition on hda through say
> XMMS, the total system load is very low, just a few percent cpu load.
>
> When I do the same, but from hdb's FAT32 partition, the cpu load hovers
> at around 30-50%. What is responsible for all the extra cpu activity in
> reading from the 2nd harddrive ?
It's hard to really say, without alot of speculation... hdb's FAT32 may be
more fragmented than hda's. Do you see UDMA66 for both devices in "dmesg"
output?
Typically, your setup is a bad one for IDE, though. If you want two HDDs in
your system, it's probably better to put the HDDs on each channel, with the
secondary one on the same channel as the DVD/CD-ROM drive (which is not used
that often). Put the second HDD on hdc (secondary master), and the cd-rom
as hdd (secondary slave). Use an 80-conductor cable on both channels, as
UDMA66 requires it.
While it's handy for extra storage to "fill up" the master/slaves, the
performance is never good. It's especially bad because you have the swap
device on the same IDE channel as another data storage device. Unlike SCSI,
IDE channels don't "overlay multiple i/o commands" or have intelligent
multiple outstanding I/O commands where the device re-targets the host when
the I/O is completed. Furthermore, the "slave" device truly is a
second-class citizen, vis-a-vis contentious I/O access attempts.
Poor chipset tunings can make all of this really really bad. There are also
some buggy CMD6xx IDE interfaces which worsen this already bad situation.
Let's first check your hdparm settings.
hdparm -v /dev/hda
hdparm -v /dev/hdb
You should see Bus-Mastering, 32-bit I/O, unmask IRQ (a bit optional, but it
can reduce IRQ latency), and MultiSector mode enabled.
Inquiry the drives for what the maximum multisect count supported is:
hdparm -i /dev/hda
hdparm -i /dev/hdb
Now, let's do some basic performance checks.
Disable swap and flush dirty buffers with:
swapoff -a
sync;sleep 2;sync
Test buffer cache + drive interface speeds:
hdparm -t -T /dev/hda
hdparm -t -T /dev/hdb
Assuming the maximum supported MultiSect count is 16 on both drives, then
configure the drives thusly:
hdparm -m16 -c1 -u1 -d1 /dev/hda
hdparm -m16 -c1 -u1 -d1 /dev/hdb
Re-test performance and compare:
hdparm -t -T /dev/hda
hdparm -t -T /dev/hdb
Good luck. Some people find that reducing the -m parametre helps lower
latency without a significant cost to performance. Try -m8 or -m4 in these
cases.
If the above doesn't do anything, then you'll need to provide the exact hdd
models, kernel version, motherboard + chipset, etc.
You can dump the IDE chipset driver's info as follows:
VIA Chipset: cat /proc/ide/via
SiS Chipset: cat /proc/ide/sis
Intel Chipset: cat /proc/ide/piix
=MB=
-- A focus on Quality.
This archive was generated by hypermail 2b28 : Fri Aug 27 2004 - 02:59:08 EEST