welcome back! On Tue, Sep 18, 2018 at 4:19 PM Juliusz Chroboczek <[email protected]> wrote: > > > (I ran across this babelweb pic from my old c.h.i.p + rtod experience, > > which cracked 16sec of delay in the mcast queue: > > Bufferbloat in the driver queues?
In that case yes, the driver had an infinitely long mcast queue. Once the number of routes cracked a certain point, updates across the 1mbit "bus" hit RFC970. One answer of course is to fix the driver (which I never got around to), another is to think about some sort of delay based rate control, and to ensure hello packets get out on reasonable intervals. ... Now that bufferbloat is fixed in several wifi cards (ath9k, ath10k, mt76, and soon iwl), and we don't have infinitely long queues... new problems are rearing their heads. Recently I tried to deploy a few babel 1.8.2 nodes with the latest openwrt, which I had to back out rapidly because I was dropping so many babel packets under contention. A patch to universally enable babel ecn in net.c "solves" this problem, even with no defined response, my network - particularly the congested gw in the middle - got a *ton* more reliable. But this opens whole cans of worms as to what the right approach is to respond to CE marks (mine is to treat it like a loss - or like half a loss - but to never expire the route merely because it is congested) - and doesn't solve the infinite queue problem either. Honestly I'd hoped to have unicast to deploy rather than continue to fiddle with ecn. https://www.bufferbloat.net/projects/ecn-sane/wiki/ -- 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
