[Babel-users] how to set the pacing rate

[Dave Taht]

On Tue, Dec 4, 2018 at 2:52 PM Christof Schulze
<christof.schulze at gmx.net> wrote:
>
> Juliusz,
>
> >I'd need to read up on data structures, as I don't currently understand
> >the tradeoffs between binary heaps and timer wheels. (Same goes for
> >dealing with resends. And Christof suggested that we should modify the
> >main event loop in babeld to use a proper data structure.)
>
> * Implement a generic task scheduler that could shamelessly be borrowed
>   from fastd or l3roamd and then modified to use whatever datastructure
>   being helpful to increase efficiency. In any case it looks to me as if
>   an abstraction layer could be helpful.

> * Given that babeld will be used in scenarios with many more interfaces
>   than before it could be worth moving from select to epoll. This would
>   also allow moving the FD_SET construction out of the loop.

epoll is not available in bsd. the equivalent is kqueue.

https://libevent.org/ wraps various mechanisms.


> The first point specifically will help in structuring the loop. The
> second will get rid of overhead in the kernel and allow us to move the
> setup of the fd outside.

My nemeses are C & mips. It was good to learn from markus on these
threads that golang finally worked on mips! Having mips as my primary
platform for a decade has stopped me from picking up a more modern
language like go, and I dearly miss associative arrays, green threads,
and the like. I am considering go for another project and the netlink
support in go has improved enormously since las I looked (
https://medium.com/@mdlayher/linux-netlink-and-go-part-2-generic-netlink-833bce516400
)

That said, I don't feel a go version of babel adds much to the party,
and that it would be better to focus on making babeld better -
finishing up hmac and dtls, fixing stuff like the broken wifi channel
detection, improving error handling and scaling performance.

I'm pretty convinced that hashing route lookups and using an abstract
route type will make a difference (thought experiment: a binary search
of 2048 34 byte routes will take ~11 probes, a hash, ~3 - processing a
packet of 50 routes will touch ~1000 32 byte cache lines, wiping out
a 32k dcache completely - but that's just packet processing, there's
resends and conflict resolution, filtering and disambiguation - some
of which do need insight into the actual route)

memory pools are easy to add to C, and helpful for reducing
fragmentation and gleaning statistics on memory use patterns, babel's
design is amiable to that with very few malloc/free pairs and < 10
main data structures. With a memory pool to start with... well...

as much as I initially liked the "dev" branch's API, I'm leaning
towards that abstract (int) route type, and instead of trying to fit
source specific, ipv4, ipv6 routes into a single 34 byte structure, to
stick them into a right-sized structure for each type.

choosing a memory pool design... a hash function... a hash table
design... in c... is my current sticking point in that other project
also (and why I yearn for go!)

Oy, a lot of work!

>
>
> [1] https://github.com/freifunk-gluon/l3roamd/blob/master/src/taskqueue.c
>
> viele Grüße
>
> Christof
>
>
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  against proprietary attachments
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740