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
