From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6692 invoked by alias); 14 Dec 2007 14:35:03 -0000 Received: (qmail 6677 invoked by uid 22791); 14 Dec 2007 14:35:02 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Dec 2007 14:34:55 +0000 Received: by nf-out-0910.google.com with SMTP id b2so823306nfb.18 for ; Fri, 14 Dec 2007 06:34:45 -0800 (PST) Received: by 10.82.171.16 with SMTP id t16mr8572783bue.11.1197642884004; Fri, 14 Dec 2007 06:34:44 -0800 (PST) Received: by 10.82.118.4 with HTTP; Fri, 14 Dec 2007 06:34:43 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 14:35:00 -0000 From: "Lev Bishop" To: cygwin@cygwin.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.7090002@4raccoons.com> <20071213175934.GB25863@calimero.vinschen.de> <476185AF.5000906@4raccoons.com> <20071214111508.GD25863@calimero.vinschen.de> <20071214134147.GG25863@calimero.vinschen.de> <20071214135239.GJ25863@calimero.vinschen.de> Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2007-12/txt/msg00351.txt.bz2 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/