LARTC - Sep 2006 - HTB shaping problem

Hi all !

I''m building a network appliance whose goals are to enhance Voip
quality on 512/128k DSL links. But, i have a voice quality problem,
and i think i''m doing something wrong, but i can''t find what.
Please
excuse my terrible english, i''m french.
>From what i''ve read, tc is the tool i need. I read the
documentations,
readmes and lartc.org howto, and came to the following setup:

NA = Linux-based network appliance (in fact a standard PC)

A--[Switch]--[eth1 NA eth0]--[DSL modem]

A = 1 pc and 1 ip phone on a 192.168.0.0/24 network
on the other side, the DSL modem is a bridge-type, thus i have my
internet ip on the NA  eth0 interface.
The DSL modem is actually a 15Mbit/1024Kbit ATM, but i want to limit
the upload to 128Kbit/s, to test the Voip thing.

My plan:

HTB qdisc with overall rate at 128kbit, and 2 classes, one with prio 1
(for VoIP) and one with prio 2 (For other data), each of them rated a
1kbit/s and ceiled at 128kbit/s. And, on top of this, SFQ qdiscs for
fairness.

So :

$TC qdisc add dev eth0 root handle 1: htb default 3
$TC class add dev eth0 parent 1: classid 1:1 htb rate 128kbit burst 6k
$TC class add dev eth0 parent 1:1 classid 1:2 htb quantum 1600 rate
1kbit ceil 128kbit  prio 1
$TC qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10
$TC class add dev eth0 parent 1:1 classid 1:3 htb quantum 1600 rate
1kbit ceil 128kbit  prio 2
$TC qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10

And my packets are classified by the following in the iptables mangle
table, forward chain: (my ip phone has 192.168.0.42, and pc
192.168.0.3)

Chain FORWARD (policy ACCEPT 3400K packets, 9214M bytes)
 pkts bytes target     prot opt in     out     source
destination
  284  118K CLASSIFY   udp  --  eth1   eth0    192.168.0.42
0.0.0.0/0           CLASSIFY set 1:2
  284  118K RETURN     udp  --  eth1   eth0    192.168.0.42
0.0.0.0/0
12679   19M CLASSIFY   tcp  --  eth1   eth0    0.0.0.0/0
0.0.0.0/0           CLASSIFY set 1:3
12679   19M RETURN     tcp  --  eth1   eth0    0.0.0.0/0
0.0.0.0/0

(here a thing that i don''t understand, is why i''m not
classifying the
packets with 2: or 3: ? when i do, the traffic is entirely stopped...i
surely miss something here.)

So, the packets get classified, and effectively, they are prioritized.
_But_ i do hear some cuts in the voice that''s sent through the NA,
when i''m doing some uploads.
(like some lazy wget --post-file=/tmp/some-big-iso-file.iso - Yeah i
could use nc, but.. :) )

Shouldn''t the voice be absolutely clean with this setup ? or am i
missing something important ?

For the sake of completeness:

# tc -s -d qdisc show dev eth0
qdisc htb 1: r2q 10 default 5 direct_packets_stat 871 ver 3.17
 Sent 25977039 bytes 18250 pkt (dropped 0, overlimits 28929 requeues 0)
 rate 0bit 0pps backlog 0b 28p requeues 0
qdisc sfq 2: parent 1:2 limit 128p quantum 1514b flows 128/1024 perturb 10sec
 Sent 162753 bytes 380 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 3: parent 1:3 limit 128p quantum 1514b flows 128/1024 perturb 10sec
 Sent 25678966 bytes 16999 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 42392b 28p requeues 0


# tc -s -d class show dev eth0
class htb 1:1 root rate 128000bit ceil 128000bit burst 6Kb/8 mpu 0b
overhead 0b cburst 1664b/8 mpu 0b overhead 0b level 7
 Sent 26406423 bytes 17759 pkt (dropped 0, overlimits 0 requeues 0)
 rate 127968bit 10pps backlog 0b 0p requeues 0
 lended: 17232 borrowed: 0 giants: 0
 tokens: 92249 ctokens: -187751

class htb 1:2 parent 1:1 leaf 2: prio 1 quantum 1600 rate 1000bit ceil
128000bit burst 1600b/8 mpu 0b overhead 0b cburst 1664b/8 mpu 0b
overhead 0b level 0
 Sent 166201 bytes 388 pkt (dropped 0, overlimits 0 requeues 0)
 rate 856bit 0pps backlog 0b 0p requeues 0
 lended: 388 borrowed: 0 giants: 0
 tokens: 6986400 ctokens: 77500

class htb 1:3 parent 1:1 leaf 3: prio 3 quantum 1600 rate 1000bit ceil
128000bit burst 1600b/8 mpu 0b overhead 0b cburst 1664b/8 mpu 0b
overhead 0b level 0
 Sent 26278072 bytes 17396 pkt (dropped 0, overlimits 0 requeues 0)
 rate 127144bit 10pps backlog 0b 25p requeues 0
 lended: 139 borrowed: 17232 giants: 0
 tokens: -20775252 ctokens: -87749



Thank you all !
-- 
f00ty
"Tact is the art of making a point without making an enemy."

f00ty wrote:
> Hi all !
> 
> I''m building a network appliance whose goals are to enhance Voip
> quality on 512/128k DSL links. But, i have a voice quality problem,
> and i think i''m doing something wrong, but i can''t find
what. Please
> excuse my terrible english, i''m french.
> 
>> From what i''ve read, tc is the tool i need. I read the
documentations,
> 
> readmes and lartc.org howto, and came to the following setup:
> 
> NA = Linux-based network appliance (in fact a standard PC)
> 
> A--[Switch]--[eth1 NA eth0]--[DSL modem]
> 
> A = 1 pc and 1 ip phone on a 192.168.0.0/24 network
> on the other side, the DSL modem is a bridge-type, thus i have my
> internet ip on the NA  eth0 interface.
> The DSL modem is actually a 15Mbit/1024Kbit ATM, but i want to limit
> the upload to 128Kbit/s, to test the Voip thing.
You can patch for accurate atm rates - it may be in kernel/for hfsc 
aswell one day.

http://ace-host.stuart.id.au/russell/files/tc/tc-atm/

You can also make htb more accurate if you change a define in 
net/sched/sched_htb.c - HYSTERESIS 0.

If you don''t patch you will need to set the sum of rates/ceils to well 
below 1024 (if that''s showtime rate).
> 
> My plan:
> 
> HTB qdisc with overall rate at 128kbit, and 2 classes, one with prio 1
> (for VoIP) and one with prio 2 (For other data), each of them rated a
> 1kbit/s and ceiled at 128kbit/s. And, on top of this, SFQ qdiscs for
> fairness.
> 
> So :
> 
> $TC qdisc add dev eth0 root handle 1: htb default 3
It''s best not to use default on eth when shaping for some other 
bottleneck, that way arp and other eth frames get let through unshaped 
by htb. You should use tc/iptables to send unmatched/classified IP to 
your own default class.
> $TC class add dev eth0 parent 1: classid 1:1 htb rate 128kbit burst 6k
> $TC class add dev eth0 parent 1:1 classid 1:2 htb quantum 1600 rate
> 1kbit ceil 128kbit  prio 1
It will be better to give rate 127kbit to the rt traffic.
> $TC qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10
I would use bfifo for rt and think about queue length, though an rt 
class usually shouldn''t be backlogged.

Andy.