On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau <n...@openwrt.org> wrote: > On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote: >> On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau <n...@openwrt.org> 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.
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. Luis _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
