Re: Improved performance on up/download even though only sip was prioritized - please explain

[Andy Furniss <adf.lists@gmail.com>]

Stefan Bauer wrote:
> Hi,
>
> my wan connection is 7000kbit down and 800kbit up.
>
> If i setup a download and upload at the same time, speed drops to 60KB/s down and 70KB/s up. This is an expected behavior without any shaping.
>
> As i only wanted to give my PBX (192.168.0.101) a fixed bandwidth for sip, i came up with the following:
>
> tc qdisc add dev pppoe-wan root       handle 1:    htb default 30
> tc class add dev pppoe-wan parent 1:  classid 1:1  htb rate 800kbit
> tc class add dev pppoe-wan parent 1:1 classid 1:10 htb rate 120kbit # voip
> tc class add dev pppoe-wan parent 1:1 classid 1:30 htb rate 680kbit # default
>
> iptables -t mangle -A FORWARD -s 192.168.0.101 -j CLASSIFY --set-class 1:10
>
> It does what i want, reserves 120kbit for traffic from 192.168.0.101.
>
> However the nice side effect is, that this also boosts my download/uploads and i have no idea why.
>
> Download is at 650KB/s and upload is around 65KB/s.
>
> Can anyone explain this behavior?

Martin has given good advice, I think there may also be a bit of luck 
involved as well.

Historically at least (I am out of date WRT current behavior)
a ppp connection has a a short qlen and if you don't make a queue for your
htb classes then the default fifos used will inherit this. It used to be 
possible for this to hurt throughput.

This means that had you happened to put the same rules on an eth 
(default qlen 1000)
then you would have seen the same buffer bloat as you so without.

The correct thing to do really is to use something like sfq/fq_codel on
the classes. Or even fifo/bfifo - but you then get to choose the length 
yourself.

One more comment below -

> Thank you in advance.
>
> Stefan
>
> root@OpenWrt:~# tc -s class show dev pppoe-wan
> class htb 1:10 parent 1:1 prio 0 rate 120000bit ceil 120000bit burst 1599b cburst 1599b
>   Sent 140214 bytes 295 pkt (dropped 486, overlimits 0 requeues 0)

You shouldn't really get drops here - it implies either not enough 
bandwidth reserved
or that the default fifo is too short.

In addition with htb it's possible to give more priority to "valuable" 
classes.