Re: horrible system performance using ide-scsi for cdrom on tibook
this helps, and i guess i can understand why, since it looks like that
flag allows other interrupts to be serviced while the cdrom dma
interrupts are being handled.
however, the system goes from totally unusable to marginally usable
after enabling this flag. in contrast there's no noticible load when
using the ide driver on my desktop. top on the tibook still shows X
and some other processes as eating most of the cpu. in the case of the
tibook, i'm taking about 80-90 interrupts/sec from ide1, and in the
desktop machine, 110-120 interrupts/sec.
its strange, though, that the interrupts from the drive dont cause this
behavior when not using ide-scsi...
one more interesting tidbit: on the desktop machine, hdparm reports
that the readahead value is 8 (sectors?) yet on the tibook, the ioctl
has apparently returned an error for this variable (BLKRAGET failed:
Input/output error). i suppose that this might make the DMA itself
slower on the tibook, but it shouldnt cause the interrupt service time
to go up, right?
Michel Dänzer writes:
> rob pfile wrote:
> > I've posted on a similar topic before. the short story is that i could
> > not make the dvd/cdrom drive in the tibook work for audio extraction
> > unless i used the ide-scsi package.
> > while that worked in the sense that cdparanoia could see the drive,
> > system performance during cd ripping is terrible. the load average goes
> > to about 5 and the mouse is completely unusable. the strange thing is
> > that the X server and a few X clients are hogging the cpu during
> > ripping, which just makes no sense.
> Educated guess: the load is caused by IDE interrupts, some of which occur in
> the X server's and clients' time slices so they get accounted for the CPU
> cycles they use.
> Try hdparm -u1 /dev/hde (or whatever the IDE device node of your DVD ROM is).
> Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
> XFree86 and DRI project member / CS student, Free Software enthusiast