From: Daniel Havey <dhavey@gmail.com>
To: Brian.Inglis@systematicsw.ab.ca, cygwin@cygwin.com
Subject: Re: Cygwin TCP slow
Date: Wed, 30 Nov 2016 09:16:00 -0000 [thread overview]
Message-ID: <CAO1c0ARyXv76_7WO3mvZFjmZ1yYw8Q8bcz5e37YpuVmqhJwejg@mail.gmail.com> (raw)
In-Reply-To: <5adc37f5-608b-6c1f-6d14-83343c82dc9f@SystematicSw.ab.ca>
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?
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.
[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.
thanxs :)
...Daniel
On Mon, Nov 28, 2016 at 12:51 PM, Brian Inglis
<Brian.Inglis@systematicsw.ab.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.
>
> --
> 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
next prev parent reply other threads:[~2016-11-30 1:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 1:25 Daniel Havey
2016-11-29 5:56 ` Brian Inglis
2016-11-30 9:16 ` Daniel Havey [this message]
2016-11-30 10:09 ` Sam Habiel
2016-11-30 10:44 ` Brian Inglis
2016-11-30 16:00 ` Lee
[not found] ` <CAD8GWss1zb1J7m3Knf1TGuAPcVKQVNFXgt2uX02o_Z08ZOfEOw@mail.gmail.com>
2016-12-02 20:29 ` Daniel Havey
2016-12-02 22:37 ` Brian Inglis
2017-01-04 21:33 ` Daniel Havey
2016-12-02 23:08 ` Mark Geisert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAO1c0ARyXv76_7WO3mvZFjmZ1yYw8Q8bcz5e37YpuVmqhJwejg@mail.gmail.com \
--to=dhavey@gmail.com \
--cc=Brian.Inglis@systematicsw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).