From: Alessandro Ren <alessandro.ren@opservices.com.br>
To: lartc@vger.kernel.org
Subject: [LARTC] QoS for Voip.
Date: Mon, 19 Jul 2004 12:45:22 +0000 [thread overview]
Message-ID: <40FBC262.4090101@opservices.com.br> (raw)
In-Reply-To: <40F7F21E.7020305@opservices.com.br>
[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]
Thanks for the tips Brian,
Actually, I have many sorts of links, line PPOE ADSL, PPPOA ADSL
which a use PPTP over PPOA relay, radio links that connect in the
ethernet interface and cable modems.
To change the SFQ queue size I must recompile de kernel? I think a
saw some messages talking about that.
One other thing, I have the 1:10 a 1:20 class, let's assume there
is no voip traffic and all bandwidth is being consumed and it is in the
other class. When the voip traffic starts, there is a inicial delay
untill the 1:20 class starts to free bandwidth to the 1:10 class, as
I've noticed. Should I change the burst and cburst parameters to get a
better response or just make de queues smaller?
Thanks.
Brian Carrig wrote:
On 16 Jul 2004 at 13:35, Alessandro Ren wrote:
> Hello Brian,
>
> This is the basis for the wshaper.
> I have only two classes and I put voip on the 1:10 class and the rest in the 1:20. I
>
>
am not
>listing here, but I have the rule marking packets and sorting then into classes,
>
>
actually, I just put
>one port into the 1:10 class, that's the voip port and nothing else. I really want to
>
>
keep the best
>quality I can for voip, without bandwidth waste., because, if a page takes 1
>
>
seconds longer do
>load is ok, but if a voip packet starts to get delay, we got a problem,
> I think, I must have no queue for voip packets, all packtes should be forwarded as
>
>
soon as
>they get to the box, right?
>
>
You do actually have a queue for VoIP, as you implement SFQ for both the 1:10 and
1:20 classes. To the best of my knowledge the default setting for this queue is 128
packets. This may be too large for VoIP if latency is a concern so I would suggest
making this queue much smaller (limit option). Unfortunately without knowing the
particulars of your link I am unable to suggest a figure but have play around and see
what suits.
Regards
Brian
>#
>tc qdisc add dev $DEV root handle 1: htb default 20
>
># shape everything at $UPLINK speed - this prevents huge queues in your
># 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 $[4*$UPLINK/10]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 $[6*$UPLINK/10]kbit \
> ceil $[10*$UPLINK/10]kbit burst 6k prio 2
>
># all get Stochastic Fairness:
>tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
>tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
>
>
>Brian Carrig wrote:
> We run something similar allowing customers to place traffic into gold, silver or
> bronze classes. I reserve a fixed amount of bandwidth for each class and allow
>
>
them
> to borrow (I hate the idea of bandwidth going to waste). However, excess
>
>
bandwidth
> is offered preferrentially to gold, then silver before being offered to bronze.
> Because p2p and other bw consuming traffic are unlikely to be in the gold and
>
>
silver
> classes (they cost more) there haven't been any problems.
> I haven't really looked at the wondershaper script in much detail, how is voip
>
>
traffic
> prioritised?
>
> Regards
> Brian
>
> On 16 Jul 2004 at 12:19, Alessandro Ren wrote:
>
>
>
> I've been using a altered version of the wshaper script to priorize voip traffic for
>
> my
>
> customers.
> I'd like to know if someone in the list has any tips on QoS for voip, if someone
>
> has done some
>
> experimentation.
> I am using HTB and if someone on the LAN uses a p2p program, I started to
>
> noticed in the
>
> voip, with cuts, jitter and lag. If a reserve a fixed amount of bandwitdh not letting
>
> anyonbe
>
> borrow, it works fine, but then if noone is using voip, I have bandwidth going to
>
> waste.
>
> I think I need some fine tunning oin the HTB parameters, but I am not sure sure
>
> about that.
>
[-- Attachment #2: Type: text/html, Size: 5440 bytes --]
next prev parent reply other threads:[~2004-07-19 12:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-16 15:19 [LARTC] QoS for Voip Alessandro Ren
2004-07-16 15:53 ` Andreas Klauer
2004-07-16 16:54 ` Jason Boxman
2004-07-16 17:51 ` ibro tj
2004-07-16 18:38 ` Andreas Klauer
2004-07-19 12:45 ` Alessandro Ren [this message]
2004-07-19 13:19 ` Andreas Klauer
-- strict thread matches above, loose matches on Subject: below --
2003-11-28 8:12 [LARTC] QoS for VoIP Craig Main
2003-11-28 18:05 ` Kilian Krause
2007-09-27 2:31 ` Ming-Ching Tiew
2007-09-27 16:05 ` Santiago
2007-09-28 1:09 ` Ming-Ching Tiew
2007-09-28 2:45 ` Santiago
2007-09-28 14:07 ` Santiago
2007-10-01 1:00 ` Ming-Ching Tiew
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40FBC262.4090101@opservices.com.br \
--to=alessandro.ren@opservices.com.br \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox