[OpenWrt-Devel] ath9k: fix dynack in IBSS mode
lorenzo.bianconi at redhat.com
Sun Aug 18 11:39:08 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
> 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
> I've got my 24km link back if required to do some additional testing.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel