From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Date: Wed, 03 Feb 2010 01:35:40 +0100 Subject: [ath9k-devel] ath9k in wireless-testing won't work in AP mode In-Reply-To: <43e72e891002021627rd07a567v8d739908ee252f56@mail.gmail.com> References: <1264806315.23248.22.camel@mj> <4B63709F.2010805@openwrt.org> <1264880367.26739.25.camel@mj> <4B64922C.1090809@openwrt.org> <1264883839.26739.47.camel@mj> <4B649ABB.1040203@openwrt.org> <20100203000843.GE17797@tux> <4B68C0E5.20603@openwrt.org> <43e72e891002021627rd07a567v8d739908ee252f56@mail.gmail.com> Message-ID: <4B68C4DC.5090607@openwrt.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote: > On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau wrote: >> On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote: >>> We have reviewed this. The 64 value came from interoperability >>> tests against another 802.11n device which had increased delayed BlockAcks >>> when CTS-to-self was enabled. Although this is a higher value than >>> what the standard says to use we recommend to just leave the value as-is >>> and actually use the values from the initvals as the minimum possible >>> value as those are the values that have been used for a large array >>> of tests, including WMM interop tests. We cannot gaurantee proper >>> functionality against other devices otherwise. >>> >>> Since the issues so far are obaserved on AR9160 and AR9220 >>> (and not AR9280) and AR9271 (sujith) this might be a bus issue >>> and the only way to zero in on the issue would be by getting full >>> register dumps to ensure every other register related to ACK Timeout >>> is programmed properly (AR_USEC_USEC I think is one) and >>> taking it from there. Testing different values are welcomed but >>> upstream we should just use what we have tested with until >>> we do WMM interop tests with different values and not sure if >>> we'll be doing that for a while. >> So how should we handle ACK timeout for different coverage class values? >> That's my primary concern, since I wrote the patch to support that. >> Should I just send a patch that adds an offset of 45? (= 64us - 19us, >> based on the diff between calculated and initval) > > 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. - Felix