Re: [squid-users] Re: squid with pdns, bandwidth control issue

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sat, 30 Jun 2012 15:08:07 +1200

On 30/06/2012 4:41 a.m., Ed W wrote:
> On 29/06/2012 14:12, Muhammad Yousuf Khan wrote:
>> i have made some test and here is some detail and results
>> ok i am using two machine
>>
>> 1, Gateway IPcop (linux)
>> 2. Debian lenny (squid)
>>
>> i am using download manager to download a 50MB file.
>>
>> IPCOP
>> -----------
>> when i do it VIA IPCOP my download burst rate up to 270 KB
>> not ping delay and other can also brows easily.
>>
>> Squid on Lenny
>> ------------------------
>>
>> VIA SQuid (proxy mode) my download reach 365 which is full throughput
>> and faster then IPCOP but
>> ping delay reach 4000 which is considered almost near to death.
>>
>> and no other users can brown and getting time out message on there
>> browser.
>>
>>
>> i think this shows that issue is with squid box and i don't know
>> weather i have to tweak the squid or TCP buffer or anything
>>
>
> Run a download using wget from both boxes and observe the download
> speeds and effect on ping. This might help you figure out if it's an
> operating system configuration setting
>
> The effect is clear though - one of your machines is managing to max
> out the entire inbound connection (which is exactly what TCP is
> supposed to try and do). The other machine is only partially using
> the connection (I know that feels more desirable, but it's likely an
> accident and it's not how tcp tries to behave)
>
> So your problem seems to be reduced to figuring out why one machine is
> performing optimally and hence hogging the whole internet connection.
>
> Reduce the problem to the basics and debug from there. Just remember
> that tcp is supposed to learn how to hog the entire connection,
> allocating traffic more evenly is a tricky problem and you might want
> to use the various features in squid delay pools and linux traffic
> control to control this..?

Well kind of. TCP is supposed to hog all the *unused* portion of the
connection. Without getting in the way of other important traffic,
particularly traffic control packets like ICMP/ping.
So ping is a good measure of when TCP is failing to accomodate important
things. But not a good measure of when TCP is operating correctly. Only
a deep packet analysis gives a good measure of TCP when it is operating
correctly (or semi-correctly).

Amos
Received on Sat Jun 30 2012 - 03:08:23 MDT

This archive was generated by hypermail 2.2.0 : Sat Jun 30 2012 - 12:00:04 MDT