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

["Stefan Bauer" <sb@plzk.de>]

Hi Martin,

thank you for your time and help. You are right, i queued all traffic excect traffic from 192.168.0.101 to class 1:30 but with no special threatment for specific packages.

So because i limited the link throughput, the upstream device was able to better deal with the packages it has to process and that improved the upload/download throughput.

It seems to be better in terms of performance to limit the link on my "site" and avoid congestion at the upstream device. Even though both devices have a queue i still do not see, why it's better to not let the modem do the "job".

Stefan

-----Ursprüngliche Nachricht-----
> Von:Martin A. Brown <martin@linux-ip.net>
> Gesendet: Son 7 Februar 2016 17:33
> An: Stefan Bauer <sb@plzk.de>
> CC: lartc@vger.kernel.org
> Betreff: Re: Improved performance on up/download even though only sip was prioritized - please explain
> 
> 
> Greetings Stefan,
> 
> >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?
> 
> Without more information, I cannot identify the exact explanation, 
> however, I can give you a partial answer.
> 
> Your HTB script does this:
> 
>    tc qdisc add dev pppoe-wan root       handle 1:    htb default 30
> 
> Point #1: (observation)
> -----------------------
> So, you say that you are classifying only traffic from your 
> 192.168.0.101, however, defining "default 30" on your HTB root qdisc 
> means that packets otherwise not classified are going to show up in 
> class 1:30.
> 
> You can see that this class is handling bytes/packets in your 'tc -s 
> class show dev pppoe-wan' output.  Take a look at the dropped 
> statistics that you posted in class 1:30.  In addition to limiting 
> the dequeue rate, that class has even dropped 6548 packets.  
> [Dropping isn't always bad.]
> 
> In short, you are shaping all traffic dequeued on this interface.
> 
> 
> Point #2:
> ---------
> Since you are shaping all traffic dequeued on this interface, you 
> have reduced the number of packets in-flight passing through your 
> modem (or lower-layer device).  The most congested link here is very 
> probably the ATM (or ADSL? or something?) link between the modem and 
> your provider's head end gear (a DSLAM or some other concentrator).
> 
> It is this link that is usually saturated.  Before you employed any 
> shaping, the packets you were sending were getting queued in great 
> big traffic jams (Stau!) in the modem headed up to the head end or 
> (buffer bloat) queued in the head end gear to be sent to you.
> 
> Every queue has a size (or depth).  If the packet cannot be 
> delivered, then it is dropped.  This goes for upload packets as well 
> as download packets.  A small amount of packet dropping is routine 
> for the Internet.  But, as congestion increases and packet-dropping, 
> correspondingly, increases, then communication between endpoints can 
> be significantly impaired.  You were experiencing this significant 
> impairment when you were saturating your link without any HTB 
> shaping.  I suspect that this was an example of buffer bloat (a term 
> of art, widely publicized in 2009 and following).
> 
> Your success here is employing a shaper on your OpenWrt box.  You 
> have effectively made your box the smallest link (setting the 
> throughput to 800kbit/680kbit), you have effectively reduced the 
> congestion at the upstream device, the modem or provider head end.
> 
> 
> To get a more precise or exact explanation, you would need to be 
> able to observe the queuing states of the devices immediately 
> upstream of your OpenWrt box.
> 
> I hope this was a helpful explanation,