----- Original Message ----- From: "Mark Hull-Richter" mhullrich@gmail.com To: "CentOS mailing list" centos@centos.org Sent: Tuesday, November 13, 2007 3:58:01 PM (GMT+1000) Australia/Brisbane Subject: [CentOS] OT: Slow browsers or slow connections?

I have AT&T (formerly SBC) DSL for my primary internet connection here, and tonight it has been exceptionally, extraordinarily S - L - O - W.... Pages that normally load in, at most, seconds, are taking several minutes to locate, even common, frequent access pages like Google, Gmail, etc.

I called AT&T, of course, and all they know about is IE, which, as you can probably guess, I rarely use. Normally I use SeaMonkey, with Firefox as a last ditch backup, on the Linux side, and SeaMonkey in my Windows VM-guest, with IE as the absolute last ditch backup.

I tried their on-the-phone-quick-fix and turned off my modem and router for the recommended 20 seconds (more like 30), and this did no good as far as I could see. (The router is for convenience when I need multiple connections - typically, as now, this is the only computer connected to it.)

However, I played along with their "support" person (they need more support than they give out...), and their suggestion was to go into IE (groan, double groan to fire up the Windows VM guest), delete all cookies, delete all files, and clear the history. Funny thing is, that worked - for IE.

So, I go back to my CentOS SeaMonkey and clear the cache and the history. I'm not sure what else to do, though, because that didn't solve the problem, and Firefox is as slow as my SeaMonkey.

Any suggestions? Are there corollaries to IE's "files" for SM or Ff?

Thanks.

mhr

On Nov 12, 2007 9:58 PM, Mark Hull-Richter mhullrich@gmail.com wrote:

So, I go back to my CentOS SeaMonkey and clear the cache and the history. I'm not sure what else to do, though, because that didn't solve the problem, and Firefox is as slow as my SeaMonkey.

Any suggestions? Are there corollaries to IE's "files" for SM or Ff?

Not that I expect it to help, but did you also clear the cookies? That's on a different tab in the preferences, at least in firefox.

I recently experienced a problem with firefox where cnn.com refused to load -- every other site I tried was fine, but cnn.com gave me the "connection failed, website may be too busy" page with the "Try Again" button. Clearing the cache didn't help, but selectively deleting cnn.com cookies (in order of my guess at their usefulness from least toward most) eventually revived it.

Mark Hull-Richter wrote:

I have AT&T (formerly SBC) DSL for my primary internet connection here, and tonight it has been exceptionally, extraordinarily S - L - O - W.... Pages that normally load in, at most, seconds, are taking several minutes to locate, even common, frequent access pages like Google, Gmail, etc.

I called AT&T, of course, and all they know about is IE, which, as you can probably guess, I rarely use. Normally I use SeaMonkey, with Firefox as a last ditch backup, on the Linux side, and SeaMonkey in my Windows VM-guest, with IE as the absolute last ditch backup.

I tried their on-the-phone-quick-fix and turned off my modem and router for the recommended 20 seconds (more like 30), and this did no good as far as I could see. (The router is for convenience when I need multiple connections - typically, as now, this is the only computer connected to it.)

However, I played along with their "support" person (they need more support than they give out...), and their suggestion was to go into IE (groan, double groan to fire up the Windows VM guest), delete all cookies, delete all files, and clear the history. Funny thing is, that worked - for IE.

So, I go back to my CentOS SeaMonkey and clear the cache and the history. I'm not sure what else to do, though, because that didn't solve the problem, and Firefox is as slow as my SeaMonkey.

Any suggestions? Are there corollaries to IE's "files" for SM or Ff?

3 possible scenarios:

1) DNS not properly configured

Make sure your resolv.conf is properly configured, if you are doing DHCP look into having your resolv.conf set through it, if you are using PPPOE you can have the ppp daemon set it too if the DNS is passed over the ppp connection.

If you are using a static resolv.conf, make sure it is correct, use nslookup on each server in resolv.conf and do a couple of test lookups (www.yahoo.com www.google.com etc).

2) TCP MTU and blackhole router if PPPOE

If you are doing PPPOE then make sure the MTU on the ppp interface link is set to 1492 as pppoe uses 8 bytes for ppp framing. If it is set to 1500 then some large packets will drop and the stack will have to resend smaller and smaller till it goes through. If ICMP need to frag messages are dropped then the connections will stall completely.

3) TCP scaling window and broken router

The latest CentOS uses the TCP scaling window algorithm to the RFC spec which some routers don't support. Some people have noticed that this solves the problem when communicating to other hosts over the Internet.

sysctl -w net.ipv4.tcp_window_scaling=0

-Ross

______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.