On Mon, 15 Apr 2002 02:28:15 -0400 "Frank Gore" <[EMAIL PROTECTED]> wrote:
> time over the Internet connection. For example, if I'm downloading a 20
> MB file from sourceforge.net, that single download takes up ALL of my
> bandwidth and leaves me with none for anything else. While downloading
> that file, I can't browse the web or check my email or start a download
> on another file, everything just times out and fails. The bandwidth is
> exclusively used for the file download and nothing else.
>
> However this behaviour seems to affect only my Linux-based clients. When
> I reboot my workstation into Windows XP (using the exact same hardware,
> since it's the same computer), this packet queuing issue disappears.
> While in Windows, I can be downloading 2 different files and still be
> able to browse the web AND check my email all at the same time. The
> bandwidth gets evenly distributed between all applications as needed. If
> I'm downloading one file at 5 KB/s, then begin a second download, then
> each download will get about 2.5 KB/s each. This is all through the
> exact same gateway box as the Slackware workstation was using.
Ok, this is a performance vs interactivity issue and can be "fixed" by
using a properly configured QOS filter. The Linux box try to download as
quick as it can, and it gets it: but that tends to hog the bandwidth.
The Windows box download at a slower rate, so downloading large file
can take much longer, but low bandwith traffic can still get through.
Since packet routing depends on the bandwidth and the physical link, the
adjustment should be done on the router. Things does not get "evenly"
distributed by default, or else any large download will take ages.
I have tried a few QOS filters, the one that works best for me is HTB.
With it, I am able to download at 480kbytes/s and still ping the
upstream router at 20ms consistently (without it, the ping will go up
to 400ms). Basically, the idea is to let low bandwidth, high priority
packets to get through the traffic jam.
It works: as long as you set it up properly. However, HTB is new and
not yet included in the kernel, it also need a patched "tc" binary for
iproute to support HTB. To try the HTB QOS filter, you need:
1) Kernel 2.4.17 (2.4.16 works fine)
2) HTB patch:
http://luxik.cdi.cz/~devik/qos/htb/htbman.htm
http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff
3) A patched "tc" binary of the iproute package:
http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz
if you feel like re-compiling iproute, get this patch:
http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_tc.diff
4) A qos.init script (attached)
INSTALLATION:
I) patch the kernel 2.4.17 with HTB patch. (I have not tried newer
kernels, but if it patch ok, it should work);
II) configure the kernel to compile HTB as module, from the menu:
Networking Options -> Qos and/or fair queueing --> HTB packet scheduler
compile and install the new kernel and modules;
III) install iproute package, then overwrite the binary from 3) above,
since the standard "tc" does not know about HTB filter yet.
SETUP:
A) there are only three parameters to set in qos.init:
DOWNLINK=
UPLINK=
DEV=
Set the DOWNLINK and UPLINK parameters in kilobits. Use a value slightly
less than the max bandwidth of your link, probably 1 - 2% less. For a
56k modem, download is 56kbits and upload is 33.6kbits, so it looks
something like this:
DOWNLINK=48
UPLINK=30
DEV=ppp0
Tweak the two values until you are satisfied.
B) testing
first start up the ppp0 connection, then run "qos.init htb". Then run
"tc -s qdisc" to read the rules.
C) put qos.init in place: When you setup ppp0 to use QOS, the interface
has to be up already, "tc" does not like it if the interface is not
there.
Debian installation:
cp qos.init /etc/ppp/ip-up.d/qos
chmod 750 /etc/ppp/ip-up.d/qos
RPM system installation:
cp qos.init /usr/sbin
echo "qos.init htb" >> /etc/ppp/ip-up.local
Done. Good luck!
qos.init
Description: Binary data
