On Mon, Nov 26, 2018 at 03:41:49AM -0800, Dave Taht wrote:
My followup just created a FOR_ALL_INTERFACES_UP macro which led to even less code. :)
\o/
Indeed they are. Do we really have to handle so many events that the complexity of using a timerwheel is justified?Elsewhere I've been dithering. The proof of concept for uthash in resend, was quite satisfying but far too much unneeded overhead (56 bytes per entry on 64 bits!! + the malloc overhead!), so I have been looking over khash and so forth ( https://github.com/attractivechaos/klib ) the benchmarks were impressive, but like all benchmarks, flawed - testing an integer hash, where we need 34 bytes of "some hash" (jenkins? spooky?), and x86 only, where I care mostly about mips, and I care about startup time for a hash a lot....- I figure reworking those benchmarks to (say) import a BGP route table, and then try to project how much SADR and p2p routes are used, and a real lookup/insert ratio in a benchmark would be more useful. But I get 14MOPs/sec on the basic benchmark on my x86 box on a million integers... lookups take 10ns.... Babel has an ordered "slot" concept in it... Elsewhere I was poking into the the evolution of the kernel's timerwheel thing ( https://lwn.net/Articles/646950/ ) which makes the valid point that most babel "timeouts" are really recurring events....
viele Grüße Christof -- () ascii ribbon campaign - against html e-mail /\ against proprietary attachments
signature.asc
Description: PGP signature
_______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
