[OLSR-users] CPU load

[Roar Bjørgum Rotvik]

Thomas Lopatic wrote:
> Hi there,

[...]

> * It would be interesting which parts of olsrd cause the high load. If 
> increasing the poll interval makes much of a difference, then it's the 
> periodically executed tasks like expelling timed out nodes from the 
> internal data structures. If increasing the HELLO intervals of all 
> surrounding nodes makes much of a difference, then it's the processing 
> of incoming packets.
> 
> * I've thought through the linear list thing again. True, there are more 
> efficient data structures and I have a gut feeling that we could save a 
> few lookups by caching the results of previous lookups. But then again, 
> the performance problems start already at fifty nodes, which shouldn't 
> be a problem for the existing data structures. (For potentially larger 
> sets we use a hash function to distribute the set elements over a number 
> of linear lists.)
> 
> To sum up, I don't have any idea why we have such a high CPU load. :-) 
> So, let's find out. I guess that the easiest change would be to lower 
> the debug level on a single node and see what this does to the CPU load 
> on this node. The next change could then be to increase the poll 
> interval length on the node and see whether this makes any difference.
> 
> If this still doesn't make any difference, we should come up with a 
> profiling version of olsrd. Has anyone ever used the profiling features 
> of GCC? Are they supported by the cross-compiler? I guess that this 
> would give us a good idea in which functions olsrd spends most of its 
> CPU cycles.

I have profiled some programs before, but not using cross-platform tools.

In short:
* Compile and link the code with GCC option "-pg -g -a" (-g and -a may 
be omitted, but they give extra information).
Code not compiled/linked with -pg will not be profiled.
* Run olsrd some time (longer run means more correct numbers) and then 
let olsrd exit normally (through return from main() or exit()). I think 
"kill <olsrd-pid>" will work.
* After olsrd quits, a profile-file (gmon.out?) is generated in the same 
directory as the olsrd binary run from.
* Then use "gprof olsrd" from the same directory to see profiling data. 
gprof has lots of options, where -p option for "flat profile" gives a 
list over functions called most (%-time, seconds used and number of 
times called).
* Then try to optimize the functions that have used most of the time, if 
possible, or try to optimize the way the function is used.
* It is possible to link the application agains profile-version of 
system libraries like glibc to include system calls like read/write, but 
this is not neccessary.

See http://sources.redhat.com/binutils/docs-2.10/gprof.html for easy 
user manual for gprof.

Regarding cross-plattform profiling, I think gprof need to be run with 
the olsrd binary used to profile and gprof.mon from the profile run and 
I don't think that running gprof in i386 on a non-i386 binary olsrd will 
work.
I guess you either have to run gprof on the target platform (the 
embedded platform), or run the profiling and testing on a standard 
computer where you have access to all the compiling and profiling tools 
easily (for example include a i386-laptop as a routing node for a while).

-- 
Roar Bjørgum Rotvik