| delorie.com/archives/browse.cgi | search |
| 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:subject:references:to:reply-to:from:message-id | |
| :date:mime-version:in-reply-to:content-type | |
| :content-transfer-encoding; q=dns; s=default; b=a7rdy7UakpFYXLRu | |
| fuvRS6c0sSSghUOvht2nTJTsMOvrHdRXaPF4YLas0llgf738v42GlFYQKuxoAenF | |
| V8BFJu+/+39VscsrVJHfQ9ct6T4L/RzaRN01C5BJdKx+pjF0Nfud8HMu2rONExzE | |
| KBlDRRVtHFJrHG4vjo0XjSIo2UU= | |
| 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:subject:references:to:reply-to:from:message-id | |
| :date:mime-version:in-reply-to:content-type | |
| :content-transfer-encoding; s=default; bh=ZSc9rGGCZfWErpddEyN+bM | |
| HBgTw=; b=eTS0cEtSl/zTX+ffa5hs9YUekBirD1jnCphEDb/4wdFyQydkAU/wzE | |
| CFB6U30nFUWNFl1EzRS1tTM0TnUqm44zMNSU0I2kbJXys3FaUxsWCEIsou44ma3X | |
| zs1oUxNCvggKbaRAlhcp7hCGuxlo4M4V2mxD+u9fWvXIZpGIHOc3c= | |
| 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=0.3 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:shaw.ca, H*r:shaw.ca, H*RU:shaw.ca, H*R:D*ca |
| X-HELO: | smtp-out-so.shaw.ca |
| 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=w_pzkKWiAAAA:8 a=ZCNKn-Z_-mKWEn-bwO0A:9 a=QEXdDO2ut3YA:10 a=buB1NfXUTBUA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=sRI3_1zDfAgwuvI8zelB:22 |
| Subject: | Re: Cygwin TCP slow |
| 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> |
| To: | cygwin AT cygwin DOT com |
| Reply-To: | Brian DOT Inglis AT SystematicSw DOT ab DOT ca |
| From: | Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca> |
| Message-ID: | <96dd675e-5b75-aced-0762-c67e96d33f67@SystematicSw.ab.ca> |
| Date: | Tue, 29 Nov 2016 21:27:55 -0700 |
| User-Agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 |
| MIME-Version: | 1.0 |
| In-Reply-To: | <CABHT963SLLrcAxNgD+bUEarohJNj=M=HA34S_2mG86OfLCO3=A@mail.gmail.com> |
| X-CMAE-Envelope: | MS4wfCTycFO6zkZVxqmcTUHrkatt7FByURXuRg2B7b7QvDa51qZ9X1TlVKKLdFiKThSyYQXDnESHnB1oDjMsLA3uKFEsILBWuPUnbmRh7/hR31yaZMbXpJ4M VDUIuGFTh6L3qOrWkJJsVAkAVQrr+5pRUnXWXwTlY57Pet0PDQPqlaygwF4tRDg+QWC9ooyHZILc6A== |
| X-IsSubscribed: | yes |
On 2016-11-29 19:38, Sam Habiel wrote: > On Tue, Nov 29, 2016 at 8:08 PM, Daniel Havey <dhavey AT gmail DOT com> wrote: >> On Mon, Nov 28, 2016 at 12:51 PM, Brian Inglis >> <Brian DOT Inglis AT systematicsw DOT ab DOT ca> wrote: >>> On 2016-11-28 12:54, Daniel Havey wrote: >>>> We have had complaints from several large hardware vendors >>>> that Windows networking is slow for apps like iperf that are >>>> used to measure throughput. Iperf on Windows is compiled >>>> against the cygwin1.dll. We have root caused the problem to a >>>> couple of lines of code in net.cc that set SO_RCVBUF and >>>> SO_SNDBUF to about 200KB. >>>> >>>> The theoretical window/RTT plot for the buffer size set by Cygwin >>>> (0x34000 = 200KB) gives us: >>>> 1ms -> 1703Mbps >>>> 2ms -> 851Mbps >>>> 3ms -> 567Mbps >>>> 4ms -> 425Mbps >>>> 5ms -> 340Mbps >>>> 6ms -> 283Mbps >>>> 7ms -> 243Mbps >>>> 8ms -> 212Mbps >>>> 9ms -> 189Mbps >>>> 10ms -> 170Mbps >>>> 20ms -> 85Mbps >>>> 40ms -> 42Mbps >>>> 60ms -> 28Mbps >>>> 80ms -> 21Mbps >>>> >>>> We have confirmed this by experiment and also confirmed that >>>> the limitation goes away if the buffers are not manually set. >>>> Windows has autotuning and when the buffers are set manually >>>> the autotuning is disabled. This is causing the throughput >>>> limitation. So we would like to formally ask that you please >>>> not manually set SO_RCVBUF or SO_SNDBUF. >>> >>> See problem reports: http://cygwin.com/problems.html >>> Provide STC, patches, attach cygcheck -svr output? >>> Links to downstream bug reports, testing, results? >>> Note that Cygwin iperf is year old 2.0.5. >> Okay, I will find some time to produce a patch. It might take a >> while though because I have a day job :). BTW, what the heck is an >> STC? STC == Simple Test Case >> Here is an experiment with three machines like this: O----O----O >> The one in the middle has a 50ms of delay (25ms in each direction). >> >> Here are the results from Cygwin on top of normal Windows: >> [send side perf] >> f:\home>iperf3 -c 10.178.204.101 >> [ ID] Interval Transfer Bandwidth >> [ 4] 0.00-10.00 sec 47.5 MBytes 39.8 Mbits/sec sender >> [ 4] 0.00-10.00 sec 47.5 MBytes 39.8 Mbits/sec receiver >> >> [receive side perf] >> f:\home>iperf3 -c 10.178.204.101 -R >> [ ID] Interval Transfer Bandwidth Retr >> [ 4] 0.00-10.00 sec 41.2 MBytes 34.5 Mbits/sec 0 sender >> [ 4] 0.00-10.00 sec 39.7 MBytes 33.3 Mbits/sec receiver >> >> This matches the calculated performance. Then we made a private >> build of Windows that ignores SO_RCVBUF and SO_SNDBUF and just >> always uses autotuning no matter what the app does. > Out of curiosity, how did you do that? Do you work for Microsoft, or > is there something fantastic I missed about building your own > modified DLLs? Or is this an Enterprise or Insider build with specific GPOs or reg entries that could be applied on any Windows release? You state the basics nowhere - Windows release and flavour, Cygwin release and arch, installed packages, DLLs, et al. That's the reason for the problem reports web page asking for cygcheck -svr output to be attached, and the lack of any attachment may mean your post may be ignored by the tiny group of very busy Cygwin volunteers. If the problem is on XP, Cygwin no longer supports it, and if it only occurs on Vista or 8, and not reproducible on 7 or 10, it may be weighed accordingly. If it only affects artificial benchmarks like iperf3 and not real network apps like say rsync, netcat, etc. it may be not be considered high enough impact to look at, among higher priorities. If you could reproduce this with an available package like rsync and equivalent settings, it may get higher priority. If you also provided a Cygwin port of iperf3 you could win a *Gold Star* from the Cygwin volunteers who may then be able to reproduce your results. >> [send side perf] >> C:\testbox\tests>iperf3 -c 10.178.204.101 >> [ ID] Interval Transfer Bandwidth >> [ 4] 0.00-10.00 sec 540 MBytes 453 Mbits/sec sender >> [ 4] 0.00-10.00 sec 540 MBytes 453 Mbits/sec receiver >> >> [receive side perf] >> C:\testbox\tests>iperf3 -c 10.178.204.101 -R >> [ ID] Interval Transfer Bandwidth Retr >> [ 4] 0.00-10.00 sec 553 MBytes 464 Mbits/sec 0 sender >> [ 4] 0.00-10.00 sec 553 MBytes 464 Mbits/sec receiver >> >> If you set SO_RCVBUF and SO_SNDBUF then performance will be >> limited according to the calculated values. If you don't set those >> values and let Windows autotuning do its thing then you will always >> get the maximum available throughput. >> >> I'll email again when I have the patch. If you would like more >> testing let me know and we can have our test people run some more >> experiments. If you attach cygcheck -svr output, and can reproduce in a STC with an available widely used Cygwin package, you are more likely to get read by one of the Cygwin committers or volunteers who can help. -- 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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |