Re: [B.A.T.M.A.N.] parametrization for bmxd on ethernet?

[Jan Hetges <tran@ms20.net>]

[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]

On Thu, Nov 15, 2007 at 08:29:49PM +0100, Axel Neumann wrote:
> 
> > > > So howto parametrize bmxd for devices without wireless-intrerface
> > >
> > > usually the same parameters as for a node with a wireless interface
> > > should be fine, like:
> > > bmxd -g 1000 eth0:bmx eth1:bmx
> > >
> > > You can slightly optimize the cpu consumtion and
> > > protocol-traffic-overhead by appending the /c 100 option to the first
> > > interface parameter like:
> > >
> > > batmand -g 1000 eth0:bat /c 100 eth1:bat
> > >
> > > This overwrites the default configuration (/c 200) of the first interface
> > > parameter which is assumed to be the only wlan interface. /c 200 achieves
> > > some optimization for the path detection via wireless links.
> > >
> > > However, on a cabled lan the protocol-traffic-overhead does not really
> > > hurt and on a i386 architecture you will barely recognize any increased
> > > cpu consumption.
> update: I added two more simple interface specific option with rv801 . The 
> daemon now tells you about this during startup:
> The batman-exp default parametrization assumes the first given interface 
> argument to be the one and only wireless interface, followed by zero or more 
> lan interfaces! To change this assumption mark the interfaces explicitly 
> using /w to specify the wlan interface(s) and /l to specify the lan 
> interface(s). Example: batmand eth0 /l wlan0 /w ath1 /w

nice one
> > >
> > > > Can i use --gateway-change-hysteresis together with -p ?
> > >
> > > No, --gateway-change-hysteresis can only be used with -r 3 (fast-switch
> > > internet connection).
> > >
> > > with -p 10.1.2.3 the gw-client will stick to its selected gw as long as
> > > its somehow available (until it times out, as you described below).
> >
> > sorry, actually my question has to be:
> > can i use -p together with -r3 ?
> 
> You can. Then -r3 is the fallback strategy for the GW selection in case the 
> preferred one is not available. But still the client-node will not think 
> about choosing a faster GW until the preferred GW has been purged. Once the 
> preferred GW is not available anymore it uses the -r3 policy to switch 
> between the remaining available GWs :-(

but with only two gateways, that's actually all i need :-)
> 
> >
> > > > Suggestion: in bmxd -cbd1 i saw nodes with lvld >400 before they
> > > > get deleted, i think 180 should be more than enough, 3 minutes is
> > > > plenty of time for normal reboot, and if a node dosn't send OGMs for
> > > > more than that... it has a serious problem ;)
> > >
> > > Well, these long timeout defaults are kind of traditional remains from
> > > batmand-0.2. But, not constantly receiving OGMs from a distant node does
> > > not mean that the distant node has not send some or is down. And it also
> > > does not necessarily mean that the old route to this distant node does
> > > not work anymore. With 0.2 we sometimes observed paths to distant nodes
> > > via which only one OGMs was received within the current window-size
> > > (which was 128 seconds) and still the path was somehow usable.
> >
> another update:
> You can slightly modify the purge interval by configuring the value used for 
> the rudimentary DuplicateAddressDetection (--dad-timeout). Default is 100 
> which means that the DAD timeout is 100% of the (originator-interval * 
> window-size). So 150 seconds by default. The daeomon also tells you about 
> these values during startup: --dad-timeout 50 (which is the minimum allowed) 
> will print:
> Using duplicate-address-detection timeout 75s, purge timeout 160s, originator 
> interval 1500ms, window size 100

o.k., i see, and thanks for the explaination


cheers

  --Jan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]