I would have thought so too, but my sample website, news.com.com loads just fine (and really fast) with proxy off using the same machine as the default route, so I thought the problem must lie within squid. I'm guessing that somehow the extra latency of one more hop causes requests to work fine while requests originating from the squid server itself are somehow too fast? I've never had to run congestion control before, but I have now tried the linux options for net.ipv4.tcp_congestion_control for reno, bic, vegas, westwood and found the best performace routing was with bic, not the old default of reno. I am RTFMing right now on exactly how to do the "shaping/restricting" on a specified NIC now. Thanks for the help. Scott -----Original Message----- From: Henrik Nordstrom [mailto:henrik@xxxxxxxxxxxxxxxxxxx] Sent: Tuesday, July 31, 2007 3:07 PM To: squid inbox Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: Detecting and blocking child proxy servers On tis, 2007-07-31 at 12:34 -0700, squid inbox wrote: > One of the techniques that my ISP uses is that when a program is > downloading with full throttle, and when i open a page, his server > will not split the speed for the requests, instead it either ignores > it or replies after a large amount of time. More likely it's just a very large link transmit buffer at the ISP causing latency to skyrocket.. seen on most DSL links. It's a common technique used for maximising download speeds, but serverely hurts interactivity while a download is in progress. Easily overcome by shaping/restricting your incoming traffic to just below the actual link speed, as if you had a slightly slower connection. A difference of a few bps should be sufficient, i.e. limit your traffic to 250 kbps if you have a 256 kbps link. The purpose of this is to make TCP back off before the link buffers at the ISP fills up.. You can easily test if this is the case by trying to ping some host while the download is running. If this is the case the you will see huge ping times, as large as 10 seconds or more.. The latency for new HTTP requests is at minimum twice the ping time.. Regards Henrik
