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: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.

Charles Wilson wrote: (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().


Unsubscribe info:
Problem reports:

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