[OpenWrt-Devel] ath9k: fix dynack in IBSS mode

[Lorenzo Bianconi]

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