Malte Starostik
2003-Dec-19 05:06 UTC
Problems using The Ultimate Traffic Conditioner from the Cookbook
-----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:
DOWNLINK=720
UPLINK=110
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/
Kabelweb
2003-Dec-25 08:43 UTC
Re: Problems using The Ultimate Traffic Conditioner from the Cookbook
Hi!> 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:It seems that your setup suffers from timer inaccuracy. This topic has been dealt with some times on this list. Read (for example) this thread: http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg02795.html In short: it might be that the timer of your qdisc runs at to low a resolution to measure exactly how much packets to let pass since the last time it could send. Therefore it seems that the bandwith cap of the qdisc does not correlate linear with the given kbps value but more or less like a staircase (ie. a dramatic drop on a certain kbps value - like you described it at 554kbps)> 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.The stairs should get smaller with the kbps value specified but should remain stairs and not become a linear slope - assuming I''ve guessed the source of your problem correctly. The solution (as mentioned in the thread above) is to either change the HZ value to for example 1024 (you don''t have to do this by manually patching your kernel source because your gentoo kernel has a patch applied which lets you specify the HZ value from kernel config - I think its somewhere in "Processor type and features") or to change PSCHED_CLOCK_SOURCE to PSCHED_CPU in your /usr/src/linux/include/net/pkt_sched.h (which I personally had some problems with in the past - can''t remember exactly though). I hope this helps - let us know... Andreas _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Malte Starostik
2003-Dec-28 08:31 UTC
Re: Problems using The Ultimate Traffic Conditioner from the Cookbook
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thursday 25 December 2003 09:43, Kabelweb wrote:> Hi! > > > 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: > > It seems that your setup suffers from timer inaccuracy. > This topic has been dealt with some times on this list. > > Read (for example) this thread: > http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg02795.html >[snip]> The solution (as mentioned in the thread above) is to either change the HZ > value to for example 1024 (you don''t have to do this by manually patching > your kernel source because your gentoo kernel has a patch applied which > lets you specify the HZ value from kernel config - I think its somewhere in > "Processor type and features") or to change PSCHED_CLOCK_SOURCE to > PSCHED_CPU in your /usr/src/linux/include/net/pkt_sched.h (which I > personally had some problems with in the past - can''t remember exactly > though). > > I hope this helps - let us know...Thanks Andreas, this helped perfectly. I used the latter approach by editing pkt_sched.h to use the rtdsc as I was a little intimidated by the help text for the HZ option mentioning not to use values larger than half the CPU''s clock in MHz. And as this is only a PII/266 I thought gentoo''s default of 200 was stressing that enough already... Regards, - -Malte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/7pTfVDF3RdLzx4cRAoObAJ9Ek0pVzNy5hh/r85W+qbeNaTecOQCg0qCw CtBhWYt6k32swyujNpRtNBo=fmYt -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/