Jody Shumaker wrote: >> HFSC doesn't support strict priorities (and neither does HTB, the >> priorities just affect unused bandwidth and is still limited by the >> ceiling). At least in the case of HFSC this is intentional, strict >> priority is not very friendly because it allows traffic to be >> entirely excluded, HFSC's goals are to enable flexible sharing by >> allowing to seperately specify bandwidth and delay requirements. >> If you really want strict priority you can use the prio qdisc as >> _child_ of HFSC. >> > > I always forget this about the prio and HTB. With HSFC does use of > the the max latency settings possibly get the desired goal from using > prio? I think this is what always appealed to me about HSFC from the > little I could understand. That if I had an interactive class, it'd > always favor getting those packets through sooner than others, trying > to honor a latency, if I set it up correctly. Exactly. I think strict priority is mostly used because of laziness, unknown conditions or unflexible algorithms. You almost never want one kind of traffic to be able to stall everything else (which BTW raises some doubts about Linux's default choice of a 3band prio qdisc). HFSC solves one and a half of these problems: without seperated bandwidth/delay specifications you are unable to express that some traffic should get good delay but doesn't need much guaranteed bandwidth, so you have to use priorities. The half solved problem is unknown conditions, it can also work in work-conserving mode, which means that it will work fine on wireless or similar networks or without any maximum bandwidth specification, but in that case it can only provide fair sharing, no absolute guarantees. Only half-solved because the unknown condition could also be the amount of bandwidth or the delay required, in which case strict priority might be the only viable option. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
