On Thursday 28 November 2002 17:45, Abraham van der Merwe wrote:
> Ok, so it is important to make the quantum proportional to the rate, but
> what happens if you have different ratios, e.g. you have the following
> classes
>
> rate 512kbit
> rate 256kbit
> rate 64kbit
> rate 32kbit
>
> For the last two, you obviously need to tweak r2q so that the quantum is
> still larger than the mtu (1500 bytes), so you can do
>
> rate 64kbit r2q 5 # quantum = 1600 bytes
> rate 32kbit r2q 2 # quantum = 2000 bytes
>
> Now you don't actually have quanta that's proportional to the rate so
> theoretically this is going to be worse than just making all the quanta =
> 1500. What do I do in this case?
Quantum is used for bandwdith that exceeds the rate. So I should go for the
options where the smallest classes are ok. If you have a class with ceil =
100 and rate = 1, then you have a big change that you need quantum. If you
have a class with rate = 99 and ceil = 100, quantum is less important.
On the other hand, the rule that quantum > mtu is only needed for packets that
are mtu bytes. If you have packets that are maximum 1000byte, you can take
quantum > 1000.
> You don't have to, but HTB assumes a mtu of 1600 by default which is
>
> a) wrong in most cases
> b) not always the same (e.g. loopback default is 16436)
>
> ------------< snip <------< snip <------< snip <------------
> root@oasis:~# tc class add dev eth0 parent 1:1 htb help
> Usage: ... qdisc add ... htb [default N] [r2q N]
> default minor id of class to which unclassified packets are sent {0}
> r2q DRR quantums are computed as rate in Bps/r2q {10}
> debug string of 16 numbers each 0-3 {0}
>
> ... class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS]
> [ceil R2] [cburst B2] [mtu MTU] [quantum Q]
> rate rate allocated to this class (class can still borrow)
> burst max bytes burst which can be accumulated during idle period
> {computed}
> ceil definite upper class rate (no borrows) {rate}
> cburst burst but for ceil {computed}
> mtu max packet size we create rate map for {1600}
> prio priority of leaf; lower are served first {0}
> quantum how much bytes to serve from leaf at once {use r2q}
>
> TC HTB version 3.3
> root@oasis:~#
> ------------< snip <------< snip <------< snip <------------
>
> See, mtu = 1600 by default.
Of course it depends on where the mtu is used in the calculatins. Maybe it's
parameter that's not so important in the calculations.
> While I'm on the topic of mtu's - should the mtu which you specify include
> the frame header (i.e. 1500 + 14 bytes for ethernet) or without the frame
> header?
I think with the frame header. When htb kicks in, the packets are ready to
send so the header is already included.
> Ah thanks. So for all practical purposes you can just set the priority of
> all filters to the same value if you don't mind in which order the filters
> are matched?
Indeed.
> I'm not sure I understand what you're saying. Can't you specify a parent
> ceil or can't you specify a child ceil that is higher than the parents?
> Which one is it or is it both?
>
> If it is the first, I take it means you can't have
>
>
>
> +-- class 1 (rate 64kbit ceil 128kbit)
> | +-- class 1.1 (rate 32kbit)
> | +-- class 1.2 (rate 48kbit)
> +-- class 2 (rate 64kbit ceil 128kbit)
> +-- class 1.1 (rate 64kbit)
>
> in other words class 1 & 2 can't borrow from each other. Is that correct
> (would be a bummer if that is the case)?
They can borrow from each other, but I miss some ceil paramters :
+-- class 1 (rate 64kbit ceil 128kbit)
| +-- class 1.1 (rate 32kbit ceil 256kbit)
| +-- class 1.2 (rate 48kbit ceil 256kbit)
+-- class 2 (rate 64kbit ceil 128kbit)
+-- class 2.1 (rate 32kbit ceil 128kbit)
+-- class 2.2 (rate 32kbit ceil 128kbit)
Class 1.1 and class 1.2 can use 256 kbit, even if the parent ceil is 128kbit.
Class 2.1 and class 2.2 are better, they can share the same 64kbit, but they
never can ask for more then the parent ceil because there own ceil don't
allows this.
> Hmm, lets say I want to do this:
>
> 1. shape/prioritize some subnets according to some rules
> 2. shape/prioritize some protocols according to some rules
>
> (1) should be evaluated and then the data stream should be passed on to (2)
> and be evaluated again according to that set of criteria. is this possible?
Yes, buy creating a smart htb setup. Not all of this is possible, classes
with different parents can't share the same bandwidth :
+-- class 1 (rate 64kbit ceil 128kbit)
| +-- class 1.1 (rate 32kbit ceil 256kbit)
| +-- class 1.2 (rate 48kbit ceil 256kbit)
+-- class 2 (rate 64kbit ceil 128kbit)
+-- class 2.1 (rate 32kbit ceil 128kbit)
+-- class 2.2 (rate 32kbit ceil 128kbit)
You can not say that class 1.2 and 2.2 are sharing the same bandwidth or they
may use 64kbit together.
There is a work around. You can create multiple imq devices and redirect the
traffic to it. So you can shape on the imq device and the real device. But
it will also introduce extra delays because the packets have to travel though
an extra queue.
> One more thing which I'm not completely clear about yet:
>
> What happens when you have a child class which have a higher rate/ceil than
> the parent? Is this illegal or not? If not, what happens?
It's not illegal. But it will be less clear to figure out what will happen.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
