
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.6001.18063" name=GENERATOR>

<STYLE></STYLE>

</HEAD>

<BODY bgColor=#ffffff>

<DIV><FONT face=Arial size=2>Hello,</FONT></DIV>

<DIV><FONT face=Arial size=2></FONT> </DIV>

<DIV><FONT face=Arial size=2>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.</FONT></DIV>

<DIV><FONT face=Arial size=2></FONT> </DIV>

<DIV><FONT face=Arial size=2>I would like to optimize the configuration for a 

small mobile network (i.e. 10 nodes) with the following 

<DIV id=result_box dir=ltr>characteristics:</DIV>

<DIV dir=ltr>- very mobile nodes and no static node, no ap</DIV>

<DIV dir=ltr>-olsrd running on small devices (pda and htc with headset, 

etc.)</DIV>

<DIV dir=ltr>-no internet gateway</DIV>

<DIV dir=ltr>-no need to interact with non-olsr neighbours</DIV>

<DIV dir=ltr>-the network have to support voip traffic but users will speak very 

few</DIV>

<DIV dir=ltr>-the network must be very reactive and support small voip traffic 

(or small P2P communications)</DIV>

<DIV dir=ltr> </DIV>

<DIV dir=ltr>In fact, to imagine, just think about small teams of firemen, about 

people in charge of security during outdoors events, etc.</DIV>

<DIV dir=ltr> </DIV>

<DIV dir=ltr>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:</DIV><SPAN lang=FR>

<DIV dir=ltr>

<P>DebugLevel 0 #The daemon runs in the background - Users don't need it...</P>

<P>IpVersion 4</P>

<P>FIBMetric "flat"</P>

<P>AllowNoInt no # We are not in a PCMCIA/USB hotswap environment and the 

interfaces should be always avaible...</P>

<P>Willingness 4 # Dynammically based on battery/power status seems to be a good 

idea for small devices. What about 7 ???</P>

<P>IpcConnect {</P>

<P>MaxConnections 0 # No GUI front-end in the wince, and no need to 

connect to the daemon</P>

<P>}</P>

<P>UseHysteresis no # delays neighbor registration... Not a good idea for a very 

reactive network...</P>

<P>Pollrate 0.05</P>

<P>NicChgsPollInt 60.00 # Interface configuration should never change... Is it 

possible to disable this checking ?</P>

<P>TcRedundancy 2</P>

<P>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 ?</P>

<P>LinkQualityLevel 2</P>

<P>LinkQualityFishEye 1</P>

<P>LinkQualityWinSize 100</P>

<P>ClearScreen no</P>

<P># NO PLUGINS</P>

<P>Interface "IFXX" {</P>

<P>AutoDetectChanges: no # turn off to save CPU</P>

<P></P>

<P>HelloInterval 2.00</P>

<P>HelloValidityTime 6.00 # This value must be larger than than the HELLO 

generation interval to make any sense.</P>

<P>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.</P>

<P>TcValidityTime 1.50 # This value must be larger than than the TC generation 

interval to make any sense.</P>

<P>MidInterval 10.00</P>

<P>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."</P>

<P>HnaInterval 5.00</P>

<P>HnaValidityTime 15.00 # This value must be larger than than the HNA 

generation interval to make any sense.</P>

<P>}</P>

<P>What do you think about it ? Could you give me some advices for this 

configuration or share your own experience ?</P>

<P>Thx a lot</P>

<P> </P></SPAN></DIV></FONT></DIV></BODY></HTML>