>> > +1 on Alan's hunch. I have not used Squid to comment on the specifics >> > and also Grant stated that another proxy gave him similar symptoms. >> > From my limited knowledge a proxy could be stalling because of cache >> > configuration problems, like running out fs space, or inodes and also >> > running out of memory if it has to process simultaneous requests from >> > too many clients at a time. If the problem also manifests when the >> > clients are within the same subnet, then this is unlikely to be a >> > network issue. >> >> Which hunch was that? I snipped a lot above but I couldn't find it in >> there. > > It was Alan's statement that this problem is not related to your AT&T router. > > I have to come back to this. I tried the www.google.com/nexus/ you mentioned > and noticed that the page eats up 1.3MB to load fully, before it starts > downloading a flash video. So seems to be a relatively large amount of data > that brings up this problem and this could point to tcp window scaling.
It also happens on very lightweight sites, but never on squid-cache.org for some reason. >> echo 0 > /proc/sys/net/ipv4/tcp_window_scaling > > This is typically enabled, but if you notice that a connection stalls and then > later on it works fine again, it could be related to a firewall/router not > responding as it should to tcp_window_scaling. In this case disabling this > would fix the problem when traversing problematic nodes. > > If you saw no difference, this suggests that window scaling is not an issue. I just tested again and 'echo 0 > /proc/sys/net/ipv4/tcp_window_scaling' on both the client and server did not fix the stalls. > I would start with the simplest tests first, which involve isolating suspect > system components one at a time. Trying to use the same laptop-desktop > machines within the LAN, takes the router out the equation - full 1500 byte > MTU will be used by both laptop and desktop. OK I will try this as soon as I'm back in that location. Thanks a lot, Grant
