[Olsr-dev] CCC-Camp07 Results

[Sven-Ola Tuecke]

Hello,

while attending the 2007 CCC's summer camp in Finowfurt, I investigated a
bit the wireless terrain. Situation was unique, because we normally do not
have ~ 30..40 OLSR nodes in near range.

Besides the fact, that the air was pested for ~ 70%-80% with PROBE_RESPONSE
managment frames, I have recorded a profiling session with my PC. As you
may know, profiling does not run under uclibc, so I've used a normal Laptop
with a full grown Linux. The testesd version has all optimizations, namely
the "NO_DEBUG" which discards any OLSR_PRINTF(). You find the outcome here:

http://download-master.berlin.freifunk.net/sven-ola/gmon.txt

To my interpretation, olsr_input_lq_tc() is a good candidate for further
optimization. Every incoming LQ_TC will trigger a lot of mallocs (in this
situation for each neighbour included in the message one malloc). After
sending the unpacked LQ_TC through processing, the data is freed again.

Because of the protcol weaknesses regarding topology-information-spreading,
the LQ_TC is the most frequent message you will see in meshes using the
LQ/ETX extensions on the incoming queue.

Another small note about PROBE_REQUESTs. Obviously, too many gadgets on the
field. Those 20-40 start scanning. Which triggers 20-40 * AdHocNodeCount
anwers. Which in turn pollutes the air. I'am not sure about the side
effects, but in situations like these it is best to supress the automatic
answer directly handled by the chipsets when using IBSS/AdHoc.

HTH
// Sven-Ola