This is the mail archive of the cygwin 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: VM and non-blocking writes

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:

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
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.



Unsubscribe info:
Problem reports:

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