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.