Corinna, > IIUC, the testcase should exhibit the problem OOTB. HAVE_MMAP is > defined and LARGE_TRANSFER_BLOCKSIZE is set to 32K. I did what you > wrote above, I built server and client, added the example port to > /etc/services, created the ReallyBigFile from /dev/urandom as above... > > However, I can't reproduce any ill effect. This testcase mmap's the > file exactly once and then calls as many 32K write's as necessary to > write the whole file. I don't see any waste of memory at all. > > When examining the memory usage with Task Manager or, better, with > sysinternal's Process Explorer, you'll see how the memory usage goes up > over time. But that's no problem. What you see is the mapping of the > file into the physical memory of the machine. With each write, the > process accesses another 32K bytes of the file mapping, so the OS has to > map another 32K of the file into the process memory. Actually this is > done in 64K chunks, but that doesn't matter here. What you see is quite > normal behaviour and has nothing to do with Cygwin's mmap implementation, > AFAICS.
Just to be clear, when the test server is serving up a 250MB file, you'd expect it to ultimately be using 250MB of memory according to Task Manager? On my server machine, this meant that by the time the end of the file was reached, Windows was paging to disk like mad, and so the transfer speed dropped dramatically. I would argue that this is a retrograde step for ftpd, but maybe I'm missing something. Charles, the latest version of ftpd that you released (no MMAP, 4k block size) works fine for me wrt memory, but used considerably more CPU than the last version of in.ftp, with no noticeable performance gain. For now I'm quite happy using the latest inetd with an old in.ftpd, so if no-one else is having problems then please don't worry about this. Thanks ant. -- 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/