On Fri, Sep 28, 2018 at 2:56 AM Toke Høiland-Jørgensen <[email protected]> wrote: > > Juliusz Chroboczek <[email protected]> writes: > > >>>> I think I agree with Juliusz here, I'd prefer Babel stay truthful and > >>>> instead change how fq_codel reacts to it. > > > >>> Yeah, perhaps fq_codel is not tolerant enough of bursts of packets. > > > >> Heh, I'm not sure there's a proper response to a large burst of > >> back-to-back packets that won't suck for all other traffic... > > > > I'm not a specialist, but my uneducated intuition would be that > > fq_codel can be tuned less agressively than plain codel -- the FQ > > element will prevent undue delay for unrelated flows. > > Yeah, it will hurt other flows less (or not at all), but that will > impact the intra-flow latency of TCP flows that do build a queue. So > it's a tradeoff...
While packet pacing is seemingly entering everything nowadays, you still can't get in more than you can put out. The "fq" part of fq_codel automagically paces things. A mix of unicast and multicast will acquire more bandwidth, not just from having different flows in an FQ'd world, but from being able to take advantage of the vastly higher rates from unicast, as we all know.... Still, when you are out of bandwidth, my argument is to "send less data", and that in the long run babel would need to automagically adjust the route announcement intervals to fit into the bandwidth available. It may well be I've been coping with another problem entirely, see previous mail. when it's your default route that is not being taken up, it's quite noticible. > > -Toke > > _______________________________________________ > Babel-users mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
