[Olsr-users] Optimizing config file - mobility

[Puissance MaXximum Online]

Hello,

I'm currently testing olsrd with some small devices (iPaq, eeePC, HTC...) and I've read a lot of things about the configuration file. Most of the time, it's optimized for big networks with a lot of statics nodes.

I would like to optimize the configuration for a small mobile network (i.e. 10 nodes) with the following 
characteristics:
- very mobile nodes and no static node, no ap
-olsrd running on small devices (pda and htc with headset, etc.)
-no internet gateway
-no need to interact with non-olsr neighbours
-the network have to support voip traffic but users will speak very few
-the network must be very reactive and support small voip traffic (or small P2P communications)

In fact, to imagine, just think about small teams of firemen, about people in charge of security during outdoors events, etc.

I've read the archives and some documents speaking about olsrd and noticed some advices/tips/rules/etc and finally filled my configuration file like that:
DebugLevel 0 #The daemon runs in the background - Users don't need it...

IpVersion 4

FIBMetric "flat"

AllowNoInt no # We are not in a PCMCIA/USB hotswap environment and the interfaces should be always avaible...

Willingness 4 # Dynammically based on battery/power status seems to be a good idea for small devices. What about 7 ???

IpcConnect {

MaxConnections 0 # No GUI front-end in the wince, and no need to connect to the daemon

}

UseHysteresis no # delays neighbor registration... Not a good idea for a very reactive network...

Pollrate 0.05

NicChgsPollInt 60.00 # Interface configuration should never change... Is it possible to disable this checking ?

TcRedundancy 2

MprCoverage 1 # Defaults to 1 , and any other setting will severly reduce the optimization introduced by the MPR secheme says the documentation. But I often see values like 5, 7... So ?

LinkQualityLevel 2

LinkQualityFishEye 1

LinkQualityWinSize 100

ClearScreen no

# NO PLUGINS

Interface "IFXX" {

AutoDetectChanges: no # turn off to save CPU


HelloInterval 2.00

HelloValidityTime 6.00 # This value must be larger than than the HELLO generation interval to make any sense.

TcInterval 0.50 # TcInterval 1.0 seems to be a bit too high together with the fish-eye, because this means that all nodes farther than 3 hops away do only receive a TC packet every 39 (13*3) seconds (assuming the broadcasts are not lost in between). Better is probably TcInterval 0.5 as said in the README-Link-Quality-Fish-Eye.txt. And TcInterval should be shorter than the HelloInterval. This may overcome the "routing loop problem" encountered occasionally because topology info is spreaded more frequently.

TcValidityTime 1.50 # This value must be larger than than the TC generation interval to make any sense.

MidInterval 10.00

MidValidityTime 30.00 # This value must be larger than than the MID generation interval to make any sense. It appears that we should "consider to use MidValidityTime >= TcValidityTime (Since MID(multiple-identity)-info is used to parse traffic-control messages, it´s nescessary to track MID at least as long as TC-info. MID tells about nodes with multiple interfaces, a ka multiple IP´s meaning the same hop. since that info usually does´t change "that often" ;-) , it´s quiet safer to extend MidValidityTime , like e.g. MidValidityTime = TcValidityTime +30. That way you avoid some quiet nasty effects, (learned it the hard way, too, in Berlin´s Freifunk-mesh)." AND "There is no reason to use smaller values for MidValidityTime than for TcValidityTime."

HnaInterval 5.00

HnaValidityTime 15.00 # This value must be larger than than the HNA generation interval to make any sense.

}

What do you think about it ? Could you give me some advices for this configuration or share your own experience ?

Thx a lot


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20080718/4999ca6c/attachment.html>