X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <4817E90F.2050904@cwilson.fastmail.fm>
Date: Tue, 29 Apr 2008 23:35:43 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer  space available.
References: <3ee066b40804282136v140bdf31v4b21082663c55021 AT mail DOT gmail DOT com> <481728A0 DOT 7020604 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <481728A0.7020604@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Charles Wilson wrote:

> http://cygwin.cwilson.fastmail.fm/ITP/ftpd-1k.exe.bz2
> http://cygwin.cwilson.fastmail.fm/ITP/ftpd-4k.exe.bz2
> http://cygwin.cwilson.fastmail.fm/ITP/ftpd-8k.exe.bz2
> http://cygwin.cwilson.fastmail.fm/ITP/ftpd-32k.exe.bz2 (same as prev)


For ex, with the 32k buffers, here's what I see in the resource monitor 
(this is on Vista, cygwin-1.7)

commit (KB)    Working Set (KB)    Shareable (KB)   Private (KB)
3948             5,832               3,716            2,116

when the client begins to 'get' the very large file, I can watch the 
Private allocations jump in 4k increments.  Meanwhile the Working Set 
and Shareable both jump in 1300kB (or so) increments.  This continues 
until a maximum of about:

commit (KB)    Working Set (KB)    Shareable (KB)   Private (KB)
4,488          240,000             238,000            2,600

is reached.  Once the transfer is complete, the numbers drop back down 
to the first set, above.  However, for smaller sizes (4k, 1k) I get sane 
behavior -- see below.


Another thing I noticed, was transfer speed:

topology one:
server=Vista, cygwin-1.7, wireless 802.11g
client=XPsp2, cygwin-1.5, wireless 802.11g
(both using the same access point, thus sharing the same nominal 54Mbps 
link)

64k buffers:     2 Mbps
32k buffers:     1 Mbps
  8k buffers:     9 Mbps
  4k buffers:  9-10 Mbps (sane!)
  1k buffers;   8-9 Mbps (sane!)

This poor behavior with 32k and 64k buffers could be a function of my AP 
not handling bi-di wireless transfers well, or the longer bursts forcing 
it to use the available bandwidth inefficiently. Trying again:

Topology two:
server=Vista, cygwin-1.7, wireless 802.11g
client=linux, 100BaseT wired

64k buffers: 17-20 Mbps
32k buffers: 15-17 Mbps
  8k buffers: 13-14 Mbps
  4k buffers: 14-15 Mbps (sane!)
  1k buffers; 13-14 Mbps (sane!)

So, while you get better performance (in unshared topologies) with the 
larger buffer sizes, the 4k and 1k buffers exhibit sane behavior with 
respect to the Working Set and Shareable memory allocations:
   (1) they stay around 5MB to 6MB rather than ballooning up to 240MB.
   (2) I actually see the numbers go down occasionally, instead of 
always increasing until the transfer is complete.

That's good enough for me to forego the improvement in transfer speed 
(which is anywhere from 13%--42% if you compare best/worst and 
worst/best between 64k and 4k on non-shared topologies) -- and avoid the 
awful behavior on shared topologies.

Unless somebody squawks loudly and soon, I'm going to release 
inetutils-1.5-4 using 4k buffers for ftpd send_data().

--
Chuck

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