Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
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 --]

  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