[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion client hangs during long operations

From: Karen Tracey <kmtracey_at_gmail.com>
Date: 2007-06-26 16:28:10 CEST

On 6/25/07, Jason Erickson <jasone@dbo2.com> wrote:
> Karen,
> You're a lifesaver! That command seemed to have done the trick. I did
> have
> more questions, if you happen to know. The command that fixed the problem
> is:
> netsh interface tcp set global autotuninglevel=disabled
> I'm a little out of my depth on this stuff. If this fixed the problem,
> does
> that mean that I likely had other network problems (or potential network
> problems) of which I was unaware? Everything seemed to be working fine,
> but
> I haven't been using this laptop for very long. If it is likely that the
> problem was isolated to Subversion, is there something less 'global' I can
> set?

Hi Jason, glad that pointer helped. From what I've read, you were likely to
see problems with any application using TCP where:

1 - large amounts of data were being sent to your Vista machine, and
2 - the characteristics of the network & application were such that the TCP
code on your machine tried to advertise a very large receive window
(basically data was flowing in quickly and being retrieved quickly by the
application), and
3 - there was a gateway/router box between you and the other end that was
doing stateful packet inspection and did not properly support TCP window
scaling, and therefore dropped packets with sequence numbers that it
considered to be outside the valid receive window for the connection.

It seems a little odd that you'd have a box doing #3 between you and your
subversion server when you are directly connected to your work network, but
I suppose it's possible. The real fix is to identify these boxes in your
network and get them upgraded/replaced so that they correctly support window
scaling, but that would require getting whoever supports your network
infrastructure involved.

Interestingly, Microsoft ran into this issue when testing Vista, and
modified Internet Explorer so that it would not try to advertise these huge
windows. So they made IE immune to the problem but all other applications
are vulnerable to it.

If you'd like to try a less drastic "fix", there are a few other settings
besides "disabled" in the command above that you could experiment with.
"Disabled" fixes the receive window at the default. "Highlyrestricted" and
"restricted" let the window grow, but more conservatively than "normal",
which is the default value for the setting. To see what the current setting
is you can use the command:

netsh interface tcp show global

In the output from this you're interested in the value of "*Receive Window
Auto-Tuning Level*."

> Incidentally, I am not the only one using Vista. There is one other user.
> The difference is, he is using a different model, so his network hardware
> might be different. Also, he upgraded from Windows XP Pro to Vista
> whereas
> I started with Vista when I installed Subversion. He said he recalled
> being
> prompted about Tortoise when doing the upgrade so that he could run it in
> 'compatibility' mode or something. I looked into that, but there was
> nothing I could do along those lines.

I can't explain why this other Vista user isn't seeing the same problem as
you. From all I've read about it the problem is not related to
hardware/software on the endpoints but rather in an intermediate network
box. But then most of the descriptions are pretty vague so perhaps there is
another factor that could come into play and that is different between your
two machines.

Received on Tue Jun 26 16:28:01 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.