[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[Luis R. Rodriguez <lrodriguez@atheros.com>]

On Tue, Feb 02, 2010 at 07:29:42PM -0800, Pavel Roskin wrote:
> On Tue, 2010-02-02 at 16:45 -0800, Luis R. Rodriguez wrote:
> > On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> > > On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
> > >> Well so what I meant is that we should ensure hardware is not
> > >> programmed with an ACK/CTS Timeout value lower than what is on the
> > >> initvals already. If changing the coverage class means a different ACK
> > >> timeout is produced we just take the max of the two values.
> > > Taking the max doesn't make any sense to me if this is about working
> > > around delay in the transmission of BlockAcks. Since the coverage class
> > > is meant to compensate delay in the air propagation time, the ACK
> > > timeout should increase along with it, because along with increasing
> > > distance, the worst case delay of the BA of a distant node will get
> > > higher as well.
> >
> > Well so increased delays would mean you would do premature retries if
> > the ACK timeout is not high enough. If you increase the ACK timeout it
> > means hardware would wait longer for the frame and the default value
> > we have used so far has been programmed on the initvals. So if the ACK
> > timeout is going to be modified to support coverage class support, I
> > take it we are only possibly increasing the ACK timeout and never
> > decreasing it.
> >
> > Please let me know if I am missing something here.
> 
> As I understand, nobody proposes to decrease the ACK timeout.  The only
> question is how it should be increased.  Should we use maximum or
> addition?  And that depends on the reasons for having the lower limit
> for ACK timeout.

The reason for having the increase to 64 was documented as a solution
to an interoperability issue against another device which sent out a delayed
BA when CTS-to-self was enabled. The reports about AR9160, AR9220 and AR9271
on this thread might not be the same though and could technically involve
a bus delay issue. Either way the default value of 64 should be used by
default since it is what has been kept and tested widely.

> If the limit is needed to guard against hardware limitations, then we
> want maximum.

Its not a hardware limitation.

> It means that the timeout is implemented accurately in
> the hardware, it just cannot be too low.

Right, that is not the case.

> If the limit is needed to compensate for whatever processing delays,
> then we want addition.  Those delays won't overlap with air propagation.
> The delay time would be added to the air propagation time.  It would
> mean adding a constant fudge factor to the ACK timeout to make it
> accurate.
> 
> I've attached a simple picture to make it more clear.

You're right, whether the processing delays are bus specific or interop
specific addition is required. So to clarify we should then add the delta
between what the spec says and what is programmed into the initvals
then.

  Luis