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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
