Hi, I''m fighting seriously with a most simple HTB setup. I''d like to share the incoming 64kbps into 5 and 59 for two different machines under NAT. HTB seems to hold the required limits when ceil is not set (no borrowing), but when borrowing enabled it seems to share equally rather then keeping the specified ratio. My setup is below. A typical output of "tc -s -d qdisc show dev eth1" and "tc -s -d class show dev eth1" is given. HTB seems to disobey the specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is measured, while rate 472Kbit is set for 1:11 and rate 20755bps is measured). Setting the explicit bandwith (ceil=64kbps everywhere) does not work. Playing with burst and cburst did not any change. I''ve tried CBQ but it seems to do the same... :( Please help. Thank you, Bálint #################################### # add root HTB disc run_tc qdisc add dev eth1 root handle 1: htb default 11 r2q 1 # be optimistic about input rates :) run_tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit # setup classes for the local nodes run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil 10mbit prio 2 run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil 10mbit prio 1 # create leaves run_tc qdisc add dev eth1 parent 1:10 sfq perturb 10 run_tc qdisc add dev eth1 parent 1:11 sfq perturb 10 # setup filtering rules : packets going to 192.168.1.2 will go into class 1:10 run_tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.2 flowid 1:10 ################################ # tc -s -d qdisc show dev eth1 qdisc sfq 8002: quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 3401706 bytes 2650 pkts (dropped 0, overlimits 0) qdisc sfq 8001: quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 2039284 bytes 1363 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 1 default 11 dcache 0 deq_util 1/1000000 deq_rate 5 trials_per_deq 0 dcache_hits 0 direct_packets 0 Sent 5440990 bytes 4013 pkts (dropped 0, overlimits 0) ################################ # tc -s -d class show dev eth1 class htb 1:11 parent 1:1 leaf 8002: prio 1 rate 472Kbit ceil 10Mbit burst 2203b/8 mpu 0b cburst 14704b/8 mpu 0b quantum 60000 level 0 Sent 3284592 bytes 2545 pkts (dropped 0, overlimits 0) rate 20755bps 15pps lended: 2545 borrowed: 0 giants: 0 injects: 0 tokens: 28909 ctokens: 9147 class htb 1:1 root prio 0 rate 10Mbit ceil 10Mbit burst 14704b/8 mpu 0b cburst 14704b/8 mpu 0b quantum 60000 level 3 Sent 5140628 bytes 3786 pkts (dropped 0, overlimits 0) rate 37374bps 26pps lended: 888 borrowed: 0 giants: 0 injects: 0 tokens: 9147 ctokens: 9147 class htb 1:10 parent 1:1 leaf 8001: prio 2 rate 40Kbit ceil 10Mbit burst 1650b/8 mpu 0b cburst 14704b/8 mpu 0b quantum 5120 level 0 Sent 1856036 bytes 1241 pkts (dropped 0, overlimits 0) rate 16466bps 10pps lended: 353 borrowed: 888 giants: 0 injects: 0 tokens: -71171 ctokens: 8247 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sunday 01 September 2002 01:04, Takács Bálint wrote:> Hi, > > I''m fighting seriously with a most simple HTB setup. I''d like to share > the incoming 64kbps into 5 and 59 for two different machines under NAT. > HTB seems to hold the required limits when ceil is not set (no > borrowing), but when borrowing enabled it seems to share equally rather > then keeping the specified ratio. > My setup is below. A typical output of "tc -s -d qdisc show dev eth1" > and "tc -s -d class show dev eth1" is given. HTB seems to disobey the > specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is > measured, while rate 472Kbit is set for 1:11 and rate 20755bps is > measured). > Setting the explicit bandwith (ceil=64kbps everywhere) does not work. > Playing with burst and cburst did not any change.You have to put a ceil of 64kbps everywhere so class 1:10 and 1:11 share the same 64 kbps : run_tc class add dev eth1 parent 1: classid 1:1 htb rate ceil 64kbps run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil 64kbps prio 2 run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil 64kbps prio 1 And if that''s not working, try ceil=62kbps. You have to do this so YOU are controlling the link and not the modem. And take sum of class = 62kbps. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Thanks Stef! The trick with setting lower maximum bandwidth works. I convinced me that I understand now what happens :) The ISP starts to build queues when maximal input rate is reached and releases packets from these queues equally. Thus the prioritized connections had to wait sometimes and it lends its guaranteed bw instead of waiting. I had to set the ceil to as low as 50 kbps (!). My usual maximal throughput rate is about 55 kb/sec, while my ISP says the maximal input rate is 512 kbit/sec. I always assigned the difference to IP administration. Now, the maximal throughput seems to not drop until ceil is lowered below 55 kbps. Thus I assume the rates calculated by HTB measure the REAL throughput without IP administration. Is it true? Sometimes the maximal input rate drops (damn ISP) and it seems to enable small "bursts" with high throughputs. Does it mean that I should to decrease/increase the ceil when it happens? I think it depends on the ISP queues: if they start to build, then I must. It can mean that I can''t use traffic shaping, or at least not HTB qdisc - maybe some prio setup will do the job. What if I try to shape the outgoing traffic? Maybe it has an effect on incoming, too. I mean if "acknowledged" information goes back slow, I can manipulate the ISP queues, hm? Bálint Stef Coene wrote:>On Sunday 01 September 2002 01:04, Takács Bálint wrote: > >>Hi, >> >>I''m fighting seriously with a most simple HTB setup. I''d like to share >>the incoming 64kbps into 5 and 59 for two different machines under NAT. >>HTB seems to hold the required limits when ceil is not set (no >>borrowing), but when borrowing enabled it seems to share equally rather >>then keeping the specified ratio. >>My setup is below. A typical output of "tc -s -d qdisc show dev eth1" >>and "tc -s -d class show dev eth1" is given. HTB seems to disobey the >>specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is >>measured, while rate 472Kbit is set for 1:11 and rate 20755bps is >>measured). >>Setting the explicit bandwith (ceil=64kbps everywhere) does not work. >>Playing with burst and cburst did not any change. >> >You have to put a ceil of 64kbps everywhere so class 1:10 and 1:11 share the >same 64 kbps : > >run_tc class add dev eth1 parent 1: classid 1:1 htb rate ceil 64kbps > >run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil 64kbps >prio 2 >run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil 64kbps >prio 1 > >And if that''s not working, try ceil=62kbps. You have to do this so YOU are >controlling the link and not the modem. And take sum of class = 62kbps. > >Stef >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 02 September 2002 13:24, Takács Bálint wrote:> Thanks Stef! The trick with setting lower maximum bandwidth works. I > convinced me that I understand now what happens :) The ISP starts to > build queues when maximal input rate is reached and releases packets > from these queues equally. Thus the prioritized connections had to wait > sometimes and it lends its guaranteed bw instead of waiting. > > I had to set the ceil to as low as 50 kbps (!). My usual maximal > throughput rate is about 55 kb/sec, while my ISP says the maximal input > rate is 512 kbit/sec. I always assigned the difference to IP > administration. Now, the maximal throughput seems to not drop until > ceil is lowered below 55 kbps. Thus I assume the rates calculated by HTB > measure the REAL throughput without IP administration. Is it true?HTB measures each bit that''s sended. So all ip-overhead included.> Sometimes the maximal input rate drops (damn ISP) and it seems to enable > small "bursts" with high throughputs. Does it mean that I should to > decrease/increase the ceil when it happens? I think it depends on the > ISP queues: if they start to build, then I must. It can mean that I > can''t use traffic shaping, or at least not HTB qdisc - maybe some prio > setup will do the job.You can use traffic shaping for the moments the traffic is not dropped. If you know exactly how the bursts are, you can try to enable the same bursts with htb.> What if I try to shape the outgoing traffic? Maybe it has an effect on > incoming, too. I mean if "acknowledged" information goes back slow, I > can manipulate the ISP queues, hm?It can affect incoming traffic, but I think the effect will be allmost neglectable. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/