On Fri, 2006-02-24 at 07:27 +1000, Russell Stuart wrote:
> On Thu, 2006-02-23 at 10:23 +0100, Andreas Klauer wrote:
> > Another way of indirect headroom would be to hard limit the Web class,
> > i.e. give the Web class a lower ceil than the other classes. This way,
> > there is bandwidth that the Web class can't use no matter what, even
> > if the link is completely empty.
>
> That is the right answer - it would achieve what I want.
> In hindsight it seems so obvious I don't know why I
> didn't think of it myself.
Turns out it didn't do what I wanted. But there is a
way to force HTB to do what I wanted, and I think it is
unusual enough to document by posting it here.
To recap: what I wanted to do to was reserve approx 20%
of the bandwidth as headroom for VOIP. The headroom was
to prevent the TCP faststart of new incoming connections
from hitting the VOIP traffic. The headroom bandwidth
was must remain unused, unless VOIP itself was forced
to eat into it. Another way of saying the same thing
is I wanted to allocate some bandwidth to VOIP that
it would not lend to other classes.
Example:
VOID - Assured Rate 30%, 20% of which can only be
used by VOIP. Lowest latency.
INTERACTIVE - Assured Rate 20%, all of which may be
borrowed by other classes. Middle Latency.
BULK - Assured Rate 50%, all of which may be
borrowed by other classes. Highest Latency.
HTB Class structure the implements this:
htb class parent 1: classid 1:10 rate 80% ceil 100%
htb class parent 1:10 classid 1:11 rate 30% ceil 100%
htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf]
htb class parent 1:10 classid 1:20 rate 70% ceil 80%
htb class parent 1:20 classid 1:21 rate 20% ceil 80% prio 1 [interactive leaf]
htb class parent 1:20 classid 1:22 rate 50% ceil 80% prio 2 [other leaf]
This is the small class tree I can think of that does it.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
