lost timer interrupts when doing audio CD burn/extract

lost timer interrupts when doing audio CD burn/extract

Post by Robert M. Riches J » Sun, 27 Apr 2003 09:09:21



When I burn or extract audio tracks, the system (RH8.0)
seems to lose about 2/3 of the clock timer interrupts, which
causes the system clock (kernel, not hw RTC) to run about 3X
slow, which loses about 5 minutes while burning and
verifying an audio CD.  (I'm digitizing my old vinyl LPs for
my own use, which is perfectly legal.)

Burning data CDs with cdrecord works fine.  Burning audio
CDs with cdrecord has the problem.  The burner uses ide-scsi
emulation, of course.  Reading data CDs works fine if I have
'options ide-cd dma=1' in /etc/modules.conf.  Extracting
audio CDs with cdparanoia has the problem.  The clock
slowdown problem is accompanied by system time > 50%, which
may indicate PIO rather than DMA when doing audio.

The system is an Iwill P4ES mobo,a 2.4GHz "B" Pentium 4, 1GB
of ECC RAM, Intel 845E chipset, with each drive is on its
own ATA-100 or ATA-133 cable.  An 'lspci -v' shows sharing
of IRQ 11 and a few others.

My previous (and only) system was an Alpha with all SCSI
I/O, so I'm new to the IRQ conflict and PIO business.

Ideally, I'd like to get cdrecord (audio mode) and
cdparanoia use DMA rather than PIO to get the CPU use down.
If I can't get the kernel/system clock to keep proper time,
I'll have to buy new SCSI drives and use the IDE ones as
doorstops.

Any suggestions?

Thanks.

Robert Riches

 
 
 

lost timer interrupts when doing audio CD burn/extract

Post by Robert M. Riches J » Wed, 30 Apr 2003 05:21:40



Quote:> When I burn or extract audio tracks, the system (RH8.0)
> seems to lose about 2/3 of the clock timer interrupts, which
> causes the system clock (kernel, not hw RTC) to run about 3X
> slow, which loses about 5 minutes while burning and
> verifying an audio CD.  (I'm digitizing my old vinyl LPs for
> my own use, which is perfectly legal.)

> Burning data CDs with cdrecord works fine.  Burning audio
> CDs with cdrecord has the problem.  The burner uses ide-scsi
> emulation, of course.  Reading data CDs works fine if I have
> 'options ide-cd dma=1' in /etc/modules.conf.  Extracting
> audio CDs with cdparanoia has the problem.  The clock
> slowdown problem is accompanied by system time > 50%, which
> may indicate PIO rather than DMA when doing audio.

> The system is an Iwill P4ES mobo,a 2.4GHz "B" Pentium 4, 1GB
> of ECC RAM, Intel 845E chipset, with each drive is on its
> own ATA-100 or ATA-133 cable.  An 'lspci -v' shows sharing
> of IRQ 11 and a few others.

> My previous (and only) system was an Alpha with all SCSI
> I/O, so I'm new to the IRQ conflict and PIO business.

> Ideally, I'd like to get cdrecord (audio mode) and
> cdparanoia use DMA rather than PIO to get the CPU use down.
> If I can't get the kernel/system clock to keep proper time,
> I'll have to buy new SCSI drives and use the IDE ones as
> doorstops.

> Any suggestions?

Please forgive my breach of netiquette for following up to
my own post.  In case it might help somebody else with a
similar issue, here is the present best solution I found:

    hdparm -u 1 -c 1 -k 1 /dev/cdrom
    hdparm -u 1 -c 1 -k 1 /dev/hdc

I plan to put these commands in /etc/rc.d/rc.local when I
get an opportunity.

The first (-u 1) switch does the lion's share of the job by
unmasking interrupts while the driver transfers data.  This
makes the clock keep correct time during audio CD burning
and extraction with cdparanoia.

The second switch (-c 1) enables 32-bit I/O between the
controller the rest of the system, rather than the default
16-bit I/O.  It reduces CPU use a little bit and speeds
cdparanoia up a little bit.  (Burning speed is, of course,
limited by the disc speed.)  The CPU overhead is still much
higher than with my previous SCSI-based Alpha system, but
it's tolerable now that the clock keeps correct time.

The third switch (-k 1) should be used _ONLY_ after testing
the first two.  It makes the first two switches stick across
soft resets.

If anyone uses hdparm to tune hard disk performance, please
read the warnings in the man page very carefully, because
this allegedly can cause serious file system corruption.

YMMV.  Good luck.

Robert Riches