Joerg Schilling wrote:
Bill Davidsen <davidsen@tmr.com> wrote:I have an interesting problem burning one CD, I keep getting underruns. I can avoid it by using a low speed burn, or live with it with the burnfree option, but I don't understand why it occurs.The system is a P4-2.8G, 1GB memory, 40x CD burner. The O/S is FC1, latest 2.4.22 kernel, and the burner runs in ide-scsi. The burn was done as root, no warning messages, nothing else running. After the first bad burn I checked that DMA and interrupts were enabled on the hard disk, and set the fifo size to 50MB, larger than the longest track (22MB). cdrecord is 2.01a31 and I tried the 2.01a19 which comes with FC1.If this is true, then you need to contact the Linux Kernel peopel for a fix. BTW: you are using outdated software.2.01a19 is 15 months old
As noted cdrecord in normal use is 2.01a31, I tried the distributed version in case there was a Redhat-ism needed. The a31 AN file is date June 2004, built from your source, unless there were major bugs, that's not the issue, I was trying the obvious things and using the version which came with the kernel before asking for ideas.
How about -pad, would there be any reason for that to cause slowdown? The recording process from the original tapes may not be always the right length, and my .inf file builder rounds up and warns to use -pad, I can rerun with the truncate option so -pad is not needed. Or could the -useinfo cause overhead?
What I don't understand is why/how there could be an underrun when the fifo is larger than the track. It almost sounds as if the application were not filling the fifo before starting the burn, but the minimum fill was 95%, so that seems unlikely. I looked at the code quickly and saw no obvious cause for this. I also watched the CPU usage which burning, and it was always 60-70% idle. Since it ran at RR priority there should be no issue with CPU performance.It sounds like either the Kernel is not performant enough to send the SCSI commands fast enough or that an unfriendly "other" application is trying to break into the communication between cdrecord & the drive.
Example? I have disabled any automounting options long ago, is there some other evil daemon which might be running?
Thanks for the feedback. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979