On Fri, 11 Jan 2002, Manuel Clos wrote: > Bill Davidsen wrote: > > > Just a thought on making cdrecord smarter for Linux... > > > > If a recorder has (claims to have) Burn-proof capability, it would be nice > > to run the burner at normal priority and with a small fifo, since the only > > drawback would be slightly slower burning. > > > Slower burning is not the only drawback. If you try to burn a cd at full > capacity and the burn proof has to be used several times, the data won't > fit. This has happened me with an external freecom. I don't know is > newer recorders don't do this little separation when starting again.
I guess the software under Windows is better at avoiding that, or newer CDs don't have the problem. > > > Perhaps this could be a flag, then if the user selected that option any > > problems would clearly be of his/her own making. > > > > Just a thought, posted from a machine which is VERY sluggish at the > > moment, doing end-of-week backup. > > Try the preemptive kernel patch for 2.4.17, it makes things *a bit* > better with ide-scsi. No, I tried patching the source to make the application behave, and limited the FIFO to 4M. It did get down to 80%, but no lower. It runs RT priority with SCSI, I see no significant issue with ide-scsi or not, I would expect preempt to behave the same, RT processes get preference, and that's the issue, doing lots of little reads trying to keep the FIFO full, instead of somewhat larger reads. Thanks for the input, I've tried preempt (with lock-breaker), -aa, low latency, -ac kernels, rmap kernels, etc. I'm looking at another problem, so I get to try burning on lots of systems and kernels. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
