Hi there Emanuele,
: I tried your solution and it seems to work. Yet i'm experiencing
: an unexpected behaviour: when i try to fill the highest priority
: queue (expecting the lower priority traffic to starve), i see
: that the higher priority queue starts to grow, while some lower
: priority packets are served. This means that upon congestion of
: the link, the shaper stops working properly and does not apply a
: strict priority policy.
:
: I was wondering about the granularity of the service: in fact it
: may happen that, if the granularity is, say, 5 packets, the
: scheduler sees the higher priority queue empty, and it serves a
: "train" of 5 packets from the lower priority queue; while it is
: serving those packets, new packets arrive in the high priority
: queue, and have to wait until the scheuler have fully served the
: lower priority train. To avoid such a behaviour, i looked for a
: parameter that sets the granularity, but the documentation is not
: that clear about it: what are the parameters that set the
: granularity? Is it a problem of prio or of htb?
I realize I'm jumping in a bit late on this item, but I don't quite
understand why HTB as below should not work for you. Have you tried
a configuration like the below? You must know your available
bandwidth for this trick to work, but the following configuration
approximates a PRIO qdisc, but gives you the benefit of shaping.
class $parent, rate $MAX, ceil $MAX
|
+- class $voip, rate ( 0.95 * $MAX), ceil $MAX
|
+- class $other, rate ( 0.05 * $MAX), ceil $MAX
Remember that all the shaping and prioritizing in the world will not
help you if you are not the bottleneck. Your shaping/prioritizing
device must be the choke point.
While I don't have any direct experience with VoIP, I can imagine
that you might see an increased latency as a result of queuing delay
in your VoIP class. To limit latency induced by queuing delay, you
could create a child of the $voip class with bfifo or pfifo qdisc of
a specified depth/size. If, however, this is necessary, you may
simply need more bandwidth.
And, as an attempt to answer your question above....perhaps you
could try fiddling with the quantum setting on a given class. When
a given class has exceeded its rate, it can only transmit quantum
bytes per dequeue opportunity.
Good luck,
-Martin
--
Martin A. Brown --- Wonderfrog Enterprises --- martin@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
