I think I found the solution:
PuTTY has a 16KB receive window unless you have a one way connection, then
it gets a 2MB one (and that's why I was able to run pscp.exe [PuTTY scp] at
So the solution is to patch PuTTY to use a larger window on two-way
connections. With 250ms ping to Singapore, the receive window would only
get emptied four times a second, resulting in the ~60KB/s I was stuck with.
On Jan 13, 2017 10:56 PM, "Charles Alexander" <charlesalexander_at_gmail.com>
> One other thing: I also tried with and without Nagle's algorithm in the
> PuTTY profile.
> On Fri, Jan 13, 2017 at 10:49 PM, Charles Alexander <
> charlesalexander_at_gmail.com> wrote:
>> I'm using svn.exe (1.9.5), connecting through svn+ssh using Plink.
>> For a nearby DigitalOcean server (in New York, 60ms ping), I get
>> checkouts and commits at hundreds of KB/s. But I am collaborating with
>> someone from Australia and he was getting really slow checkouts and commits
>> to the server.
>> After lots of troubleshooting, I couldn't find anything that would speed
>> it up for him. I tried making a digital ocean server in Singapore to see
>> if it would be fast for him, and still be fast for me. While it is faster
>> for him, I ended up seeing the same exact poor speeds he was seeing.
>> The Singapore test server has a 280ms ping for me. My checkouts go at
>> almost exactly 60KB/s.
>> However, if I checkout from a linux VM on my same machine, through the
>> same internet, using the linux svn client, I get hundreds of KB/s even to
>> Worried it might be an issue with Plink/PuTTY, I tried copying a large
>> file with PuTTY's pscp.exe, and it goes at around 3400 KB/s, without
>> Anyone have any ideas on what could be causing the slow down? A checkout
>> of the same exact repository from the New York server goes around ten times
>> faster. And a checkout from a linux VM on the same desktop I am running
>> svn.exe from went about the same, even to the Singapore server. Everything
>> also goes slow when I use TortoiseSVN and not the commandline.
>> Let me know if there is any more information I can provide to help track
>> this down.
>> Charles Alexander
Received on 2017-01-16 09:18:55 CET