Hi,
I''m trying to use prio qdisc with htb, however not the
"usual" way (like for
example FairNAT).
Here is my idea:
Root has HTB shaping traffic to link speed -> then goes PRIO queues ->
each
prio queue has HTB with sublasses for each user, should look like this:
1: htb qdisc
|
1:1 htb class
/|\
/ | \
10:1 10:2 10:3 prio queues
| | |
20: 30: 40: htb qdiscs
/ | \
20:1.... 30:1... 40:1... htb classes
Then, if I''m right, when there is traffic in prio qdisc 1 to fully load
link,
users would get it distributed evenly but any low priority connections in
qdiscs 2,3... would starve. Which is exactly what I want.
Problem is, when I add filters to enqueue in HTB "below" prio qdisc,
they
aren''t working.
I''m tried to make simplified version first:
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 3000kbit
tc qdisc add dev eth0 parent 1:1 handle 10: prio
tc qdisc add dev eth0 parent 10:1 handle 20: htb
tc class add dev eth0 parent 20:0 classid 20:1 htb rate 3000kbit
tc qdisc add dev eth0 parent 10:2 handle 30: htb
tc qdisc add dev eth0 parent 10:3 handle 40: htb
tc class add dev eth0 parent 30:0 classid 30:1 htb rate 3000kbit
tc class add dev eth0 parent 40:0 classid 40:1 htb rate 3000kbit
tc filter add dev eth0 protocol ip parent 1: prio 0 handle 4 fw flowid 40:1
all packets are marked with 4, but none gets to 40:1
---------------------------------------------------------------
class htb 40:1 root prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst
5439b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 14505 ctokens: 14505
class htb 30:1 root prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst
5439b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 14505 ctokens: 14505
class htb 20:1 root prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst
5439b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 14505 ctokens: 14505
class prio 10:1 parent 10: leaf 20: [UNKNOWN]
class prio 10:2 parent 10: leaf 30: [UNKNOWN]
class prio 10:3 parent 10: leaf 40: [UNKNOWN]
class htb 1:1 root leaf 10: prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b
cburst 5439b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 14505 ctokens: 14505
---------------------------------------------------------------
qdisc htb 40: r2q 10 default 0 direct_packets_stat 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc htb 30: r2q 10 default 0 direct_packets_stat 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc htb 20: r2q 10 default 0 direct_packets_stat 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc prio 10: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc htb 1: r2q 10 default 0 direct_packets_stat 7347
Sent 827649 bytes 7347 pkts (dropped 0, overlimits 0)
---------------------------------------------------------------
{setting flowid to 1:1 works as expected}
I can''t find where my mistake lies,
any suggestions or pointers would be helpfull.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Am Saturday 08 May 2004 17:22 schrieb Tomas Simonaitis:> Then, if I''m right, when there is traffic in prio qdisc 1 to fully load > link, users would get it distributed evenly but any low priority > connections in qdiscs 2,3... would starve. Which is exactly what I want.Not just that - if User A has high priority traffic (Prio band 1), User B and C middle-priority Traffic (Prio band 2), User A still uses up all the bandwidth and lets B and C starve. If that *really* is your intention, you''re on the right path, otherwise: don''t do it. It''s not useful for distributing bandwidth evenly between users. Another problem is rate distribution for lower-level HTB qdiscs. Since these qdiscs know nothing about each other, it won''t work. So the ''rate 3000kbit'' of the lower level HTB qdiscs is a little illusionary. Instead of using PRIO qdisc, it''s probably worth a try to use the prio parameter of HTB itself. It won''t have exactly the same effect, but sharing will work (since you''re using a single HTB qdisc then) and maybe it''s still sufficient for you.> tc qdisc add dev eth0 root handle 1: htb > tc class add dev eth0 parent 1: classid 1:1 htb rate 3000kbit > tc qdisc add dev eth0 parent 1:1 handle 10: prio > tc qdisc add dev eth0 parent 10:3 handle 40: htb > tc filter add dev eth0 protocol ip parent 1: prio 0 handle 4 fw flowid > 40:1This filter rule is WRONG. You tell the top qdisc to enqueue traffic into a class that''s not even a child of this qdisc. Even if traffic would be enqueued that way, it wouldn''t have traversed the prio qdisc then, therefore you wouldn''t get the effect you wanted. Attach the filter rules to the qdiscs/classes they belong to only. In this case, it would probably be parent 40: instead of parent 1:. Care to explain why you want this setup? It seems somehow impractical to me. Regards, Andreas _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Not just that - if User A has high priority traffic (Prio band 1), > User B and C middle-priority Traffic (Prio band 2), User A still > uses up all the bandwidth and lets B and C starve. If that *really* > is your intention, you''re on the right path, otherwise: don''t do it. > It''s not useful for distributing bandwidth evenly between users.It''s my intention, each user would also have ceil limit set in each prio band and high prio bands would be for known interactive traffic only.> Another problem is rate distribution for lower-level HTB qdiscs. > Since these qdiscs know nothing about each other, it won''t work. > So the ''rate 3000kbit'' of the lower level HTB qdiscs is a little > illusionary.I thought to use it as ceil limit for deeper children where actual user htb''s would reside, so that they can be divided evenly (that is, there should be subclasses for 20:1/30:1..)> Instead of using PRIO qdisc, it''s probably worth a try to use > the prio parameter of HTB itself. It won''t have exactly the > same effect, but sharing will work (since you''re using a single > HTB qdisc then) and maybe it''s still sufficient for you.I''m actually using such setup right now - seems far too "friendly", to achieve good results I had to set pretty low ceil for low priority classes. Thought I''ll try to tweak it again.> This filter rule is WRONG. You tell the top qdisc to enqueue traffic > into a class that''s not even a child of this qdisc. Even if traffic > would be enqueued that way, it wouldn''t have traversed the prio > qdisc then, therefore you wouldn''t get the effect you wanted.Ah, I see.> Attach the filter rules to the qdiscs/classes they belong to only. > In this case, it would probably be parent 40: instead of parent 1:.Then something like this seems to work, but isn''t it overcomplicated? -- tc filter add dev eth0 protocol ip parent 1: prio 0 handle 1 fw flowid 1:1 tc filter add dev eth0 protocol ip parent 1:1 prio 0 handle 1 fw flowid 10:2 tc filter add dev eth0 protocol ip parent 30: prio 0 handle 1 fw flowid 30:1 -- Using other selectors instead of fw would seem optimal, but I would loose l7.> Care to explain why you want this setup? > It seems somehow impractical to me.Main traffic would be in prio 2 band, only known interactive would go to prio 1, and known waste to prio 3. If there is nothing going on, I would like to let any p2p downloads etc. full speed, but as soon as important traffic appears they should be nearly stopped. Of course, additional problem is that user could actually get 3x traffic if he is using all bands. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/