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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
