> > > >> 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, >
Hi Koen, > 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. > are you referring to tx side or rx side? are you able to reproduce the issue with debug enable? I guess the system will resend the assoc request/response packets so eventually we should be able tack the 'late ack' > Do you think it would be useful to start at high ack_to and let it > estimate/drop afterwards? > I think we can add more logic to take care of this issue but first I would have a clearer idea of the problem > Ps. > > I've got my 24km link back if required to do some additional testing. > cool :) Regards, Lorenzo > > Thanks, > > Koen > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
