During my tests I''m starting to feel stupid :). Traffic shaping works quite on its own. System: RedHat 7.3, RedHat kernel 2.4.18-18.7.xsmp, HTB version 3.6, interfaces eth0 and eth1 are acting as bridge br0. If TCP shaping almost works, it just exceeds limits UDP is not shaped. Traffic flows PC=>eth0=>eth1=>PC. Statistics shown is for just UDP traffic (1mbit of small udp packets). What strange is that I do not see dropped or overlimits packets. Lots of info is at the end of the letter. Where is my mistake? Thanks, Mindaugas ===============================================================$TC qdisc del dev eth1 root $TC qdisc add dev eth1 root handle 1: htb $TC class add dev eth1 parent 1: classid 1:200 htb rate 256kbit $TC qdisc add dev eth1 parent 1:200 handle 200: sfq perturb 10 $TC filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip dst $ip flowid 1:200 #for w in "qdisc" "class" "filter"; do bin/tc -s -d $w show dev eth1; echo; done qdisc sfq 200: quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 25485900 bytes 424765 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 10 default 0 direct_packets_stat 552 ver 3.6 Sent 25553103 bytes 425317 pkts (dropped 0, overlimits 0) class htb 1:200 root leaf 200: prio 0 quantum 3276 rate 256Kbit ceil 256Kbit burst 1919b/8 mpu 0b cburst 1919b/8 mpu 0b level 0 Sent 25486560 bytes 424776 pkts (dropped 0, overlimits 0) rate 162710bps 2711pps lended: 424776 borrowed: 0 giants: 0 tokens: 30 ctokens: 30 filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:200 match d5e28382/ffffffff at 16 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > During my tests I''m starting to feel stupid :). Traffic > shaping works quite on its own. > > System: RedHat 7.3, RedHat kernel 2.4.18-18.7.xsmp, HTB > version 3.6, interfaces eth0 and eth1 are acting as bridge br0. > > If TCP shaping almost works, it just exceeds limits UDP > is not shaped. Traffic flows PC=>eth0=>eth1=>PC. Statistics > shown is for just UDP traffic (1mbit of small udp packets). > What strange is that I do not see dropped or overlimits > packets. >It seems that I found the cause. I downloaded and installed vanilla Linux kernel 2.4.20 and everything went fine. Then I installed variable HZ patch from http://www.kernel.org/pub/linux/kernel/people/rml/variable-HZ/v2.4/ and set HZ to 1000. Shaping started to act not as I wanted. Setting HZ back to 100 fixed the problem. Is this some bug in HTB or HZ has to be set to 100? Mindaugas _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> It seems that I found the cause. > > I downloaded and installed vanilla Linux kernel 2.4.20 and > everything went fine. Then I installed variable HZ patch from > http://www.kernel.org/pub/linux/kernel/people/rml/variable-HZ/v2.4/ > and set HZ to 1000. Shaping started to act not as I wanted. > Setting HZ back to 100 fixed the problem. > > Is this some bug in HTB or HZ has to be set to 100?It should not be. I used it too. But I don''t know variable-HZ patch - it might affect something of course. devik _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Setting HZ back to 100 fixed the problem. > > Is this some bug in HTB or HZ has to be set to 100?ehh other thought - htb is tested with HZ=1024 or HZ=100. You said that you use HZ 1000. In include/net/pkt_sched.h: #if HZ == 100 #define PSCHED_JSCALE 13 #elif HZ == 1024 #define PSCHED_JSCALE 10 #else #define PSCHED_JSCALE 0 #endif I''m not sure if variable-HZ patch repaired this too. Simply QoS subsystem is not aware what to do with this HZ rate. You might try to redefine PSCHED_JSCALE to be 10 for your case. Also try to set PSCHED_CLOCK_SOURCE to PSCHED_CPU in the same file. It might help. devik _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > Setting HZ back to 100 fixed the problem. > > > > Is this some bug in HTB or HZ has to be set to 100? > > ehh other thought - htb is tested with HZ=1024 or HZ=100. > You said that you use HZ 1000.Yes. You are right. If I set HZ to 1024 everything worked OK.> In include/net/pkt_sched.h: > #if HZ == 100 > #define PSCHED_JSCALE 13 > #elif HZ == 1024 > #define PSCHED_JSCALE 10 > #else > #define PSCHED_JSCALE 0 > #endif > > I''m not sure if variable-HZ patch repaired this too. Simply > QoS subsystem is not aware what to do with this HZ rate. > You might try to redefine PSCHED_JSCALE to be 10 for your > case. > Also try to set PSCHED_CLOCK_SOURCE to PSCHED_CPU in the same > file. It might help.Well I''d prefer to leave that to professionals :). Who is packet filters maintainer? Alexey Kuznetsov? Mindaugas _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > #define PSCHED_JSCALE 0 > > #endif > > > > I''m not sure if variable-HZ patch repaired this too. Simply > > QoS subsystem is not aware what to do with this HZ rate. > > You might try to redefine PSCHED_JSCALE to be 10 for your > > case. > > Also try to set PSCHED_CLOCK_SOURCE to PSCHED_CPU in the same > > file. It might help. > > Well I''d prefer to leave that to professionals :). Who is packet > filters maintainer? Alexey Kuznetsov?Filters ?? If you mean qos classifiers (badly named filters in tc tool) then yes, Alexey. If you mean iptables then I''m not sure. devik _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > > > Well I''d prefer to leave that to professionals :). Who is packet > > filters maintainer? Alexey Kuznetsov? > > Filters ?? If you mean qos classifiers (badly named filters in tc tool) > then yes, Alexey. If you mean iptables then I''m not sure.I mean packet schedulers :). And OK. This problem is avoidable. But as another test I tried to flood link with two data streams - one UDP, one TCP, both going the same direction. Then total traffic drops considerably. Data is below. In bytes. Traffic is shaped to 256kbit. Two TCP streams or one UDP stream is shaped without problems. Traffic flows at ~33000 Mindaugas 1 1041255151 1041255161 21100.6 21100.6 21100.6 1 1041255161 1041255171 18968.4 18968.4 18968.4 1 1041255171 1041255181 19081.9 19081.9 19081.9 1 1041255181 1041255191 19946.4 19946.4 19946.4 1 1041255191 1041255201 33362 33362 33362 1 1041255201 1041255211 33105.7 33105.7 33105.7 1 1041255211 1041255221 17019.4 17019.4 17019.4 1 1041255221 1041255231 17146.2 17146.2 17146.2 1 1041255231 1041255241 18635.5 18635.5 18635.5 1 1041255241 1041255251 16486.2 16486.2 16486.2 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/