On Tue, 2010-02-02 at 16:45 -0800, Luis R. Rodriguez wrote: > 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: > >> 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
<<attachment: acktimeout.png>>
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
