From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30289 invoked by alias); 28 Nov 2016 20:51:18 -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 30206 invoked by uid 89); 28 Nov 2016 20:51:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_20,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, Hx-spam-relays-external:!192.168.1.100! X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Nov 2016 20:51:06 +0000 Received: from [192.168.1.100] ([174.0.238.184]) by shaw.ca with SMTP id BStDcw4xgm7BbBStEcwHMV; Mon, 28 Nov 2016 13:51:04 -0700 X-Authority-Analysis: v=2.2 cv=XqWKARN9 c=1 sm=1 tr=0 a=WqCeCkldcEjBO3QZneQsCg==:117 a=WqCeCkldcEjBO3QZneQsCg==:17 a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=J1_jgBw0DZDVExNvRqgA:9 a=QEXdDO2ut3YA:10 a=buB1NfXUTBUA:10 a=sRI3_1zDfAgwuvI8zelB:22 Subject: Re: Cygwin TCP slow References: To: cygwin@cygwin.com From: Brian Inglis Reply-To: Brian.Inglis@SystematicSw.ab.ca Message-ID: <5adc37f5-608b-6c1f-6d14-83343c82dc9f@SystematicSw.ab.ca> Date: Tue, 29 Nov 2016 05:56:00 -0000 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHdmAIqVP/PCaaWKNp9m7LVxRBIZi4H5zUnAiLBI6vGH19Q5c0P2pO9a6qi7TDrsDvqYElnlCZ5po9TzC5V6Fubb0zNKgxX2DXQEoZM4k0/maKxPXDCM iE9wzG53D61n/k7wVZXZjjQLJgYjl4lf7hmKhYXFN4XnE0VIK1BnJmhYFBzQFy3i/7lonUOeqYk7Qw== X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00316.txt.bz2 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. -- 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