Re: Shaping incoming VoIP traffic fails

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel Musketa wrote:
Hello,

I'm trying to get lossless VoIP traffic over my 3000k/500k ADSL line. Shaping outgoing traffic is no problem: I set total ceil for outgiong device (ppp0) to 450kbit and put VoIP into highest prio class. Even during full upload the voice is clean on the other end.

Now I tried to get the same result for incoming data. I attached HTB to eth1 where the incoming voip traffic is forwarded to. But even when I set the ceiling for other traffic as low as 800kbit there are drop outs in incoming voice while "full" downloading.

Could I setup HTB better than below? Should I reduce eth1's queue length (now 1000)? If yes, how?

If you use child qdiscs on classes then you set qlen with their params, only people that don't bother need to play with txqueuelen.

...  sfq perturb 10 limit 16 ....

I think in this case - gig eth and because of gso/tso then it would be better not to shape on eth, but put ifb on ingress of ppp0. If you really needed to use eth rather than ifb I would not use a default/ use default 0 and only classify traffic from wan - unclassified goes unshaped with htb. You use iptables so may prefer the latter - but it looks like you could make tc rules to do the same for you in this case.

I would also give voip more of the bandwidth (rate) and make the lesser classes borrow.

Sfq is really only for bulk - not that it should make much difference as your voip class should never be backlogged, if set up as above.

To use ifb something like -

modprobe ifb
tc qdisc add dev ppp0 ingress
ip link set ifb0 up

tc filter add dev ppp0 parent ffff:  \
protocol ip prio 10 u32 match u32 0 0 \
flowid 1:0 \
action mirred egress redirect dev ifb0

Then add your htb rules/filters to ifb0

FWIW 64kbit 50pps voip = 80kbit IP level, for my dsl pppoa = 116kbit at atm level, for other pppoXs maybe 53*8*50 bit/s more. You can patch for dsl(atm) overheads, or wait for an in kernel solution.

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

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux