From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Tue, 2 Feb 2010 16:27:20 -0800 Subject: [ath9k-devel] ath9k in wireless-testing won't work in AP mode In-Reply-To: <4B68C0E5.20603@openwrt.org> 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> Message-ID: <43e72e891002021627rd07a567v8d739908ee252f56@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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. Luis