Mail Archives: cygwin/2008/04/29/23:36:30
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/
- Raw text -