This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pipe performance problem


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]