Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On May 1 01:57, Charles Wilson wrote: Corinna Vinschen wrote: On Apr 30 01:58, Charles Wilson wrote: If [disabling mmap] *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. There might be a bug lurking somewhere. Could you create a very simple testcase which basically behaves like ftpd for debugging? attached. gcc -o server server.c gcc -o client client.c Add an entry to /etc/services on both machines, like: example 22725/tcp or you could edit the two files and use a hardcoded port number, instead of a service name and getservbyname() And don't forget to open a hole in your server machine's firewall for that port. On the server machine, invoke as: $ server filename This file is the one that will be transferred to the client. This works for me: $ dd if=/dev/urandom of=ReallyBigFile bs=1M count=250 On the client: $ client hostname_of_server filename filename is where the client will save the transferred data. server is a traditional daemon, which forks off a copy to handle each new connection. That copy is the one you want to debug/strace/whatever. With this pair of programs, I saw sane memory usage in all cases when NOT using mmap, and I saw insane memory usage for all mmap cases except when blocksize was 1k. To switch among the various cases, edit the server.c file to #define/#undef HAVE_MMAP, and change the value of LARGE_TRANSFER_BLOCKSIZE. 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. Corinna -- 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/ -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On May 7 20:28, antony baxter wrote: 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 Yes, I expect that. The reason is that ftpd (actually Chuck's example code in my case) creates a memory map of the size of the whole file. If you access every single bit of the file, as ftpd naturally does, the file has ultimately be mapped in memory in full size. If the file is bigger than the memory left in the virtual memory space of the process, the mmap will fail. As long as Windows can fit it into RAM, it will do so. If it can't, it will use the paging file. A better approach using mmap would probably mmap only chunks of, say, 16 Megs into memory, unmap them after writing and map the next 16 Megs of the file. This way you can map any arbitrary sized file and you wouldn't have paging tradeoffs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On May 1 01:57, Charles Wilson wrote: Corinna Vinschen wrote: On Apr 30 01:58, Charles Wilson wrote: If [disabling mmap] *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. There might be a bug lurking somewhere. Could you create a very simple testcase which basically behaves like ftpd for debugging? attached. Thanks! I'm off for a couple of days, but I'll look into it when I'm back. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles, Well, one of the differences between ftpd-1.3.2 and ftpd-1.5 is that the newer version uses mmap on the (local) file. ftpd.c is the /only/ source file in inetutils that uses mmap. So, I recompiled with HAVE_MMAP turned off (but still using 4k chunks). Give this a try: http://cygwin.cwilson.fastmail.fm/ITP/ftpd-no-mmap-4k.exe.bz2 I get behavior here which is very similar to what I reported for the 4k-WITH-mmap version: (1) sane memory profile (2) topology one, 9-10 Mbps 2-3% cpu (3) topology two, 14-15 Mbps, 4-6% cpu [*] I'm not sure what benefit mmap has in this case -- unless you can exploit some zero-copy kernel code for transferring data from disk to ethernet device. But I don't think Windows has anything like that. I certainly don't *see* any benefit, in my limited testing on this set of hardware. If this *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. Ok, with this version memory stays at a constant 3600kb, cpu usage hovers at around 50%, and performance is quick (55 seconds to transfer the file). Its *possible* that the cpu usage is a red herring - the server is running in VMware and that may introduce some peculiarities of its own; however in.ftpd from inetutils 1.3.6 did maintain very low cpu usage. 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On Apr 30 01:58, Charles Wilson wrote: antony baxter wrote: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Quick addendum: I copied over in.ftpd.exe from another Cygwin installation running inetutils 1.3.2 and symlinked it to ftpd on my server; using that to serve the same file, memory usage sticks at 3500kb, cpu usage never rises about 5%, and the file was delivered in 194 seconds. Well, one of the differences between ftpd-1.3.2 and ftpd-1.5 is that the newer version uses mmap on the (local) file. ftpd.c is the /only/ source file in inetutils that uses mmap. Ok, so the ftpd using mmap is faster, one way or another. So, I recompiled with HAVE_MMAP turned off (but still using 4k chunks). Give this a try: http://cygwin.cwilson.fastmail.fm/ITP/ftpd-no-mmap-4k.exe.bz2 I get behavior here which is very similar to what I reported for the 4k-WITH-mmap version: (1) sane memory profile (2) topology one, 9-10 Mbps 2-3% cpu (3) topology two, 14-15 Mbps, 4-6% cpu [*] I'm not sure what benefit mmap has in this case -- unless you can exploit some zero-copy kernel code for transferring data from disk to ethernet device. But I don't think Windows has anything like that. I certainly don't *see* any benefit, in my limited testing on this set of hardware. If this *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. There might be a bug lurking somewhere. Could you create a very simple testcase which basically behaves like ftpd for debugging? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Corinna Vinschen wrote: On Apr 30 01:58, Charles Wilson wrote: Well, one of the differences between ftpd-1.3.2 and ftpd-1.5 is that the newer version uses mmap on the (local) file. ftpd.c is the /only/ source file in inetutils that uses mmap. Ok, so the ftpd using mmap is faster, one way or another. Not according to my numbers: mmap, topo 1, 4k buffers: 9-10 Mbps mmap, topo 2, 4k buffers: 14-15 Mbps NO mmap, topo 1, 4k bufs: 9-10 Mbps NO mmap, topo 2, 4k bufs: 14-15 Mbps If [disabling mmap] *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. There might be a bug lurking somewhere. Could you create a very simple testcase which basically behaves like ftpd for debugging? attached. gcc -o server server.c gcc -o client client.c Add an entry to /etc/services on both machines, like: example 22725/tcp or you could edit the two files and use a hardcoded port number, instead of a service name and getservbyname() And don't forget to open a hole in your server machine's firewall for that port. On the server machine, invoke as: $ server filename This file is the one that will be transferred to the client. This works for me: $ dd if=/dev/urandom of=ReallyBigFile bs=1M count=250 On the client: $ client hostname_of_server filename filename is where the client will save the transferred data. server is a traditional daemon, which forks off a copy to handle each new connection. That copy is the one you want to debug/strace/whatever. With this pair of programs, I saw sane memory usage in all cases when NOT using mmap, and I saw insane memory usage for all mmap cases except when blocksize was 1k. To switch among the various cases, edit the server.c file to #define/#undef HAVE_MMAP, and change the value of LARGE_TRANSFER_BLOCKSIZE. -- Chuck ftpd-mmap-troubles.tar.bz2 Description: Binary data -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On Apr 28 19:44, Charles Wilson wrote: Charles Wilson wrote: Yeah, I'll code that up for 1.5-4. Should I stick with BUFSIZ == 1024, or when MMAP use something a little bigger, say 32k? Also, uploads to the server seem to be sane (e.g. read() from the server side). So it's just downloads to the client when HAVE_MMAP. The fix was pretty easy: #ifdef HAVE_MMAP #include sys/mman.h +# ifdef __CYGWIN__ + /* On cygwin, network transfers are limited to an absolute + maximum of 64k, or transfer fails with ENOBUFS. Conservative: */ +# define LARGE_TRANSFER_LIMIT 32768 +# endif #endif In theory that looks fine, I just don't like the comment. This is not Cygwin's fault in the first place and it's not Cygwin returning ENOBUFS when you use too big send calls in the first place. Also, Cygwin does not return ENOBUFS for writes 64K. The 1.5 versions lets you do what you want and you have to deal with Winsock's behaviour directly. The 1.7 version just sends a maximum of 64K regardless of the incoming buffer size. It doesn't refuse the write completely. Eventually we should do our own write buffer management in Cygwin so you won't have to care. Brian Ford is looking into it, afaik. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
antony baxter wrote: Better, in the sense that I can now retrieve the file; however ftpd.exe's memory usage (monitored via Task Manager) now grows continously during the transfer until eventually the server machine grinds to a halt, paging furiously. Once the transfer does finally finish ftpd.exe's memory usage drops back to normal (2,400K). Hmm. A little more research shows winsock's internal behavior -- transfers, waitiong for ack, allocating internal buffers -- is very sensitive to the size of so_sndbuf (winsock default 8192) and the packet size (ethernet default 1560). See if one of these options gives better performance: 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) Also, what is the value of HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
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,7162,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,0002,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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles, Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). Squawk! Unfortunately, with XP SP2, Cygwin 1.5 as the server machine, I get pretty much the same symptoms with each of the above ftpds serving up a 350mb file: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Sorry! 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles, Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). Charles, Unless somebody squawks loudly and soon, I'm going to release inetutils-1.5-4 using 4k buffers for ftpd send_data(). Squawk! Unfortunately, with XP SP2, Cygwin 1.5 as the server machine, I get pretty much the same symptoms with each of the above ftpds serving up a 350mb file: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Quick addendum: I copied over in.ftpd.exe from another Cygwin installation running inetutils 1.3.2 and symlinked it to ftpd on my server; using that to serve the same file, memory usage sticks at 3500kb, cpu usage never rises about 5%, and the file was delivered in 194 seconds. 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
antony baxter wrote: Unfortunately, with XP SP2, Cygwin 1.5 as the server machine, I get pretty much the same symptoms with each of the above ftpds serving up a 350mb file: 1. In all cases, the ftpd process' memory usage increases to ~350mb, 2. As the buffer value decreases, the process' cpu usage increases (ftpd-1k.exe used about 75% of the cpu vs. about 10% for ftpd-8k.exe), 3. Performance jumped around (ftpd-1k transferred the file in 90seconds, ftpd-4k in 166 seconds, ftp-8k in 114 seconds on a wired network) Quick addendum: I copied over in.ftpd.exe from another Cygwin installation running inetutils 1.3.2 and symlinked it to ftpd on my server; using that to serve the same file, memory usage sticks at 3500kb, cpu usage never rises about 5%, and the file was delivered in 194 seconds. Well, one of the differences between ftpd-1.3.2 and ftpd-1.5 is that the newer version uses mmap on the (local) file. ftpd.c is the /only/ source file in inetutils that uses mmap. So, I recompiled with HAVE_MMAP turned off (but still using 4k chunks). Give this a try: http://cygwin.cwilson.fastmail.fm/ITP/ftpd-no-mmap-4k.exe.bz2 I get behavior here which is very similar to what I reported for the 4k-WITH-mmap version: (1) sane memory profile (2) topology one, 9-10 Mbps 2-3% cpu (3) topology two, 14-15 Mbps, 4-6% cpu [*] I'm not sure what benefit mmap has in this case -- unless you can exploit some zero-copy kernel code for transferring data from disk to ethernet device. But I don't think Windows has anything like that. I certainly don't *see* any benefit, in my limited testing on this set of hardware. If this *does* fix the problem, it may point to an issue with cygwin-1.5's mmap implementation, or with XP's handling of the underlying NtCreateSection()...mmap is not supposed to be CPU-intensive. -- Chuck [*] However, with the mmap'ed, 4k buffer version, I also saw only 4-6% CPU utilization on Vista, cygwin-1.7. So, YMMV. -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
antony baxter wrote: ftp get BCUpdateXP.exe 'EPSV': command not understood. local: BCUpdateXP.exe remote: BCUpdateXP.exe 227 Entering Passive Mode (192,168,1,99,4,110) 150 Opening BINARY mode data connection for 'BCUpdateXP.exe' (226020663 bytes). 0% | | 0 0.00 KB/s--:-- ETA 426 Data connection: No buffer space available. This means that very first call to the cygwin1.dll function 'write(int networkSocketFd, const void *buf, size_t nbyte)' failed for some reason: ENOBUFS is not one of the valid error codes for write(), so it's set to that by something internal to cygwin's implementation of write(). e.g. smells like a cygwin (or windows) bug -- cygwin is unable to create a Mutex or an Event for managing the socket communications (e.g. CreateMutex or CreateEvent in net.cc: (handler_socket::init_events) failed) I'm wondering if you have different versions of cygwin on the two machines -- not that it should matter, but if so then the answer may be simple. Can you send -- as attachments, not cut-n-paste -- the result of 'cygcheck -s -v -r' on each of the two cygwin machines? -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
On Apr 28 03:06, Charles Wilson wrote: antony baxter wrote: ftp get BCUpdateXP.exe 'EPSV': command not understood. local: BCUpdateXP.exe remote: BCUpdateXP.exe 227 Entering Passive Mode (192,168,1,99,4,110) 150 Opening BINARY mode data connection for 'BCUpdateXP.exe' (226020663 bytes). 0% | | 0 0.00 KB/s--:-- ETA 426 Data connection: No buffer space available. This means that very first call to the cygwin1.dll function 'write(int networkSocketFd, const void *buf, size_t nbyte)' failed for some reason: ENOBUFS is not one of the valid error codes for write(), so it's set to that by something internal to cygwin's implementation of write(). e.g. smells like a cygwin (or windows) bug -- cygwin is unable to create a Mutex or an Event for managing the socket communications (e.g. CreateMutex or CreateEvent in net.cc: (handler_socket::init_events) failed) This code only exists in 1.7. The only way to get ENOBUFS in 1.5.x is when Winsock emits it. I see two possible reasons. One is a third-party firewall software which interacts badly with ftpd on the machine with the ENOBUFS problem, the other is ftpd itself. Does ftpd from 1.5 try to write the 215 Megs in one single write call, by any chance? We had this discussion lately and I added a stop-gap measure into 1.7 so that no write to the net writes more than 64K in one go. The problem is that Winsock unintelligibly tries to create a temporary internal buffer the size of the write buffer, regardless of its size. Naturally that can fail, and if it does, you get the error code WSAENOBUFS. The only way around that for 1.5 is to split network writes to smaller chunks. Doing that is much faster on Windows, too, btw. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Corinna Vinschen wrote: This code only exists in 1.7. The only way to get ENOBUFS in 1.5.x is when Winsock emits it. I see two possible reasons. One is a third-party firewall software which interacts badly with ftpd on the machine with the ENOBUFS problem, the other is ftpd itself. Does ftpd from 1.5 try to write the 215 Megs in one single write call, by any chance? Why, yes, yes it does. But only if #HAVE_MMAP; otherwise it's a little more sane and uses BUFSIZ from stdio.h; 1024. We had this discussion lately and I added a stop-gap measure into 1.7 so that no write to the net writes more than 64K in one go. The problem is that Winsock unintelligibly tries to create a temporary internal buffer the size of the write buffer, regardless of its size. Naturally that can fail, and if it does, you get the error code WSAENOBUFS. The only way around that for 1.5 is to split network writes to smaller chunks. Doing that is much faster on Windows, too, btw. Yeah, I'll code that up for 1.5-4. Should I stick with BUFSIZ == 1024, or when MMAP use something a little bigger, say 32k? -- 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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles Wilson wrote:
Yeah, I'll code that up for 1.5-4. Should I stick with BUFSIZ == 1024,
or when MMAP use something a little bigger, say 32k?
Also, uploads to the server seem to be sane (e.g. read() from the server
side). So it's just downloads to the client when HAVE_MMAP. The fix was
pretty easy:
#ifdef HAVE_MMAP
#include sys/mman.h
+# ifdef __CYGWIN__
+ /* On cygwin, network transfers are limited to an absolute
+ maximum of 64k, or transfer fails with ENOBUFS. Conservative: */
+# define LARGE_TRANSFER_LIMIT 32768
+# endif
#endif
...
do
{
- cnt = write (netfd, bp, len);
+#ifdef __CYGWIN__
+ /* on cygwin, socket write is limited to 64k max */
+ cnt = write (netfd, bp, (len LARGE_TRANSFER_LIMIT ? len :
LARGE_TRANSFER_LIMIT));
+#else
+ cnt = write (netfd, bp, len);
+#endif
len -= cnt;
bp += cnt;
if (cnt 0) byte_count += cnt;
} while (cnt 0 len 0);
antony, please test the following:
http://cygwin.cwilson.fastmail.fm/ITP/ftpd.exe.bz2
--
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/
Re: inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Charles, antony, please test the following: http://cygwin.cwilson.fastmail.fm/ITP/ftpd.exe.bz2 Better, in the sense that I can now retrieve the file; however ftpd.exe's memory usage (monitored via Task Manager) now grows continously during the transfer until eventually the server machine grinds to a halt, paging furiously. Once the transfer does finally finish ftpd.exe's memory usage drops back to normal (2,400K). 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/
inetutils 1.5 / ftpd problem: 426 Data connection: No buffer space available.
Hi, Problem Description: 2 PCs, both up to date Cygwin DLL, one running inetutils 1.5, the other running inetutils 1.3.2, plus a third computer (probably not important, but MacOSX). The PC with inetutils 1.5 has a largish (215MB) file on it, which I want to get from the OSX computer: [EMAIL PROTECTED] (.../ant/Downloads) % ftp xp-ant1 Connected to xp-ant1. 220- 220- Welcome to xp-ant1... 220 xp-ant1 FTP server (GNU inetutils 1.5) ready. 331 Password required for ant. 230- Fanfare!!! 230- You are successfully logged in to this server!!! 230 User ant logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp cd /mnt/downloads 250 CWD command successful. ftp bin 200 Type set to I. ftp get BCUpdateXP.exe 'EPSV': command not understood. local: BCUpdateXP.exe remote: BCUpdateXP.exe 227 Entering Passive Mode (192,168,1,99,4,110) 150 Opening BINARY mode data connection for 'BCUpdateXP.exe' (226020663 bytes). 0% | | 0 0.00 KB/s--:-- ETA 426 Data connection: No buffer space available. I copied the file over to the other PC running inetutils 1.3.2, and then ftp-ing in from my Mac and getting it worked fine: ... 220 xp-ant2 FTP server (GNU inetutils 1.3.2) ready. ... ftp get BCUpdateXP.exe 'EPSV': command not understood. local: BCUpdateXP.exe remote: BCUpdateXP.exe 227 Entering Passive Mode (192,168,1,187,5,22) 150 Opening BINARY mode data connection for 'BCUpdateXP.exe' (226020663 bytes). 100% || 215 MB9.80 MB/s00:00 ETA 226 Transfer complete. 226020663 bytes received in 00:22 (9.78 MB/s) Had a read through the docs but couldn't see anything that would specifically address this; I'm not using tcp-wrappers as I'm in a secure environment, the inetutils 1.5 ftp server machine is XP SP2 running in VMware (as is the other running 1.3.2), its a fresh install. Can anyone else reproduce this? I can easily downgrade the server to 1.3.2 so no great problem, but it would be good to solve this. Thanks Ant.q -- 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/
