[Olsr-users] Optimizing config file - mobility

[Hannes Gredler]

config so far looks good - 

i'd set the tc-interval to 2s (1s or 0.5) seems overly aggressive.

if the number of olsr nodes is small (<50) there is no need
to turn on fisheye.

On Fri, Jul 18, 2008 at 08:17:14PM +0200, Puissance MaXximum Online wrote:
|    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

| -- 
| Olsr-users mailing list
| (spam-protected)
| http://lists.olsr.org/mailman/listinfo/olsr-users