From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46555 invoked by alias); 2 Dec 2016 22:37:27 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 46541 invoked by uid 89); 2 Dec 2016 22:37:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Provider, Hx-spam-relays-external:shaw.ca, H*r:shaw.ca, H*RU:shaw.ca X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 22:37:16 +0000 Received: from [192.168.1.100] ([174.0.238.184]) by shaw.ca with SMTP id CwS8cgxBSIwqSCwS9cgsnt; Fri, 02 Dec 2016 15:37:15 -0700 X-Authority-Analysis: v=2.2 cv=cNuQihWN c=1 sm=1 tr=0 a=WqCeCkldcEjBO3QZneQsCg==:117 a=WqCeCkldcEjBO3QZneQsCg==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=cAXX2R3EAAAA:8 a=FP58Ms26AAAA:8 a=w_pzkKWiAAAA:8 a=CCpqsmhAAAAA:8 a=yMhMjlubAAAA:8 a=yd7d9MuRAAAA:8 a=aAcZxa1nJOexesNOnbkA:9 a=lAnoyzS4FyhlQJTY:21 a=N0MmapH0k6NttwFn:21 a=QEXdDO2ut3YA:10 a=gdYglN19eE0A:10 a=2wkYanB4cVUA:10 a=VRK7SkBfyHkA:10 a=7utUOSbz6MoA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=MTFir8XF8A10EAIrxktM:22 a=6LVbBl2NLSWPyIBDCKCu:22 a=sRI3_1zDfAgwuvI8zelB:22 a=ul9cdbp4aOFLsgKbc677:22 a=BKKCjISod1eDJeS0ORpz:22 a=2MYdOIn-Rl6PNOFFLamb:22 Subject: Re: Cygwin TCP slow References: <5adc37f5-608b-6c1f-6d14-83343c82dc9f@SystematicSw.ab.ca> <96dd675e-5b75-aced-0762-c67e96d33f67@SystematicSw.ab.ca> Reply-To: Brian.Inglis@SystematicSw.ab.ca To: cygwin@cygwin.com From: Brian Inglis Message-ID: <820fa59f-a268-0a6c-e1d4-844ad0b7e0a3@SystematicSw.ab.ca> Date: Fri, 02 Dec 2016 22:37:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNg7iDIdiJYpzbMnIG5DV3p3klYdzqtuY4y/TP+JYE5/dP/r4NaFHIZvIn3KoNXSzfkKaWzMHQXDBp265667yK7PeEUpWsXaldxreSTtkwaWGQRvDkYn 0a7/yPSp7eM0YBvdXGAWd2OM+NeOM7FDEJ4LEEG1TJRJwQGF4dUvipzN1PuqVGqLncusoD9MnY2sAg== X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00025.txt.bz2 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 Windows builds, but, I also > don't like to change standard behavior. Do Windows versions and flavours have accessible feature codes indicating when RFC 1323 TCP Window Scaling is available, active, and its parameters? I could see custom builds modifying desktop or VM setups to limit damage and load e.g. Education, Enterprise, and Insider messing around; and companies, vendors, and users setting GPOs or reg entries for apps that perform worse with Window Scaling and RFC 1323 non-compliant (old) equipment compatibility e.g. some Education and non-profit orgs. $ ls /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Internet\ Settings/WinHttp/TcpAutotuning ls: cannot access '/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Internet Settings/WinHttp/TcpAutotuning': No such file or directory So that is not an availability test. What is accessed by: $ netsh interface tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : enabled Chimney Offload State : disabled NetDMA State : disabled Direct Cache Access (DCA) : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : none ECN Capability : disabled RFC 1323 Timestamps : disabled Initial RTO : 3000 Receive Segment Coalescing State : disabled Non Sack Rtt Resiliency : disabled Max SYN Retransmissions : 2 TCP Fast Open : enabled For general Cygwin reference the following (elevated?) commands en-/disable WinHTTP RFC 1323 TCP Window Scaling: # netsh int tcp set global autotuninglevel=disabled # netsh int tcp set global autotuninglevel=normal Are there separate features and parameters for WinInet or other Windows flavours of network access, that affect their use of Window Scaling tweaks? How does that interact with Bandwidth Reservation GPOs or reg entries: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched == 0 And are there other settings, parameters, GPOs, or reg entries that also may affect the operation of TCP Window Scaling? > 6.) I will consider looking into iperf3 once we have solved the > problem in 2. Also there would be a much greater chance that these > things get solved more quickly if we could solve the problem in > number 4. One of my TCP devs likes cygwin and indicated a willingness > to help. However, I will not allow any of my dev team to get mixed > up with using @gmail accounts. Could cause too much trouble for the > youngster :) HTH -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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