Re: Cygwin TCP slow

[Mark Geisert]

Daniel Havey wrote:

2.) Here is the cygcheck.out file with all that information.
The make is failing because of some device configuration.

/home/dahavey/oss/src/newlib-cygwin/winsup/cygwin/gendevices: shilka
command missing? - No such file or directory
make[3]: *** [Makefile:720:
/home/dahavey/oss/src/newlib-cygwin/winsup/cygwin/devices.cc] Error 2
make[3]: Leaving directory
'/home/dahavey/oss/build/x86_64-unknown-cygwin/winsup/cygwin'
make[2]: *** [Makefile:81: cygwin] Error 1
make[2]: Leaving directory
'/home/dahavey/oss/build/x86_64-unknown-cygwin/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '/home/dahavey/oss/build'
make: *** [Makefile:883: all] Error 2

/home/dahavey/oss/src/newlib-cygwin/winsup/cygwin/gendevices doesn't
exist in the sources that I downloaded from the cygwin website using:
git clone git://sourceware.org/git/newlib-cygwin.git
Something is not right here :).


The canonical build instructions for the Cygwin DLL are in the FAQ...
https://cygwin.com/faq.html#faq.programming.building-cygwin

You might want to look over the first paragraph there to avoid stumbling over 
the next requirement ;)


..mark


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin TCP slow

[Brian Inglis]

On 2016-12-02 13:29, Daniel Havey wrote:
> On Wed, Nov 30, 2016 at 1:13 PM, Lee  wrote:
>> I don't know if this qualifies as a simple test case, but if you
>> don't already have wireshark, get it from
>> https://www.wireshark.org/download.html
>> get iperf-2.0.9.tar.gz from https://sourceforge.net/projects/iperf2/files/
>> change the setsockopt calls on lines 125 & 132 of
>> src/tcp_window_size.c to
>>   rc = 0;
>> ./configure  --prefix=/usr/local
>> make && make install
>> start wireshark & add a column for bytes in flight:
>> edit / preferences
>> appearance / columns
>> click on the "+" button to get a new row
>> double click on the "New Column", type BIF
>> double click the empty bit in the Fields column
>> type tcp.an which pulls up a pick list; click on
>> tcp.analysis.bytes_in_flight
>> click on OK
>> find a public iperf server -- I got lucky & found one ~65ms away,
>> so thruput is going to be constrained by the 130ms round trip
>> time. start the wireshark capture
>> iperf  -c 
>> when it's done stop the capture & click on the BIF column header
>> What I get is a max bytes in flight of 66560
>> recompile iperf using the windows cross-compiler
>> make clean
>> make distclean
>> ./configure  --prefix=/usr/local --build=i686-pc-cygwin 
>> --host=i686-w64-mingw32
>> make && make install
>> start capturing
>> iperf  -c 
>> when it's done stop the capture & sort on the BIF column
>> What I get is a max bytes in flight of 196608
>> So, for me, it's about a 3X difference between the native & cygwin
>> app.
>> If the problem really is in net.cc as the OP said, have a look at
>> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/net.cc;h=e4805d3e11c3cea09b1cdfa27170dfe626265125;hb=HEAD
>> starting at line 587
>> /* Raise default buffer sizes (instead of WinSock default 8K).
>> I think starting with Windows Vista the default is tcp autotuning.
>> So unless there's some other reason for setting the send/receive
>> buffer it seems that cygwin apps would be better off going with the
>> defaults.

> 0.) I don't care about XP at all and I care only a little about
> other downlevel products. (The further downlevel the less I care :)).
> It's Windows 10 from now until forever. There will be no eleven.
> 1.) Yes, I am the program manager for Windows TCP/IP and I want to 
> make the Internet a better place for everyone by setting the
> transport buffers correctly.
> 2.) Here is the cygcheck.out file with all that information. The make
> is failing because of some device configuration.
> 
> /home/dahavey/oss/src/newlib-cygwin/winsup/cygwin/gendevices: shilka
> command missing? - No such file or directory
> make[3]: *** [Makefile:720:
> /home/dahavey/oss/src/newlib-cygwin/winsup/cygwin/devices.cc] Error 2
> make[3]: Leaving directory
> '/home/dahavey/oss/build/x86_64-unknown-cygwin/winsup/cygwin'
> make[2]: *** [Makefile:81: cygwin] Error 1
> make[2]: Leaving directory
> '/home/dahavey/oss/build/x86_64-unknown-cygwin/winsup'
> make[1]: *** [Makefile:9464: all-target-winsup] Error 2
> make[1]: Leaving directory '/home/dahavey/oss/build'
> make: *** [Makefile:883: all] Error 2
> 
> /home/dahavey/oss/src/newlib-cygwin/winsup/cygwin/gendevices doesn't 
> exist in the sources that I downloaded from the cygwin website
> using: git clone git://sourceware.org/git/newlib-cygwin.git
> Something is not right here :).
> 
> 3.) No point in going further until this problem is sorted out.

Install cocom package which includes shilka, and other utilities named 
after Soviet weapons. See newlib-cygwin/winsup/doc/fhandler-tut.txt
 
> 4.) This is a little random to the thread, but, does anybody know
> who I might talk to about getting email addresses taken out of the
> spam filter on the mailing lists? I suspect that every address 
> @microsoft.com is being filtered. I don't know why this happened, 
> but, it does seem a little draconian to spam filter all 100,000 of
> us :). Also it's a pain in the but to use @gmail for business and it 
> further slows the process.

See https://sourceware.org/lists.html for policies and contacts. 
Only plain text *ONLY* email is accepted - HTML, some MIME content, 
some attachments, confidentiality, privacy, or disclaimer notices will 
get email bounced or just undelivered, as they don't want confidential, 
private, risky, or unreadable content posted, and can't guarantee it 
will get to the intended recipient if list members unsubscribe. ;^>
This often disqualifies using corporate email accounts for 
lists/groups with similar (auto-)moderation policies.
See http://www.frontierfleet.net/email/ for rationale, blocks, and 
workarounds. 

> 5.) Just FYI: I want the buffering done correctly for all apps that 
> use Windows so I am considering changing the behavior of Windows (no 
> downlevel support) to not mess up the buffers even if the app sets 
> SO_RCVBUF and/or SO_SNDBUF. This method is cool because it fixes the 
> problem for everyone who uses the new 

Re: Pre-compiled Perl::Critic ?

[Jim Reisert AD1C]

On Thu, Dec 1, 2016 at 12:55 PM, Achim Gratz wrote:

> Last I looked it pulled in a lot of dependencies that I don't really
> care to maintain.

Fair enough.  Thanks.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: remote GTK apps nor workin correctly in Cygwin/X

[Jon Turney]

On 30/11/2016 12:36, David Cunningham wrote:

I'm not sure if this is a cygwin problem, a gtk problem or something
else (please be gentle).


Thanks for reporting this issue.


I have 3 remote machines, one running servers, one running Ubuntu 16.04
and the other 2 Debian stretch.

[...]

Remote applications on the Debian machines from a Cygwin xterm (or
putty) don't work correctly. An application (gnome-terminal and nemiver
being the two mostly use) will open correctly and keyboard is (mostly)
OK but mouse input doesn't work.

For example clicking a menu heading will place a line under the heading
in the GUI but the menu doesn't open. Note that I get the same failure
when using the keyboard shortcut keys (e.g ALT-F <> File). Sometimes a
part of the menu (maybe one or 2 lines) will appear in the top left of
the Desktop and can be scrolled through and selected using the keyboard.
The window controls (minimise, maximise, exit) work correctly.


I can reproduce this using a debian stretch VM.

It occurs with the cygwin X server in both windowed and multiwindow 
mode, so that would seem to exonerate the cygwin multiwindow mode WM.


The menus work correctly using the debian X server with no WM, though.


I get (lots of ) GTK error messages in terminal like this as I try to
use the GUI:

[...]

I've come across this bug filed against gtk in Debian which seems
somewhat similar:

.

I'm unclear then whether this is a Debian/gtk issue or a Cywin/X issue
(given that Ubuntu->Debian is OK).


I'm pretty sure this is more fallout from the change mentioned in the 
upstream bug [1] linked there, but why it only manifests under the 
cygwin X server, I don't know.


[1] https://bugzilla.gnome.org/show_bug.cgi?id=773387


Can anyone advise where I go from here?


I would suggest perhaps raising a bug against gtk+, although idk how 
much attention that will get.


--
Jon Turney
Volunteer Cygwin/X X Server maintainer

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple