[Babel-users] unicast attempt breaks timestamping

[Dave Taht]

On Mon, Jan 9, 2017 at 8:31 AM, Baptiste Jonglez
<baptiste at bitsofnetworks.org> wrote:
> On Mon, Jan 09, 2017 at 03:18:02PM +0100, Juliusz Chroboczek wrote:
>> > Can you provide the patch in question?
>>
>> I cannot find the original patch, but it basically consists in always
>> taking the alternative (else) branch in the conditional at line 1666 in
>> message.c.
>>
>> > Is there any reason why you couldn't send hellos alongside the IHUs?
>>
>> Yes, Hellos cannot be sent over unicast in the current protocol.  So if
>> all IHUs are sent over unicast, the timestamps are ignored.
>>
>> I see two solutions:
>>
>>   - extend the IHU timestamp sub-TLV to allow an optional timestamp,
>>     perhaps only used when sent over unicast;
>
> I just checked [1], we should be able to do that without breaking
> interoperability.  Nice.
>
> Dave, do you want to give it a try?

Sure!

I am quite confident that the RTT metric will deoptimize modern wifi
under load in favor of any other interface on the device... on
everything that doesn't have ATF. (see attached)

(The weird way that I use babel in this environment is to generate a
persistent identifier fd99::XX, so I can find a given device again
after moving it from wifi link to wifi link)

My primary focus is to find ever more ways to blow up the ATF patches,
and certainly adding babel into the mix makes for more "interesting"
results. I'm deploying a variety of devices at varying ranges, but I
started with the chip first as it's debian....

And sigh.

I am seeing 16+ second ping times on the "chip", under load, at 20ft
distance (and have similar results on nearly every other wifi chipset
besides the ath9k - but usually further than that). Using babel on
such a link usually disconnects it inside of 60 seconds on a test.

(chip wifi driver appears to be a single giant FIFO queue, does not
respect CS6 markings, does not put multicast in a special queue,
powersave on or off doesn't matter (I'm still exploring the powersave
issues I hit last time on the pi3), and this is the story on nearly
everything that doesn't use mac80211)

... so while I would hope that a working RTT metric on this kind of
crappy wifi would quickly de-optimize that sort of box out being a
primary wifi hop and router...  and will gladly test babel changes
throughout the next few months of test run...

It doesn't fix the extraordinary bufferbloat on nearly evertyhing
outside my ath9k bubble that I'm trying not to be depressed about.

(the chip was cool because it's 20 bucks with a battery)

>>   - extend the protocol to allow unicast Hellos.

+1

> I don't see the implications of such a change, so I can't really give an
> opinion.
>
> Baptiste
>
> [1] https://github.com/jech/babeld/blob/master/message.c#L245
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slow_chip_boom.png
Type: image/png
Size: 157316 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20170109/f4e3f48f/attachment-0001.png>