From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Date: Wed, 03 Feb 2010 01:18:45 +0100 Subject: [ath9k-devel] ath9k in wireless-testing won't work in AP mode In-Reply-To: <20100203000843.GE17797@tux> 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> Message-ID: <4B68C0E5.20603@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: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) - Felix