X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=iSC8Jf3
	M99zn6SKAGS3sLBGAOyLN9Vds8D2GCrLWauU/ZfhnoohPulo6zJd2oOTU25EwKgT
	2Bv04V+6TSKUX4iHg2wc5m2+qB323kCzzbondJB1fLRYfKXlwMPAL7P21c4zmJX/
	MtwSLuaQsyoDkE6fTB50MB2RUm8U0zkvAhx4=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=m1MX88lS9zWm/
	l2tkJjMGzuR66Q=; b=YfqkOy8k49nvGWDr8bf4xVBUmLp1WLmNPFs7c9CS1fjr9
	gSXzm/XTHtew4AUl02tbnLKNlHBZ4ZNuC/BH8qBmrGw5wL/joKw5pjkcZa2qu2Pr
	1ta5mmsu3yv0SvtasIsHxYHIbv6czbQNBbUtwoEvws3OUJ9YK0/GgXOpQQBHF0=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=soviet, Soviet, Non, Education
X-HELO:	mail-qt0-f177.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=BW+cqBlL6dV8ilFHnY0FsuhiuB5LT1attFgvGXpY2uo=; b=NzN+xNFeHAzCYEIFl5szHj10aQwDEb6IjcBIUuc2cxt3YtHECgU2l9xe0R6szMxYHj TkZM/SdT98YOw27ocufhAEEhxkI9Mqi0WGM++l7RDH5sngTjPL6/E/fUY9i7hStjs7nX PsfmIAPlGFnM800+QumvnMNj5XE1QfzldHoHcxMjVto16TM4hYjU5o5tA5XgWcSlL13+ G1o8dGBLozcsMtfJLxr84GjBUMdM1LzMHq/shnSohHHMikrjZYoY3zFVwWTSg9Gv5qu4 yVXvs3lcRDH73VlYUxAXXnQr1r5SUTCF5FaDwqbAEV/QvAhE5Z/7hGGqXnqWVou05eOM 3fug==
X-Gm-Message-State:	AIkVDXJbxS81+3bqpRqyfe/FAoUXRQSQJblDUI2pYoB/N/fiEYuG88HygdeXnKq5do8ZsLFQN7m5sVqU/40v1g==
X-Received:	by 10.200.57.36 with SMTP id s33mr55451083qtb.210.1483565571856; Wed, 04 Jan 2017 13:32:51 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<820fa59f-a268-0a6c-e1d4-844ad0b7e0a3@SystematicSw.ab.ca>
References:	<CAO1c0AT52ZzCKc3yD_7eX6ri4VubrTb5L+X-4vHWoXBAX2jsfw AT mail DOT gmail DOT com> <5adc37f5-608b-6c1f-6d14-83343c82dc9f AT SystematicSw DOT ab DOT ca> <CAO1c0ARyXv76_7WO3mvZFjmZ1yYw8Q8bcz5e37YpuVmqhJwejg AT mail DOT gmail DOT com> <CABHT963SLLrcAxNgD+bUEarohJNj=M=HA34S_2mG86OfLCO3=A AT mail DOT gmail DOT com> <96dd675e-5b75-aced-0762-c67e96d33f67 AT SystematicSw DOT ab DOT ca> <CAD8GWss1zb1J7m3Knf1TGuAPcVKQVNFXgt2uX02o_Z08ZOfEOw AT mail DOT gmail DOT com> <CAO1c0AR9SPdvq6tVifZ18Ev+vp9oWd0wThbj0BqeLPk9qVmTFA AT mail DOT gmail DOT com> <820fa59f-a268-0a6c-e1d4-844ad0b7e0a3 AT SystematicSw DOT ab DOT ca>
From:	Daniel Havey <dhavey AT gmail DOT com>
Date:	Wed, 4 Jan 2017 13:32:51 -0800
Message-ID:	<CAO1c0AQkkjZKHaKijcWV0mmAOEBzORES+FpiB2BGsBPe1bOajg@mail.gmail.com>
Subject:	Re: Cygwin TCP slow
To:	Brian DOT Inglis AT systematicsw DOT ab DOT ca, cygwin AT cygwin DOT com
X-IsSubscribed:	yes

Resending in plain text:

Hey Brian,
I took a little time off for Christmas.
The official Windows guidance for autotuning is here.
https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/
Please don't turn off Window Scaling.  The RFC for Window Scaling was
standardized in 1992 when Microsoft was selling Windows 3.1 and I was
using an external USR 14.4Kbs modem.  I've never even seen hardware
that is actually slower when Window Scaling is enabled, but, I have
seen cases where software (cygwin1.dll) manually sets the window size
and slows down the Internet speed achieved by a user.  Do you have an
STC?

1.) I don't know any of those reg keys.  They are not supported in Windows 10.
2.) netsh interface tcp show global.  This is okay, but, I typically
use the newer powershell version: Get-NetTCPSettings.
3.) WinInet and WinHTTP both leave Window Scaling at the default
Windows setting.  (Please don't disable window scaling :)).
4.) Progress on the patch that removes the buffering commands:  I am
waiting for legal to give me the go ahead.  Now that Christmas is over
I should be able to get closure on this.
5.) I don't know anything about the Bandwidth Reservation GPOs.  We
have LEDBaT and recommend for bandwidth flows.  Here is a list of the
new anniversary update features on our blog.
https://blogs.technet.microsoft.com/networking/2016/07/18/announcing-new-transport-advancements-in-the-anniversary-update-for-windows-10-and-windows-server-2016/
I will be updating the blog with the new features included in our next
update soon :).

thanxs ;^)

On Fri, Dec 2, 2016 at 2:37 PM, Brian Inglis
<Brian DOT Inglis AT systematicsw DOT ab DOT ca> wrote:
> On 2016-12-02 13:29, Daniel Havey wrote:
>> On Wed, Nov 30, 2016 at 1:13 PM, Lee <ler762 AT gmail DOT com> 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 <host name>
>>> 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 <host name>
>>> 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
>

--
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

- Raw text -