[linux-audio-user] 2nd harddrive overhead

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux