Hello,
I recently had a customer complaining that the download speed from
Canada to Paris is bad. He got 150 Mbit/s and had a 1 Gbit line with a
single connection. Both systems were Windows Server 2016. Proprietary
Application. This was for 80ms latency link. After some testing I found out
that Windows sizes the tcp window size to small. It was 256 KB. So in order to
test it, you need a system with a high latency and a big pipe. I did for
testing provision two Windows Server 2016 at AWS. One in Paris, one in Canada.
And did some testing using chrome, internet explorer, and iperf3 (You need the
newest version where you can set the TCP window size).

My conclusion was that if you use an untuned program. The TCP Window
size will never exceed 256 KB no matter what you do. As a result the
throughput will drop based on the latency. For example:

1 Gbit/s = 1000000000 bps
90 ms = 90 / 1000 seconds = 0.09 s
1000000000 * 0.09 = 90000000.00 / 8 / 1024 / 1024 = 10.73 MB

So to utilize a Gigabit link with 90ms latency with a single tcp
connection, you need a TCP window size of 11 MB.

You can test that with:

# Server
iperf3 -s

# Client
iperf3 -w 11M -c <server>

On Windows. This seems to be a problem stating with Windows Server 2008
and newer, because with Windows 2003 you could tune the tcp window size
using registry keys, which is now gone:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=1 (DWORD)
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=256960 (DWORD)

Some people refer to the Windows Auto Tuning Level. However when I played with
that, I got no different results. Also not after a reboot.

See also: https://serverfault.com/questions/698504/receiver-limits-tcp-window-size-to-64-512

Normal and experimental refers to the tcp auto tuning mode. It made no
difference to me.

Normal, chrome: https://thomas.glanzmann.de/cases/f97b7cd8-96eb-11e8-8cd2-63e73dca13db/screenshot-x1-2018-05-09-00_38_03.png
Normal, ie: https://thomas.glanzmann.de/cases/f97b7cd8-96eb-11e8-8cd2-63e73dca13db/screenshot-x1-2018-05-09-00_38_32.png
Experimental, chrome: https://thomas.glanzmann.de/cases/f97b7cd8-96eb-11e8-8cd2-63e73dca13db/screenshot-x1-2018-05-09-00_40_24.png
Experimental, ie: https://thomas.glanzmann.de/cases/f97b7cd8-96eb-11e8-8cd2-63e73dca13db/screenshot-x1-2018-05-09-00_40_54.png

So in short, I confirm what Daniel Jeliński is saying. If you don't tune
SO_SNDBUF and SO_RCVBUF, you end up with a 256 KB tcp window on windows
2008 or newer. No matter what. iexplorer does not tune this, so
downloads are slow over a high latency link, chrome does so you get much
better results. See above. However even chrome does only use a 3 MB tcp
window. As a result for a 90ms Gigabit link, only ca 1/3 of the
bandwidth is utilied with a single connection.

If you like to run me some more experiements, I can do that. I just
compile curl with a higher SO_SNDBUF / SO_RCVBUF, fire up a ec2 AWS
instance with windows server 2016 somewhere in the world with a big pipe
and high latency and download something from my well connected
webserver.

Of course someone also could use tc to simulate a high latency link. And
do the testing local between two VMs.

Cheers,
        Thomas
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-03