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:1 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. 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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
