From: Stephen Hemminger <shemminger@osdl.org>
To: Daniel Drake <dsd@gentoo.org>
Cc: John Heffner <jheffner@psc.edu>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.17 regression: Very slow net transfer from some hosts
Date: Tue, 11 Apr 2006 16:59:13 -0700 [thread overview]
Message-ID: <20060411165913.5b6bfa0b@localhost.localdomain> (raw)
In-Reply-To: <443C4471.7040407@gentoo.org>
On Wed, 12 Apr 2006 01:06:09 +0100
Daniel Drake <dsd@gentoo.org> wrote:
> Stephen Hemminger wrote:
> >> This is very familiar, and I just found the article I was thinking of:
> >> http://lwn.net/Articles/92727/
> >>
> >> I was also hit by that bug, on the same collection of websites, but that
> >> particular problem was fixed for 2.6.8 or so. So I guess it is extremely
> >> likely that my ISP has broken routers. nmap isn't able to identify the
> >> OS of any ISP routers in my path.
> >
> > We never fixed it, its kind of hard to fix other peoples equipment ;-)
>
> Weird, things started working for me around 2.6.9 without having to
> modify any sysctl stuff.
What we did was default the window scaling needed to match the max
possible memory usage. The normal value for tcp_wmem correlated to
a window scale of 2. If a corrupting middlebox lost the window
scale option, then connection would proceed but all windows would
be 1/4 of possible; and connection would still limp along at
somewhat reduced bandwidth.
John's changes cause tcp_wmem to be bigger, so we ask for a bigger
window scale. If the "window scale lost in translation" problem gets
too bad, the sender will never send anything because it thinks
the receiver is doing silly-window-syndrome.
>
> > Turn off TCP window scaling, your performance will be limited but about
> > as good as you can get with a corrupting firewall in between.
>
> I was wrong in my previous mail where I said that the rmem/wmem output
> hasn't changed over the two kernels - it has, the 3rd column differs. I
> simply set those values back to what they were on 2.6.16 and now things
> work again - I presumably have window scale 2 (scale factor 4) again,
> which appears to be a decent compromise between having a window and
> things actually working.
>
> For anyone else interested, the ISP is NTL (UK). The fix:
>
> echo "4096 16384 131072 " > /proc/sys/net/ipv4/tcp_wmem
> echo "4096 87380 174760 " > /proc/sys/net/ipv4/tcp_rmem
>
>
> This issue is visible on my 1GB system but not on my laptop (256mb RAM).
> The key thing is that more memory means a higher window scale factor is
> used, which appears to trigger ntl's brokenness.
>
> Daniel
next prev parent reply other threads:[~2006-04-11 23:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-11 19:30 2.6.17 regression: Very slow net transfer from some hosts Daniel Drake
2006-04-11 19:21 ` Stephen Hemminger
2006-04-11 19:23 ` John Heffner
2006-04-11 20:03 ` Daniel Drake
2006-04-11 19:55 ` John Heffner
2006-04-11 20:53 ` Daniel Drake
2006-04-11 20:54 ` John Heffner
2006-04-11 22:20 ` Daniel Drake
2006-04-11 22:33 ` Stephen Hemminger
2006-04-12 0:06 ` Daniel Drake
2006-04-11 23:59 ` Stephen Hemminger [this message]
2006-04-12 0:32 ` John Heffner
2006-04-12 0:42 ` John Heffner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060411165913.5b6bfa0b@localhost.localdomain \
--to=shemminger@osdl.org \
--cc=dsd@gentoo.org \
--cc=jheffner@psc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).