X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <ba40711f0712140634u6c5d268fxfb49544d5b6927ba@mail.gmail.com>
Date: Fri, 14 Dec 2007 09:34:43 -0500
From: "Lev Bishop" <lev DOT bishop AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: VM and non-blocking writes
In-Reply-To: <20071214135239.GJ25863@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47616D31 DOT 7090002 AT 4raccoons DOT com> 	 <20071213175934 DOT GB25863 AT calimero DOT vinschen DOT de> 	 <476185AF DOT 5000906 AT 4raccoons DOT com> 	 <20071214111508 DOT GD25863 AT calimero DOT vinschen DOT de> 	 <20071214134147 DOT GG25863 AT calimero DOT vinschen DOT de> 	 <20071214135239 DOT GJ25863 AT calimero DOT vinschen DOT de>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Dec 14, 2007 8:52 AM, Corinna Vinschen wrote:
> On Dec 14 14:41, Corinna Vinschen wrote:
> > On the other hand, as soon as I call send (or WSASendTo) multiple
> > times with smaller sizes (I tried with 10k), select starts to
> > block at one point.  But even then strange things happen.  After
> > some time (after 5 seconds, then after 14 seconds, then about every
> > 60 seconds) select() just signals the socket ready for write and
> > the next send adds another 10K to the internal buffer.  A tcpdump
> > on the interface shows that no package goes over the line... which
> > would be a surprise anyway, given that the peer does not even once
> > call read().
>
> Hmm, a few minutes ago select() mysteriously blocked fully after send
> has written 19 blocks of 10K each....

Good luck with figuring this stuff out. The way winsock deals with all
of this stuff is rather mysterious and quite hackish, basically
because it's all implemented in an emulation layer afd.sys and
msafd.dll which tries to give bsd socket syntax (or something sorta
close anyway) on top of the native overlapped io. The afd layer does
some mighty weird things. See, for example, my reverse engineering of
one aspect of it's send buffer management here:
http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html

There's a whole bunch of tuning parameters that deal with when afd
should make a copy of an application-supplied buffer (incurring the
copy costs) or just lock the application buffer in ram (incurring VM
manipulation costs) and so on. Look at registry configuration
parameters:
DefaultReceiveWindow, DefaultSendWindow, FastCopyReceiveThreshold,
FastSendDatagramThreshold, LargeBufferSize, LargeBufferListDepth,
MaxFastTransmit, MaxFastCopyTransmit, MediumBufferSize,
MediumBufferListDepth, OverheadChargeGranularity, PriorityBoost,
SmallBufferListDepth, SmallBufferSize, TransmitIoLength,
FFPControlFlags, FFPFastForwardingCacheSize, GlobalMaxTcpWindowSize
and probably others.

You can probably do something about this particular issue by tweaking
those parameters, or making sure you make the sends fall on the right
side of some boundary defined by those parameters. But in general....
I'm not confident.

Lev

Lev

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/