Mail Archives: cygwin/2002/11/29/11:05:17
Rob,
I'm not sure if this finding ever made it through here as such, but in my
experiments, nice-ing "mkisofs" up (negative nice value) and "cdrecord"
down (positive nice value) I could turn certain failure of a 270 MB
recording session into probable success. Still, the behavior was not ideal:
the "fifo" (the buffer within cdrecord fed by the pipe from mkisofs) would
drain down to only 1% full (with the CD recorder's internal buffer taking
up the slack) before again rising to a more comfortable value.
One thing is for sure, were seeing a situation where the hardware (CPU and
disk) has far more than enough capacity to sustain reliable CD recording
while something about the combination of mkisofs, cdrecord and Cygwin
conspire to cause almost certain failure.
Randall Schulz
Mountain View, CA USA
At 05:08 2002-11-29, Robert Collins wrote:
>On Fri, 2002-11-29 at 13:00, Christopher Faylor wrote:
>
> > Of course, it is entirely possible that there is something wrong with
> > the logic in cygwin and that a pipe is waiting 10ms for every read or
> > something like that. I don't know. I don't see how that's possible
> > from the code in ready_for_read but it's certainly at least a
> > possibility.
>
>My WAG is that this is happening:
>
>because dd has higher scheduler priority, it interrupts mkisofs every
>10ms, and on average hits the 10ms sleep every second read.
>
>Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -