Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <5.1.0.14.2.20021129075413.00fdf8a8@pop3.cris.com>
X-Sender: rrschulz AT pop3 DOT cris DOT com
Date: Fri, 29 Nov 2002 08:06:04 -0800
To: cygwin AT cygwin DOT com
From: Randall R Schulz <rrschulz AT cris DOT com>
Subject: Re: pipe performance problem
In-Reply-To: <1038575316.4126.7.camel@lifelesswks>
References: <20021129020012 DOT GB9074 AT redhat DOT com>
 <14936170000 DOT 20021127223905 AT huno DOT net>
 <20021127233624 DOT GK17798 AT redhat DOT com>
 <1245871093 DOT 20021128012046 AT huno DOT net>
 <20021128003443 DOT GD21457 AT redhat DOT com>
 <5549457171 DOT 20021128022032 AT huno DOT net>
 <6654089625 DOT 20021128033745 AT huno DOT net>
 <1988826218 DOT 20021128150740 AT huno DOT net>
 <14015247140 DOT 20021129012600 AT huno DOT net>
 <20021129003838 DOT GA8794 AT redhat DOT com>
 <10718265421 DOT 20021129021618 AT huno DOT net>
 <20021129020012 DOT GB9074 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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/