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@xxxxxxxxxxxx> > Gesendet: Son 7 Februar 2016 17:33 > An: Stefan Bauer <sb@xxxxxxx> > CC: lartc@xxxxxxxxxxxxxxx > 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, -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
