Re: [ath5k-devel] [PATCH 00/10] ANI for ath5k

[Bruno Randolf <br1@einfach.org>]

On Friday 26 March 2010 06:13:11 Luis R. Rodriguez wrote:
> > > - Improve beacon averaging algorithm for IBSS: Maybe we should keep
> > > track of
> > > 
> > >  the average RSSI on a per-node basis and use the minimum of those in
> > >  order not to loose far away nodes? The other option would be to limit
> > >  the parameters we control similar to AP mode.
> > 
> > We have talked about this before. I thought that we agreed
> > that adhoc nodes may
> > 
> >    a)be activated at any time
> >    b)be positioned at an unknown distance apart
> > 
> > it therefore makes no sense to average the RSSI over the current nodes.
> > If all the current nodes in the network are close by, the ani algorithm
> > will wind the sensitivity down. Consequently, if a remote node is
> > started, it will not be able to connect. Yet, the remote node should
> > have been able to connect as the slot times etc were long enough,
> > and the link budget is fine...

i'm not sure how big the effect of ANI is - would it really shut the remote 
node out completely? or would just performance degrade? also beacons are sent 
at the lowest rate, so they will travel far. this needs to be tested! it 
doesnt make sense to discuss this based on hypothetical assumptions.

> > So yes, the only way to
> > 
> > > - Improve beacon averaging algorithm for IBSS:
> > is to turn ani off. which means the issue you raised else where of
> > providing reasonable userland controls (not via debugfs) becomes
> > important.
> 
> If ANI helps IBSS so much then why not just default to turning it
> off within the driver?

i would say in most standard cases, IBSS nodes are close together or at a 
similar distance, so it does make sense to use ANI by default.

as well, we all agree that there should be userland controls. the questions is 
just about the interface to use.

bruno