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? thanks rob 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 >
