Hi Martin, thank you again. That was very well and clear explained! Stefan -----Ursprüngliche Nachricht----- > Von:Martin A. Brown <martin@xxxxxxxxxxxx> > Gesendet: Son 7 Februar 2016 19:14 > An: Stefan Bauer <sb@xxxxxxx> > CC: lartc@xxxxxxxxxxxxxxx > Betreff: Re: AW: Improved performance on up/download even though only sip was prioritized - please explain > > > Hello again Stefan, > > >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. > > But, the important factor here is that your OpenWrt device is > managing the shaping and scheduling. That goes for both default > traffic and your VoIP traffic. > > >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. > > Correct. But, more importantly the packets are no longer piling up > in congestion on the modem. So, the modem can pass packets through > right away and be ready to deal with the next. > > >It seems to be better in terms of performance to limit the link on > >my "site" and avoid congestion at the upstream device. > > Absolutely. > > >Even though both devices have a queue i still do not see, why it's > >better to not let the modem do the "job". > > The modem software/hardware was created to queue packets a certain > way and you didn't like how it did the job. > > Without knowing your specific modem (it is unimportant, anyway), I > will assert that the problem with your modem is the problem that has > been described by Jim Gettys as 'buffer bloat' [0]. > > The gear and provider configurations that lead to 'buffer bloat' > result in two problems: > > * deep queues trade throughput for latency (leading you to want to > prioritize your VoIP in the first place) > > * deep queues cause strange and unpleasant interactions with > packet drops [which packet drops, in turn, cause unpredictable > throughput numbers] > > You like better how your OpenWrt box is handling the queueing, > because it is making better tradeoffs between throughput and latency > (and packet dropping during saturation situations). All of this > results in a better experience for your users. > > Since you added the HTB qdisc, you have taught your OpenWrt device > to "slow down" its dequeue rate so that the packet congestion occurs > on the OpenWrt device, not on the modem. > > In short, you have just implemented the bottleneck rule [0]. Your > box has become the bottleneck (which is a good thing)! > > Best regards, > > -Martin > > [0] https://gettys.wordpress.com/ > http://www.bufferbloat.net/ > > [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/rules.html > > -- > Martin A. Brown > http://linux-ip.net/ > > -- 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
