Git clone in windows much slower than in linux

Question

I have been chasing a problem with extremely slow clone speeds from github on windows. Linux (kali) does not have this problem.

I am on a 100/40 megabit/s down up connection. I can obtain close to 8mb/s download no problem.

I have plugged my PC directly into our internet outlet without any router or switches.

Windows git clone (windows 10, git 2.14.1) consistently downloads at approxmately 150-210kb/s

I have tried another windows 7 and windows 10 machine with the same issue. I have tried a windows XP VM with the same issue. I have changed my connection to 4G cellular and speed is the same.

I have tried the github mirror test (https://bitbucket.org/mirror/git.git) with the same results.

I have tried SSH and HTTPS with a change in speed but still slow.

I have tried other github mirrors also with slow speeds.

I have tried using a VPN (PIA) via silicon valley which was even slower.

If I use kali linux in a VM on the same machine with the network connection bridged I get ~8 mb/s from bitbucket using both SSH and HTTPS.

If I use visual studio team services hosted build agent (windows) I get either roughly 60mb/s (possibly cached?)

I have tried running git from git bash, ubuntu bash (windows 10), windows cmd, powershell all with the same slow speeds.

I have tried the using the "OpenSSL Library" and also the "native windows secure channel library" when installing git.

I have tried downgrading as low as version 2.00 from 2.14 with no difference.

I am located in Australia.

I have spoken to bitbucket support and they have suggested that the MSS/MTU must be 1436 or lower. My router and PC defaults to 1500 however using wireshark in windows I can see that all the packets have an MTU of 1436.

Using tcpdump in kali linux I also see an MTU of 1436.

To summarise I have changed the following things: Different PC/VM Different versions of windows Different physical network connections.

I either get ~200kb/s max in windows, or I get 8mb/s max in linux.

What specifically is different between the linux and windows git implementations that could cause theses speed differences?

edit: In case git was using a slow network share (seen other questions regarding this) I tried doing a cp -r using my local clone and I get roughly 1gb/s transfer speeds (RAID 0 SSD) using the same paths as in my git config.

edit: If I bridge the network in my Kali VM to windows I get 8mb/s, if I use NAT then I get 200kb/s indicating it is something to do with the https via windows rather than the git client causing the problem. Does this help?

edit 2: It appears all HTTPS traffic via windows is capped at 200kb/s, this is a windows problem not a git problem. I will start a new question.

https://superuser.com/questions/1244551/https-traffic-40x-slower-than-http-in-windows-10-x64

Answer 1

Problem solved. Open command prompt as administrator and run the following commands:

netsh interface tcp show global netsh interface tcp set global autotuninglevel=normal  netsh interface tcp show heuristics netsh interface tcp set heuristics disabled 

Do not forget to restart the computer in the end.

The cause was auto tuning was set to disabled for some reason on all my windows 10 PCs. After restart PC the speed instantly went to 8mb/s

Answer 2

Try and un-compress PortableGit-2.14.1-64-bit.7z.exe in (for instance) C:\git2.14.1

Then, in a CMD (not bash), type:

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\ set GH=C:\git2.14.1 set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH% 

In that session, your PATH will only reference Windows and Git.

Try again a Git clone, to see if the speed is still capped.

If it does, as the OP comment, then Windows networking is at fault.
That is what the OP discovered in his other question.
And that i what is explained in "window auto-tuning in Windows 10"

The Receive Window Auto-Tuning feature lets the operating system continually monitor routing conditions such as bandwidth, network delay, and application delay. Therefore, the operating system can configure connections by scaling the TCP receive window to maximize the network performance.

To determine the optimal receive window size, the Receive Window Auto-Tuning feature measures the products that delay bandwidth and the application retrieve rates. Then, the Receive Window Auto-Tuning feature adapts the receive window size of the ongoing transmission to take advantage of any unused bandwidth.

Let the default settings of Window Auto-Tuning feature be enabled. If your network uses an old router or your firewall software does not support this feature, and you are experiencing poor or no connectivity issues, only then may you disable this feature and see if it works in your favor.

As explained in Microsoft blog post:

Some of the confusion may have originated from a misinterpretation of a blog post which suggests disabling heuristics with the following command:

netsh interface tcp set heuristics disabled 

Heuristics is a feature that can interfere with auto-tuning and disabling it can improve Internet speeds and in fact heuristics have already been disabled in Windows 8.1 and greater.
Auto-Tuning on the other hand should NEVER be disabled.