Very slow clone using plink

[DBotThePony]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.16.2.windows.1
cpu: x86_64
built from commit: e1848984d1004040ec5199e749b5f282ddf4bb09
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.15063]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Path Option: CmdTools
Plink Path: C:\Program Files\PuTTY\plink.exe
SSH Option: Plink
CURL Option: WinSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Mintty

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

Just clone

• What did you expect to occur after running these commands?

Fast clone speed

• What actually happened instead?

Clone speed is capped at rough 88 kb/s in terminal. Process Hacker tells speed is capped rough at 96 kb/s

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

This happens on ANY remote repository. If you git clone a repository from local linux machine it will be capped at rough 664 kb/s. If from local vm machine - capped at 7.5 mb/s. If i clone it from command line using dirty ssh-agent and ssh setup, i get 30 mb/s.

Side notes:

• Speed over https on most of repos is at least 3 MB/s
• openssh works good only for clone, for push (because of some limitations of software i use and other stuff) it doesn't for me. And yes, bundled openssh produce a bit slower speed than https clone
• Before using tcp optimizer software https clone was capped at 667 kb/s too. Tested both on bridged network settings in virtual box on win7 and win xp vms, and on host windows 10 - same results. But in vm with linux system git clone speed is fair and balanced.
  Even if direct reason of this issue is wontfix, the issue with https clone speed without using third party software is present still.
• process hacker screenshot on clone:
  
• this issue stand unresolved for ages, so i decided to report.

[dscho]

If it works better with OpenSSH than with plink, maybe this is a PuTTY issue? Did you have a look at that project's bug tracker/forum/mailing list?

[DBotThePony]

Didn't found anything. I've attempted to find PuTTY issue tracker, but couldin't find it.

[landstander668]

I'm guessing the reason you use PuTTY is for integration with private keys loaded into the PuTTY authentication agent (Pageant). Assuming that's accurate, a workaround would be to use the ssh-pageant integration, which allows OpenSSH to use Pageant for key management (and is already included in Git for Windows).

[dscho]

@roboderpy did you get a chance to try @landstander668's suggestion?

[dscho]

For the record, PuTTY's bug tracker seems to be this page: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ (with unresolved bugs on this page: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/#pending), and the process to report new bugs (after checking the list of pending bugs) is described here: https://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html.

[DBotThePony]

Ssh pageant integration works well

[dscho]

@roboderpy okay, then let's close the ticket here. If you want to continue using PuTTY, I suggest going through that list of open ("pending") PuTTY issues, and if you do not find it, report the issue as suggested on their "feedback" page.