Re: [LARTC] Shaping incoming VoIP traffic fails
On 11/15/06, Daniel Musketa [EMAIL PROTECTED] wrote: On Wednesday 15 November 2006 12:07, Daniel Musketa wrote: Could I setup HTB better than below? Should I reduce eth1's queue length (now 1000)? If yes, how? The txqueuelen can be changed by ip link set eth1 txqlen len I tried values of 100 and 3 but can't hear an improvement. I can watch traffic coming in on ppp0 with `iftop` and it never exeeds 900kbit. Why could a 2000kbit headroom be not enough for clean receiving of 80kbit VoIP data? Because you are not on the controlling side. The router upstream of you doesn't have the concept of priority of the voip traffic so what comes first, goes out first. Also if the download side can send at a higher rate than you line can handle, there will be a queue of packets at the router handling the bandwidth limititation. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping incoming VoIP traffic fails
Am Donnerstag, 16. November 2006 17:37 schrieb Larry Brigman: On 11/15/06, Daniel Musketa [EMAIL PROTECTED] wrote: I can watch traffic coming in on ppp0 with `iftop` and it never exeeds 900kbit. Why could a 2000kbit headroom be not enough for clean receiving of 80kbit VoIP data? Because [...] what comes first, goes out first. Also if the download side can send at a higher rate than you line can handle, there will be a queue of packets at the router handling the bandwidth limititation. `iftop` shows me a rate of 800kbit for packets going out to the LAN on eth1. This is the ceil value for egress shaping from router to LAN. But I also can watch the download rate of packets coming in from ppp0. And it's never more than 900kbit, so TCP's mechanism of lowering TX speed after delayed/missing ACKs seems to work. To me it looks as if there wasn't a filled queue on the ISP's side of the line. `tc -s ...` shows me a backlog of about 20p in the download class. I still can't understand why more than 2 Mbit free bandwith and an empty queue can cause drop outs ... mmh ... Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Shaping incoming VoIP traffic fails
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? Thanks. Daniel 8 INT=eth1 # creating root and root class tc qdisc add dev $INT root handle 1: htb default 10 tc class add dev $INT parent 1: classid 1:1 htb rate 1000mbit prio 0 # class for not forwarded traffic (and sfq leaf) tc class add dev $INT parent 1:1 classid 1:10 htb \ rate 997mbit ceil 1000mbit prio 1 tc qdisc add dev $INT parent 1:10 handle 10: sfq perturb 10 # class for forwarded traffic tc class add dev $INT parent 1:1 classid 1:11 htb \ rate 2500kbit ceil 2500kbit prio 0 # class for highest prio VOIP (and sfq leaf) tc class add dev $INT parent 1:11 classid 1:110 htb \ rate 200kbit ceil 2500kbit prio 0 tc qdisc add dev $INT parent 1:110 handle 110: sfq perturb 10 # class for higher prio traffic (and sfq leaf) tc class add dev $INT parent 1:11 classid 1:111 \ htb rate 1200kbit ceil 1500kbit prio 1 tc qdisc add dev $INT parent 1:111 handle 111: sfq perturb 10 # class for low prio traffic (and sfq leaf) tc class add dev $INT parent 1:11 classid 1:112 htb \ rate 100kbit ceil 800kbit prio 2 tc qdisc add dev $INT parent 1:112 handle 112: sfq perturb 10 # filters for forwarded traffic tc filter add dev $INT parent 1: prio 0 protocol ip handle 110 fw flowid 1:110 tc filter add dev $INT parent 1: prio 1 protocol ip handle 111 fw flowid 1:111 tc filter add dev $INT parent 1: prio 2 protocol ip handle 112 fw flowid 1:112 # iptables ruels for marking forwarded traffic # put everything to lowest prio iptables -t mangle -A FORWARD -o $INT -j MARK --set-mark 112 # VOIP traffic - 110 iptables -t mangle -A FORWARD -o $INT -p udp --sport sip \ -j MARK --set-mark 110 iptables -t mangle -A FORWARD -o $INT -p udp --dport sip \ -j MARK --set-mark 110 iptables -t mangle -A FORWARD -o $INT -p udp --dport 1:10500 \ -j MARK --set-mark 110 # higher prio iptables -t mangle -A FORWARD -o $INT -p tcp -m multiport \ --sports 22,80,443,143 -j MARK --set-mark 111 iptables -t mangle -A FORWARD -o $INT -p icmp -j MARK --set-mark 111 8 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping incoming VoIP traffic fails
On Wednesday 15 November 2006 12:07, Daniel Musketa wrote: Could I setup HTB better than below? Should I reduce eth1's queue length (now 1000)? If yes, how? The txqueuelen can be changed by ip link set eth1 txqlen len I tried values of 100 and 3 but can't hear an improvement. I can watch traffic coming in on ppp0 with `iftop` and it never exeeds 900kbit. Why could a 2000kbit headroom be not enough for clean receiving of 80kbit VoIP data? Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
