Note:
I'm approximately 90% sure all the stuff I have written below is correct,
but haven't tested anything.
For reference, I am copy-n-pasting the relevant lines from what I think is
the script you describe:
# DSL modem which destroy latency:
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1
# bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
burst 6k prio 2
> First, it is defined the root htb qdisc, as expected;
> then, it is defined the main (parent) htb class, with
> the total uplink as rate, also as expected; then,
> they are defined 2 child clases: first of them has
> also the total uplink as rate (!) and second, has the
> 90% of the total uplink as rate (!). So, sum of child
> classes equals to 190% of the total uplink (and
> parent) rate.
As you probably know, the total actual transfer rates of child classes
cannot exceed the specified ceil of the parent class.
In this case, since the specified rates of the children add up to higher
than the allowed ceil, bandwidth is allocated according to prio - the
class with a lower prio (higher priority) gets all the bandwidth its rate
(and the parent's ceil) allows. When the lower-prio class has idle
bandwidth, the high-prio class may send packets.
(Note that ceil=rate when ceil isn't specified.)
As the script is written, the bulk class is only able to send packets when
the interactive class has bandwidth free; if interactive traffic is 100%
then the bulk class is completely starved. Why, then, is the bulk rate 90%
instead of 100%? My only guess is that it takes into account how latency
suffers when bandwidth is high. Interactive traffic is worth causing high
latency, but bulk traffic is not.
> Why is this done that way?? I understand it goes
> against basic (htb) shaping rules, and also, it seems
> ilogical. Wouldn't it be better to define rates, for
> example, 90% for bulk traffic and 10% for interactive
> traffic, both with 100% ceils (or only interactive) ??
>
I think you might have gotten your 90% and your 10% transposed from what
you meant to write.
If the script were set up the way you have written, then the bulk class
would end up using 90% of the bandwidth when the two classes are
competing. When the rates of child classes add up to exactly the ceil of
the parent, then each class is guaranteed bandwidth up to its specified
rate, regardless of prio. When both classes are trying to send as quickly
as possible, there is no bandwidth left over for each class' ceil to make
a difference.
Going back to the script, I would do it a little differently than how it
is written. As I mentioned earlier, interactive traffic at 100% bandwidth
leaves no room at all for bulk traffic. I think it's nicer to guarantee
bulk traffic a little bit of bandwidth, like this:
# 80% - 100%, high priority for grabbing free bandwidth
tc class add dev $DEV parent 1:1 classid 1:10 htb rate $[8*$UPLINK/10]kbit \
ceil ${UPLINK}kbit burst 6k prio 1
# 20% - 90%, low priority for grabbing free bandwidth
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[2*$UPLINK/10]kbit \
ceil $[9*$UPLINK/10]kbit burst 6k prio 2
...but that's just my preference.
-Corey
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
