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