[Babel-users] some thoughts towards babel-1.9

[Dave Taht]

On Mon, Jan 2, 2017 at 4:21 PM, Juliusz Chroboczek <jch at irif.fr> wrote:
>> If that is the only error in two highly speculative documents then I'm
>> winning. :)
>
> You'll be helpful (I prefer this to "winning") when you implement some of
> your ideas and provide us with hard data to show that they are useful.

Well, the rabel repo exists for the crazy ideas... and unfortunately
testing them at scale tends towards being a PITA. At the time I took
babel-1.8pre for a spin I had multiple interrelated problems with
fq_codel, with airtime fairness, with bugs in powersave, crypto,
IPV6SUBTREES, and I forget what else.

I welcome suggestions for repeatable experiments. The fallout of all
that all-up testing was a ton of fixes outside of babel.

My intent is to repeat the experiments that I list below. What would
you (or those listening) consider definitive experiments showing the
usage of CS6, and unicast IHU?

> (For the record, CS6 and unicast IHU have both been implemented, and
> I still haven't seen any hard data that shows that they improve the
> behaviour of the network.)

While powersave was broken by the conversion to fq_codel'd intermediate queues,

http://blog.cerowrt.org/post/poking_at_powersave/

switching to unicast IHU fixed it. Now... theoretically... powersave
is fixed now... (at least on the ath9k, but maybe not the chip)

I can imagine powersave being broken elsewhere.

I do claim unicast IHU helps keep minstrel's stats fresh, but to show
that would require logging minstrel behaviors from idle to use and
back again, in a variety of tests. Testing both multicast and unicast
paths has helped elsewhere on my network(s) - ( a couple times when
dealing with broken firewall rules, also).

To me more unicast is desirable under nearly every circumstance on modern wifi.

...

I am not sure what sort of definitive proof you want about CS6.
Unicast CS6 is much more inefficient txop-wise vs a vs the aggregated
BE queue.

Multicast, there is no difference between the markings, I think,
although I have not evaluated what exactly the new
multicast-suppressing bridging code does in lede, and in fact, wasn't
aware it existed til today,

https://www.spinics.net/lists/netdev/msg412256.html

'cause I'd mostly been testing on x86.

...

I suggested that battlemesh add an experiment carrying 2x as many
routes as currently carried by wlan-slovenia. Metrics might be total
data transferred at "rate", the "fullness" of the route table, how
often we see triggered updates.... ?

I can easily create that many extra routes... hmm... ok, I WILL create
that many extra routes.

...

I have been til, oh, about today (airtime fairness entered net-next a
few hours back) busy with make-wifi-fast. Today I'm building net-next
on a couple boxes, and flashing a bunch of routers with that code and
recreating the setup I had for:

http://blog.cerowrt.org/post/babel_half_fail/

http://blog.cerowrt.org/post/failing_over_faster/

And will switch between rabel and babel after I get everything running again.

... Still borked so far as I know is the ath10k-ct firmware in adhoc,
so have to test that.

>
> -- Juliusz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org