[LARTC] Problems using The Ultimate Traffic Conditioner from the Cookbook

From: Malte Starostik <malte.starostik@t-online.de>
To: lartc@vger.kernel.org
Subject: [LARTC] Problems using The Ultimate Traffic Conditioner from the Cookbook
Date: Fri, 19 Dec 2003 05:06:30 +0000	[thread overview]
Message-ID: <marc-lartc-107181174021910@msgid-missing> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm absolutely new to tc and found The Ultimate Traffic Conditioner to be 
exactly what I wanted as a starting point.
Now the script doesn't behave as I expected though, which applies to both the 
CBQ and HTB versions, the latter of which being my preference.
The only changes made to the script are these assignments:
DOWNLINKr0
UPLINK\x110
DEV=ppp0

and s/^tc/\/sbin/tc/ so it can be run via sudo (no /sbin in $PATH then)

My ISP provides ADSL at 768kbps up/128kbps down.
Now with the above configuration downloads still come in at normal speed (~88 
kbytes/s with ftp), latency increases like without any traffic control and 
according to tc -s no packet is dropped at all.
So I played a bit with the DOWNLINK value and found out that down to and 
including 555 no packets are dropped even if a download fully saturates the 
link while 554 already drastically caps the download to ~65 kbytes/s, and 
there are packets being dropped:
 Sent 2788072 bytes 2611 pkts (dropped 461, overlimits 0)

Lower values than 554 drop even more packets, just as I'd expect; there seems 
to be no other threshold as hard as from 554 to 555.
Now I fail to see any meaning in these values, the download speed I get when 
using them and especially what happens at 555 (supposed to be kbits/s, 
right?).

Any insight is greatly appreciated!

Some specs (don't hesitate to solicit any more info if needed):

$ uname -a
Linux zaphod.bound-souls 2.4.20-gentoo-r7 #2 Fri Dec 19 03:28:33 CET 2003 i686 
Pentium II (Klamath) GenuineIntel GNU/Linux

$ /sbin/ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:d7:fe:1b brd ff:ff:ff:ff:ff:ff
    inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
    inet6 fe80::280:c8ff:fed7:fe1b/10 scope link
    inet6 3ffe:b80:24b:1::1/64 scope global
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:00:e8:45:97:a9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::200:e8ff:fe45:97a9/10 scope link
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc htb qlen 3
    link/ppp
    inet 217.232.54.6 peer 217.5.98.175/32 scope global ppp0
6: ippp0: <POINTOPOINT,NOARP> mtu 1500 qdisc noop qlen 30
    link/ppp
7: sit1@NONE: <POINTOPOINT,NOARP,UP> mtu 1472 qdisc noqueue
    link/sit 0.0.0.0 peer 206.123.31.114
    inet6 fe80::d9e8:3606/10 scope link
    inet6 fe80::ac10:1/10 scope link
    inet6 3ffe:b80:2:c97::2/128 scope global

The DSL modem used by ppp0 is connected directly to eth1.
There are quite some non-fancy iptables rules in effect, as set up by a very 
basic shorewall configuration.
The box is pretty damn idle.

Thanks alot in advance,
Malte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4odYVDF3RdLzx4cRAjKYAKCo1GpMrHPL7T3ddBqpLYABf+ivbQCg0S1p
2+LTZ6aOvSF/STInht1XClA=xzeC
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/