[Babel-users] how to set the pacing rate

[Christof Schulze]

On Wed, Dec 05, 2018 at 11:53:42AM -0800, Dave Taht wrote:
>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.
I had looked here before posting: 
https://www.freebsd.org/cgi/man.cgi?query=epoll&apropos=0&sektion=0&manpath=SuSE+Linux/i386+11.2&format=html

Apparently netbsd has it as well.

OpenBSD is missing it though.


>
>
>> 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
-- 
()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments