Stuart Henderson <s...@spacehopper.org> writes: > This is quite a different rule; the old one limits outgoing bandwidth to > 100Kb/s and _within that 100Kb/s_ it prioritizes certain traffic. This > suggested replacement isn't throttling the packets going out of the > interface at all, so unless there's a huge amount of data being sent, the > priorities aren't going to come into play.
Priorities won't make much difference unless you're close to your actual bandwidth limit, certainly. In the fairly common case where actually available bandwidth is different (less than) your interface bandwidth, you probably want a queue setup in place with a defined upper limit to play with. > I'm not sure how "set prio" fits together with the new queueing code yet, Well, the main difference is that in the new world priorities and queues are independent-ish. Queues serve to slice up your bandwidth into known-sized chunks (which may be flexible, hfsc-style), while priorities play within whatever limits are in place. You can get rather close to the queues with fixed priorities scheme by using both set queue and set prio in the same match or pass rule. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
