[OLSR-users] dot plugin

[Sven-Ola Tuecke]

Hi aaron,

as far as I observe, there is no throughput penalty with that CPU load. 
Kernel IP packet forwarding should always have a higher prio - so 30% is O.K 
(my two cents). Anyhow, if there will be more nodes in the mesh, we need to 
reduce the TC/Hello times and the MprCoverage=9 we currently use.

I have another question to you: You have connected two or more WRTs by 
ethernet link with all your WLAN locations. Do you use the same IP address 
range for WLAN and Ether Interface? I experience some routing problems with 
the MID annoucements if WLAN and Eth have the same IP range. There are no 
problems if the ifaces have differnent ranges, e.g. WLAN=104.x.x.x/8 and 
Ether=10.x.x.x/8.

LG, Sven-Ola

"aaron" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> On Thu, 20 Jan 2005, Sven-Ola Tuecke wrote:
>
>> Hi,
>>
>> the freifunk-olsrd is compiled with the usual CFLAGS
>> ("-Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -g"). Thomas Lopatic
>> has pointed out, that extensive search through linear routing tables 
>> causes
>> the high CPU load. The Freifunk-Firmware now starts without debug, so 
>> here
>> in Berlin we have a load of 30% with a typical WRT54G (V2.0).
>
> same here. Could you also observe that with this high CPU usage the 
> available bandwidth is somewhat reduced by 50% on the linksysen? (instead 
> of 1.3 MBytes/sec "only" 600 something Kbytes/sec)
>
>>
>> If the olsrd starts loosing routes: Are you shure, the dot-draw does not
>> halt olsrd main thread execution during calculations? As far as I know,
>> there are some issues with threading and plugins right now. One of the
>> drawbacks with the dyn-gw-ping-enhancement also...
>
> dont know about that (yet)
>
> ciao,
> a.
>
>>
>> LG, Sven-Ola
>>
>> "aaron" <(spam-protected)> schrieb im Newsbeitrag
>> news:(spam-protected)
>>> On Thu, 20 Jan 2005, Bruno Randolf wrote:
>>>
>>> yes, definetely. It would fit to the observation that on the Linksys
>>> WRT54G olsrd consumes (with LQ & freifunk config) lots of CPU. As a
>>> consequence the thruput is reduced and in extreme situations it also 
>>> loses
>>> routes.
>>>
>>> BTW: was the freifunk olsrd 0.4.8 compiled with -O3 ? Another check that
>>> came to our minds here would be to reduce the polling rate but i am not
>>> sure if this is a good idea :)
>>>
>>> a.
>>>
>>>
>>> > hi aaron!
>>>>
>>>> i noticed the same problem with my perl script for drawing the topology
>>>> (http://meshcube.org/cgi-bin/trac.cgi/file/tools/olsr-topology-view.pl):
>>>> after some time olsrd starts loosiong routes, especially when the 
>>>> machine
>>>> has
>>>> high load. when i stop the script, the routes appear again. my 
>>>> suspicion
>>>> is
>>>> that reading the ipc port of the plugin too slow, slows down (lags)
>>>> olsrd -
>>>> is this possible?
>>>>
>>>> bruno
>>>>
>>>> On Wednesday 19 January 2005 00:52, aaron wrote:
>>>>> hi!
>>>>>
>>>>> while $TRUE; do
>>>>>    netcat localhost 2004 > topology.$DATENOW
>>>>>    sleep 10
>>>>> done
>>>>>
>>>>>
>>>>> seems to make olsrd lose routes after a few hours. Anybody else 
>>>>> noticed
>>>>> that / could somebody confirm?
>>>>>
>>>>> a.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> olsr-users mailing list
>>>>> (spam-protected)
>>>>> https://www.olsr.org/mailman/listinfo/olsr-users
>>>>
>>> _______________________________________________
>>> olsr-users mailing list
>>> (spam-protected)
>>> https://www.olsr.org/mailman/listinfo/olsr-users
>>
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users