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

[Pavel Roskin <proski@gnu.org>]

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.

If the limit is needed to guard against hardware limitations, then we
want maximum.  It means that the timeout is implemented accurately in
the hardware, it just cannot be too low.

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.

-- 
Regards,
Pavel Roskin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acktimeout.png
Type: image/png
Size: 12484 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20100202/7b829921/attachment-0001.png