[OLSR-users] CPU load

[Andreas Tønnesen]

Hi,

FYI, I wrote a section on resource usage in my thesis:
http://www.olsr.org/docs/report_html/node149.html
it might be worth checking out. It could be interesting to use
the results for comparision with current results.

Due to the use of multiple treads in olsrd at the time - the results
are not complete. I have sucessfully used:
http://sam.zoy.org/writings/programming/gprof.html
on multithreaded applications since.

- Andreas

Roar Bjørgum Rotvik wrote:
> 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).
> 

-- 
Andreas Tønnesen
http://www.olsr.org