All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@gentoo.org>
To: Stephen Hemminger <shemminger@osdl.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: Wed, 12 Apr 2006 01:06:09 +0100	[thread overview]
Message-ID: <443C4471.7040407@gentoo.org> (raw)
In-Reply-To: <20060411153315.4132b477@localhost.localdomain>

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.

> 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

  reply	other threads:[~2006-04-11 23:53 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 [this message]
2006-04-11 23:59                 ` Stephen Hemminger
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=443C4471.7040407@gentoo.org \
    --to=dsd@gentoo.org \
    --cc=jheffner@psc.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.