[LARTC] QoS for Voip.

[LARTC] QoS for Voip.

[Alessandro Ren]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]


     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.
      Any indeas?



[-- Attachment #2: Type: text/html, Size: 910 bytes --]

Re: [LARTC] QoS for Voip.

[Andreas Klauer]

Am Friday 16 July 2004 17:19 schrieb Alessandro Ren:
>     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.

Have you tried filtering P2P traffic (using IPP2P or l7-filter)?
With HTB, I'd suggest to put it into a class with low prio and low rate, 
so P2P has to borrow nearly everything. But on the other hand you should 
make sure Voip can't max out the line either. It's not easy to find a 
balance there.

At home, I have a different approach. There's just fair sharing between 
custumers (err, flatmates). Each person gets his HTB class, all HTB 
classes have the same priorities and rates, so everyone gets the same 
amount of bandwidth no matter what it's used for (p2p, www, voip, gaming).
Prioritizing interactive over http over p2p traffic is then also done on a 
per-user basis. This way it doesn't matter to a single user what kind of 
traffic other users generates... the only guarantee there is that each 
user can get the same amount of bandwidth.

If this setup causes cuts, jitter and lag in voip, it's either because the 
same user is generating other traffic with same or higher priority than 
voip; or because there just isn't enough bandwidth available altogether to 
serve all the people.

However, that kind of setup requires a lot of classes in HTB (one per 
[active] client); so if there are too many clients, the rates per class 
get too low, which might impact HTB performance.

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS for Voip.

[Jason Boxman]

On Friday 16 July 2004 11:53, Andreas Klauer wrote:
<snip>
> At home, I have a different approach. There's just fair sharing between
> custumers (err, flatmates). Each person gets his HTB class, all HTB
> classes have the same priorities and rates, so everyone gets the same
> amount of bandwidth no matter what it's used for (p2p, www, voip, gaming).
> Prioritizing interactive over http over p2p traffic is then also done on a
> per-user basis. This way it doesn't matter to a single user what kind of
> traffic other users generates... the only guarantee there is that each
> user can get the same amount of bandwidth.

But how well does that scale?

# Default: Put stuff in class 2.

    $BIN_TC filter add dev $UC_DEV parent 1:$UC_MARK prio 100 \
                   protocol ip handle $UC_MARK fw flowid 1:$(($UC_MARK+2))

Would you want to do per user classifications to give SSH for each user a 
higher priority if you had, say, 230 users, for example?  Or would each user 
merely need to find for himself with his slice?

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS for Voip.

[ibro tj]

Hi,

the hint from Martin A Brown which I am experimenting
without regret yet is that you shoul decrease the
queue lenght to say 30 from the default 100 and also
reduce the MTU(MAX. TRANSFER UNIT) to the size of
typical voice traffic say 256 using

ip link set dev eth0 qlen 30
ip link set dev eth0 mtu 1000

Hope it helps.


Ibrahim T.


--- Alessandro Ren <alessandro.ren@opservices.com.br>
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.
>       Any indeas?
> 
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS for Voip.

[Andreas Klauer]

Am Friday 16 July 2004 18:54 schrieb Jason Boxman:

> But how well does that scale?

> Would you want to do per user classifications to give SSH for each user
> a higher priority if you had, say, 230 users, for example?  Or would
> each user merely need to find for himself with his slice?

I wrote something about having to many users in my mail too. :-) 
And I made clear that this setup is what I do at home and I do not have 
(thank god) 230 flatmates. So hopefully there were no 
misunderstandings. :-)

The interesting question is... are the 230 users all active at the same 
time. You only need classes for active users. And for that many active 
users, you need a lot of bandwidth if each of them wants to be doing VoIP 
and P2P so I don't see *that* many problems there. Of course, I don't have 
any practical experience there.

From the point of view of a big ISP, I'd probably make my own life easier 
by just providing constant (ceiled) rates, no borrowing. Global 
prioritization (where theoretically each user can use the whole available 
bandwidth) has the risk that if a user finds out a special type of traffic 
is being prioritized, he abuses this. For example, he could use a 
prioritized protocol to tunnel other stuff through it... think of P2P over 
VoIP. If VoIP is allowed to use all the bandwith, such a user could steal 
way too many bandwidth from others. The only way to prevent this sort of 
thing would then be to make no global prioritizations, but give each user 
his own sandbox (which is more or less the idea behind my home setup).

Depending on the bandwidth your clients get, you don't have to do things 
like prioritizing SSH and VoIP for them... my ISP doesn't do that for me 
either, at least not on such a close level. And I doubt I would like my 
ISP to decide for me which traffic to prioritize for me. I just do this 
kind of stuff on my own home machine.

I hope it makes sense in a way :-0 It was a rather hasty rant, sorry

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] QoS for Voip.

[Alessandro Ren]

[-- 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 --]

Re: [LARTC] QoS for Voip.

[Andreas Klauer]

Am Monday 19 July 2004 14:45 schrieb Alessandro Ren:
>     To change the SFQ queue size I must recompile de kernel?

Yes. It's not dynamic. But you could use ESFQ instead, I think it allows 
specifying the queue length with the tc command.

> 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?

This is just guesswork, I haven't checked the code:

As far as I understand the way QoS is implemented in the kernel, a packet 
may only get out of the queue if the qdisc (in your case HTB) allows it 
to. If that's correct, the queue size should not matter, your problem is 
that HTB allows the 1:20 class to dequeue whilst 1:10 does not get a 
chance to do stuff. If you get a delay, then HTB is just too slow 
adjusting for the changed conditions.

I haven't noticed such a problem myself though, since there is usually 
always traffic in my classes...

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] QoS for VoIP

[Craig Main]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

Hi all,

I would like to prioritise all VoIP traffic on a linux router. I am new
to QoS, tc and TOS, to please be gentle.

My logic works like this:

1) identify the VoIP packets
2) mark packets using iptables (with TOS?)
3) use tc to prioritise the marked packets.

Is this logic correct? If not, where is it flawed?

I understand that VoIP used the udp protocol and has packet sized less
than 250 bytes. Is simply reducing the MTU on the interfaces good enough
to give better thoughput, without the lag of larger packets trying to
pass though?

Are there any good HOWTOS?

TIA

Regards
Craig
--
Craig Main
RHCE
ST Solutions
Cell: 082-323-4670
Home Tel: 011-760-1900
AIM: SATuxman; ICQ: 75815570
http://www.stsolutions.co.za
http://www.linuxsa.com


____________________________
I WILL NEVER WIN AN EMMY I WILL NEVER WIN AN EMMY I WILL NEVER WIN AN
EMMY I WILL NEVER WIN AN EMMY Bart Simpson on chalkboard in episode 9F21

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] QoS for VoIP

[Kilian Krause]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

Hi Craig,

> I would like to prioritise all VoIP traffic on a linux router. I am new
> to QoS, tc and TOS, to please be gentle.
> 
> My logic works like this:
> 
> 1) identify the VoIP packets
> 2) mark packets using iptables (with TOS?)
> 3) use tc to prioritise the marked packets.
> 
> Is this logic correct? If not, where is it flawed?

it can work, VoIP for me is H323, for SIP i haven't checked yet what
their ports are..

> I understand that VoIP used the udp protocol and has packet sized less
> than 250 bytes. Is simply reducing the MTU on the interfaces good enough
> to give better thoughput, without the lag of larger packets trying to
> pass though?

Well, reducing MTU is most probably not a good idea, as you force more
packets benig sent even when you can keep the overhead to just 1 packet
with large payload. so i wouldn't do that..
VoIP (speaking of H323) is UDP traffic on random ports but can be
limited by using either GnomeMeeting or nmproxy
(http://www.cryogenic.net/nmproxy.html), thouch i haven't tried the
latter so far..

As of GnomeMeeting you can simply use a match for UDP ports 5000-5003
(on a direct connection)...
For OhPhone and OpenMCU etc. the ports may vary.. If you don't use H245
tunneling there's also some TCP ports involved (for GM 30000-30010).

Using a GateKeeper will also have another port-range.. but checking
either source, mailinglist or support info of these products will shed
some light where you'll be most lucky matching their packets..

> Are there any good HOWTOS?

None that i know of, sorry..

Good luck! ;)

-- 
Best regards,
 Kilian

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[LARTC] QoS for VoIP

[Ming-Ching Tiew]

As you are probably aware, this is a ever green topic.

I have personally tried doing it, testing it and verifying it
and I am myself finding this problem challenging and frustrating.

Most of the scripts will recommend some form of rate limiting
( or policing ) on the download. But the challenge is how to 
determine the correct value for the policing ? 

Lot of the recommendation says use x % over the sales package 
figure. Is this the correct way to do it ? Should it be a more
engineering way to empirically determine it ?

What I noticed is that if I over-specify the x %, then I
will greatly limit the utilizable bandwidth. The LAN users will
noticed significant difference in download speed compared
to when QoS is not running. But if I under specify the
x %, then the entire VoIP QoS has no significance, and
the VoIP quality will be bad.

Any views or comments ?

--------------------------------------------
Important Warning! 

*************************** 

This electronic communication (including any attached files) may contain confidential and/or legally privileged information and is only intended for the use of the person to whom it is addressed. If you are not the intended recipient, you do not have permission to read, use, disseminate, distribute, copy or retain any part of this communication or its attachments in any form. If this e-mail was sent to you by mistake, please take the time to notify the sender so that they can identify the problem and avoid any more mistakes in sending e-mail to you. The unauthorised use of information contained in this communication or its attachments may result in legal action against any person who uses it.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS for VoIP

[Santiago]

The prio qdisc is the solution. Try this.

On Thu, 27 Sep 2007 10:31:08 +0800, Ming-Ching Tiew wrote
> As you are probably aware, this is a ever green topic.
> 
> I have personally tried doing it, testing it and verifying it
> and I am myself finding this problem challenging and frustrating.
> 
> Most of the scripts will recommend some form of rate limiting
> ( or policing ) on the download. But the challenge is how to 
> determine the correct value for the policing ?
> 
> Lot of the recommendation says use x % over the sales package 
> figure. Is this the correct way to do it ? Should it be a more
> engineering way to empirically determine it ?
> 
> What I noticed is that if I over-specify the x %, then I
> will greatly limit the utilizable bandwidth. The LAN users will
> noticed significant difference in download speed compared
> to when QoS is not running. But if I under specify the
> x %, then the entire VoIP QoS has no significance, and
> the VoIP quality will be bad.
> 
> Any views or comments ?
> 
> --------------------------------------------
> Important Warning!
> 
> ***************************
> 
> This electronic communication (including any attached files) may 
> contain confidential and/or legally privileged information and is 
> only intended for the use of the person to whom it is addressed. If 
> you are not the intended recipient, you do not have permission to 
> read, use, disseminate, distribute, copy or retain any part of this 
> communication or its attachments in any form. If this e-mail was 
> sent to you by mistake, please take the time to notify the sender so 
> that they can identify the problem and avoid any more mistakes in 
> sending e-mail to you. The unauthorised use of information contained 
> in this communication or its attachments may result in legal action 
> against any person who uses it.
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 
> -- 
> Este mensaje ha sido analizado por MailScanner
> en busca de virus y otros contenidos peligrosos,
> y se considera que está limpio.
> MailScanner agradece a transtec Computers por su apoyo.


--
Open WebMail Project (http://openwebmail.org)


-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
MailScanner agradece a transtec Computers por su apoyo.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS for VoIP

[Ming-Ching Tiew]

From: "Santiago" <santiago@elportal.net.ec>


> The prio qdisc is the solution. Try this.
>

I wonder if that's speaking from experience or speaking from
theoretical standpoint ? I have always been told, to control
the traffic, I have to be the slowest link in the chain.

And my question is how slow I should be ! If you are
not the slowest, you can't control. If you are damn slow,
you are under-utilizing your bandwidth.

Read this section of LARTC :-

        http://lartc.org/howto/lartc.qdisc.html

You also have to be sure you are controlling the bottleneck of the link. If
you have a 100Mbit NIC and you have a router that has a 256kbit link, you
have to make sure you are not sending more data than your router can handle.
Otherwise, it will be the router who is controlling the link and shaping the
available bandwith. We need to 'own the queue' so to speak, and be the
slowest link in the chain. Luckily this is easily possible.




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS for VoIP

[Santiago]

On Fri, 28 Sep 2007 09:09:20 +0800, Ming-Ching Tiew wrote
> From: "Santiago" <santiago@elportal.net.ec>
> 
> > The prio qdisc is the solution. Try this.
> >
> 
> I wonder if that's speaking from experience or speaking from
> theoretical standpoint ? I have always been told, to control
> the traffic, I have to be the slowest link in the chain.
> 
> And my question is how slow I should be ! If you are
> not the slowest, you can't control. If you are damn slow,
> you are under-utilizing your bandwidth.
> 
> Read this section of LARTC :-
> 
>         http://lartc.org/howto/lartc.qdisc.html
> 
> You also have to be sure you are controlling the bottleneck of the 
> link. If you have a 100Mbit NIC and you have a router that has a 
> 256kbit link, you have to make sure you are not sending more data 
> than your router can handle. Otherwise, it will be the router who is 
> controlling the link and shaping the available bandwith. We need to 
> 'own the queue' so to speak, and be the slowest link in the chain. 
> Luckily this is easily possible.
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 
> -- 
> Este mensaje ha sido analizado por MailScanner
> en busca de virus y otros contenidos peligrosos,
> y se considera que está limpio.
> MailScanner agradece a transtec Computers por su apoyo.


--
Open WebMail Project (http://openwebmail.org)


-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
MailScanner agradece a transtec Computers por su apoyo.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS for VoIP

[Santiago]

If you have for example 1024 Kbps, you have to create a class (maybe htb) 
about 920Kpbs to create the queue. Then you have to attach the prio qdisc to 
this class, mark the voip packets and send to class :1 in the prio qdisc.

Santiago
Ecuador
On Thu, 27 Sep 2007 12:05:16 -0400, Santiago wrote
> The prio qdisc is the solution. Try this.
> 
> On Thu, 27 Sep 2007 10:31:08 +0800, Ming-Ching Tiew wrote
> > As you are probably aware, this is a ever green topic.
> > 
> > I have personally tried doing it, testing it and verifying it
> > and I am myself finding this problem challenging and frustrating.
> > 
> > Most of the scripts will recommend some form of rate limiting
> > ( or policing ) on the download. But the challenge is how to 
> > determine the correct value for the policing ?
> > 
> > Lot of the recommendation says use x % over the sales package 
> > figure. Is this the correct way to do it ? Should it be a more
> > engineering way to empirically determine it ?
> > 
> > What I noticed is that if I over-specify the x %, then I
> > will greatly limit the utilizable bandwidth. The LAN users will
> > noticed significant difference in download speed compared
> > to when QoS is not running. But if I under specify the
> > x %, then the entire VoIP QoS has no significance, and
> > the VoIP quality will be bad.
> > 
> > Any views or comments ?
> > 
> > --------------------------------------------
> > Important Warning!
> > 
> > ***************************
> > 
> > This electronic communication (including any attached files) may 
> > contain confidential and/or legally privileged information and is 
> > only intended for the use of the person to whom it is addressed. If 
> > you are not the intended recipient, you do not have permission to 
> > read, use, disseminate, distribute, copy or retain any part of this 
> > communication or its attachments in any form. If this e-mail was 
> > sent to you by mistake, please take the time to notify the sender so 
> > that they can identify the problem and avoid any more mistakes in 
> > sending e-mail to you. The unauthorised use of information contained 
> > in this communication or its attachments may result in legal action 
> > against any person who uses it.
> > 
> > _______________________________________________
> > LARTC mailing list
> > LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> > 
> > -- 
> > Este mensaje ha sido analizado por MailScanner
> > en busca de virus y otros contenidos peligrosos,
> > y se considera que está limpio.
> > MailScanner agradece a transtec Computers por su apoyo.
> 
> --
> Open WebMail Project (http://openwebmail.org)
> 
> -- 
> Este mensaje ha sido analizado por MailScanner
> en busca de virus y otros contenidos peligrosos,
> y se considera que está limpio.
> MailScanner agradece a transtec Computers por su apoyo.
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


--
Open WebMail Project (http://openwebmail.org)


-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
MailScanner agradece a transtec Computers por su apoyo.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS for VoIP

[Ming-Ching Tiew]

From: "Santiago" <santiago@elportal.net.ec>

> If you have for example 1024 Kbps, you have to create a class (maybe htb)
> about 920Kpbs to create the queue. Then you have to attach the prio qdisc
to
> this class, mark the voip packets and send to class :1 in the prio qdisc.
>

That's what I am talking about. You said it **VERY** easily that "If you
have for example 1024 Kbps, you have to create a class about 920 Kbps ...".

But what's the reality. The reality is that you might not have
a 1024 Kbps link, even though the ISP you sign up with might
claim that. You don't know for sure. Even perhaps for most of
the days you have 1024 Kbps, certain peak hours you might
be clamped down to a lower figure due to congestion at the
BRAS of the ISP.

And how do you arrive at your magic figure of 920 kbps ?

And bear in mind that most ADSL are asymmetric, your uplink
is usually lower than your downlink. Even if you clamp down
your down link, if you don't police ( or rate limit ) your uplink,
you still can't really control the link. So in practice you will
actually police the rate of download to a figure slightly smaller
than your uplink speed. There you can see, your overall throughput
of the internet (download ) is significantly slowed down.




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc