[OpenWrt-Devel] ath9k: fix dynack in IBSS mode
Koen Vandeputte
koen.vandeputte at ncentric.com
Fri Aug 16 05:48:49 EDT 2019
>> Hi Joe,
>>
>>> Lorenzo, I deployed an ath9k auto distance solution in April that is
>>> working for the AREDN community http://www.arednmesh.org .
>>>
>>> https://github.com/aredn/aredn_ar71xx/blob/develop/patches/712-auto-distance-settings.patch
>>>
>>> Summary of solution:
>>>
>>> * no dependency on wpa_supplicant
>>> * initial ack_to is set to max, to not enter late ack conditions
>>> * User level trigger to flip distance setting to static and back to
>>> auto when new 802.11 adhoc neighbor joins. (we archive and chart SNR
>>> values for neighbors and natural to hook in this trigger).
>> Have you initialized the ackto to the max value to remove wpa_supplicant
>> dependency or because the system is not able to trigger the 'late ack'?
>> I did not get why you need to flip the algo off/on when new 802.11 adhoc
>> neighbor joins
>>
>> Regards,
>> Lorenzo
>>
> initialized the ackto to max:
>
> A) avoidance of late-ack state
> B) not require wpa_supplicant -- not in use by our community today
> C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
> "late ack" (consistent, with observation of low SNR Neighbors sticking
> at max ack_to with my changes )
>
> flip the algo off/on when new neighbor joins:
>
> Intended technique to reset ack_to to max. If ack_to is set to 20km
> and then a new adhoc neighbor joins at 30km, this would be a late ack
> state, and unable to detect. My early testing results showed the
> algo off/on would restart the ack_to to max and start the process over
> with the new neighbor. I trust I got it right?
>
> There are 10s to 100s of users testing this bleeding edge change from
> nightly builds, and so far, I've not found a failure case.
> Although, the findings are showing the cases where static setting has
> better throughput.
>
> Joe AE6XE
>
>>>
<snip>
Lorenzo,
It's been a while regarding the above.
I can confirm the issue that if the algorithm misses the late ack's due
to low initial snr, the initial ack_to is too low to recover afterwards.
Do you think it would be useful to start at high ack_to and let it
estimate/drop afterwards?
Ps.
I've got my 24km link back if required to do some additional testing.
Thanks,
Koen
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list