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 10000: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 --------
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
On 11/15/06, Daniel Musketa <Daniel@musketa.de> 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.
Am Donnerstag, 16. November 2006 17:37 schrieb Larry Brigman:> On 11/15/06, Daniel Musketa <Daniel@musketa.de> 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
Hi, newbie question. In sch_htb.c:htb_dequeue() there is a comment "try to dequeue direct packets as high prio (!) to minimize cpu work". Does that mean that any unclassified packet (no class/filter applicable) is scheduled as the highest priority packet in HTB? If yes, what is the reason that the direct queue is not treated as the lowest priority best-effort? TIA for any info. -- Naren. Narendra C. Tulpule Principal Firmware Engineer, Staff 6450 Sequence Dr +1-858-404-2650 San Diego, CA 92121 narendra.c.tulpule@motorola.com
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.
Tulpule Naren-MGI2846 wrote:> Hi, > newbie question. In sch_htb.c:htb_dequeue() there is a comment "try > to dequeue direct packets as high prio (!) to minimize cpu work". Does > that mean that any unclassified packet (no class/filter applicable) is > scheduled as the highest priority packet in HTB? If yes, what is the > reason that the direct queue is not treated as the lowest priority > best-effort? > TIA for any info. > > -- Naren. > > Narendra C. Tulpule Principal Firmware Engineer, Staff > 6450 Sequence Dr +1-858-404-2650 > San Diego, CA 92121 narendra.c.tulpule@motorola.com >Yes, unclassified traffic is dequeued at hardware speed bypassing any defined qdiscs. It is up to you to specify default class and make it low prio. Right now i can''t thnik of any reason for that behavior. /ak
Ales Klok wrote:> Tulpule Naren-MGI2846 wrote: > >> Hi, >> newbie question. In sch_htb.c:htb_dequeue() there is a comment "try >> to dequeue direct packets as high prio (!) to minimize cpu work". Does >> that mean that any unclassified packet (no class/filter applicable) is >> scheduled as the highest priority packet in HTB? If yes, what is the >> reason that the direct queue is not treated as the lowest priority >> best-effort? >> TIA for any info. >> >> -- Naren. >> >> Narendra C. Tulpule Principal Firmware Engineer, Staff >> 6450 Sequence Dr +1-858-404-2650 >> San Diego, CA 92121 narendra.c.tulpule@motorola.com >> > > > Yes, unclassified traffic is dequeued at hardware speed bypassing any > defined qdiscs. It is up to you to specify default class and make it low > prio. Right now i can''t thnik of any reason for that behavior. > /akYou want arp/dhcp etc. to go to a low prio class? Andy.