inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.

Charles Wilson cygwin@cwilson.fastmail.fm
Wed Apr 30 04:41:00 GMT 2008


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/



More information about the Cygwin mailing list