Hi. I''m trying to get a traffic shaper like this:
------
VoIP pkts --> | |_|
------ \ |
---O ->
------ /
Data pkts --> |
------
In this shaper voip packets are in a different queue than any other kind of
packet. I want a data packet to be served only when no packets are in the
voip queue (when voip queue is empty).
Furthermore the total traffic that leaves this shaper needs to be limited to
a specific (and precise) value of bandwidth, like a token bucket.
I can''t use something like this (PRIO + TBF) because in this way when
"data
congestion" happens, voip packets may be lost too(packet drop appens on the
TBF queue):
------
VoIP pkts --> | |_|
------ \ ----- |
O ---> |---O ->
------ / -----
Data pkts --> |
------
I also can''t use HTB because it doesn''t provide a priority
mechanism like my
needs, and CBQ because his bandwidth limiting algorithm isn''t very
precise
(according to the documentation).
How can I solve this problem using tc qdiscs?
Thanks
--
Emanuele
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
On Wed, Apr 05, 2006 at 03:18:06PM +0200, Emanuele Colombo wrote:> Hi. I''m trying to get a traffic shaper like this: > > > ------ > VoIP pkts --> | |_| > ------ \ | > ---O -> > ------ / > Data pkts --> | > ------ > > In this shaper voip packets are in a different queue than any other kind of > packet. I want a data packet to be served only when no packets are in the > voip queue (when voip queue is empty). > Furthermore the total traffic that leaves this shaper needs to be limited to > a specific (and precise) value of bandwidth, like a token bucket. > > > I can''t use something like this (PRIO + TBF) because in this way when "data > congestion" happens, voip packets may be lost too(packet drop appens on the > TBF queue): > > ------ > VoIP pkts --> | |_| > ------ \ ----- | > O ---> |---O -> > ------ / ----- > Data pkts --> | > ------ > > I also can''t use HTB because it doesn''t provide a priority mechanism like my > needs, and CBQ because his bandwidth limiting algorithm isn''t very precise > (according to the documentation).What about using HTB and *then* using PRIO as its leaf class? You would use HTB only to shape.
> What about using HTB and *then* using PRIO as its leaf class? You would > use HTB only to shape.Thanks, it could be a good idea! I''ll try this as soon as possible. Thanks! -- Emanuele
> What about using HTB and *then* using PRIO as its leaf class? You would > use HTB only to shape.Hi! 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? Thanx in advance Emanuele
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@wonderfrog.net
Emanuele Colombo wrote:>> What about using HTB and *then* using PRIO as its leaf class? You would >> use HTB only to shape. > > Hi! > 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?One thing you may try is to recompile sch_htb with HTB_HYSTERESIS[1] set to 0. You''ll get improved performance on slower links where you need the accurancy. [1] http://edseek.com/~jasonb/articles/traffic_shaping/buildkernel.html
2006/4/7, Martin A. Brown <martin-lartc@wonderfrog.net>:> > Hi there Emanuele, > > 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.I''ve already tried this way... with VoIP traffic this solution doesn''t work very well, because data traffic tries to use as much bandwidth as possible, and it creates some jitter and delay on voice data...> 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.don''t need more bandwidth, I need that data bandwith is reduced!> 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.I tried changing quantum and r2q parameters of HTB, but I can''t solve this problem... setting a low value of quantum results in decreasing real throughput, and it also introduces dependence on packet size... Another test I''ve done is to create only a prio qdisc (without HTB) and make the phisical layer slower than incoming traffic. It appears to be a problem of prio, because the same problem of queuing in high priority queue happens. Emanuele
2006/4/7, Jason Boxman <jasonb@edseek.com>:> One thing you may try is to recompile sch_htb with HTB_HYSTERESIS[1] set to 0. > > You''ll get improved performance on slower links where you need the accurancy. > > [1] http://edseek.com/~jasonb/articles/traffic_shaping/buildkernel.htmlOk, I''ll try, thanks! Emanuele