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

[Joe Ayers]

On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
<lorenzo.bianconi at redhat.com> wrote:
>
> >
> > bump.
>
> Hi Joe,
>
> sorry for the delay
>
> >
> > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers <joe at ayerscasa.com> wrote:
> >>
> >> Lorenzo,  I have tested dynack on a (real distance apart) ~60km link
> >> with some success.   This is the code change made:
> >>
> >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> >> @@ -20,8 +20,9 @@
> >>
> >>  #define COMPUTE_TO (5 * HZ)
> >>  #define LATEACK_DELAY (10 * HZ)
> >> -#define LATEACK_TO 256
> >> -#define MAX_DELAY 300
> >> +#define LATEACK_TO 1054
> >> +/* AREDN max distance set to 150km */
> >> +#define MAX_DELAY 1054
> >>  #define EWMA_LEVEL 96
> >>  #define EWMA_DIV 128
> >>
> >> @@ -293,7 +294,8 @@
> >>  void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
> >>  {
> >>   /* ackto = slottime + sifs + air delay */
> >> - u32 ackto = 9 + 16 + 64;
> >> + /* AREDN starting point is 20km */
> >> + u32 ackto = 9 + 16 + 171;
> >>   struct ath_dynack *da = &ah->dynack;
> >>
> >>   an->ackto = ackto;
> >> @@ -328,7 +330,8 @@
> >>  void ath_dynack_reset(struct ath_hw *ah)
> >>  {
> >>   /* ackto = slottime + sifs + air delay */
> >> - u32 ackto = 9 + 16 + 64;
> >> + /* AREDN starting point is 20km */
> >> + u32 ackto = 9 + 16 + 171;
> >>   struct ath_dynack *da = &ah->dynack;
> >>
> >>   da->lto = jiffies;
> >>
> >> Notes:
> >>
> >> 1) The stations are showing ack_to between 525 up to 575 A.  When
> >> static set at 60k distance, the timeout is set to 460 S.
> >> 2) significant performance improvement between these settings with
> >> iperf3 and back to back runs with reboot in the middle:
> >>
>
> could you please try to attached patch? The max distance the hw can
> support depends of channel width:
> e.g @20MHz (HT20, 5GHz)
>
> max distance is ~ 61Km
>

Could these max distance specs be what the manufacture tested, not
necessarily a hardware limitation -- just not known?

I suspect in the calculation for max_to, if the channel is 10MHz, the
max distance can be doubled for the hardware--do the specs only give
20MHz values?   This would be consistent with, for example, the symbol
lengths are doubled when cutting the bandwidth in half, hence half the
rates and still 64 bins or 64 point fft squeezed in the channel.  SNR
is also 3dB higher given same energy in half the bandwidth.  We don't
see 20MHz channels working at these long distances, rather use 10MHz
for it to work.  Intuitively, as I understand it, more time is needed
with increased distance for reflection signals to not be received past
the symbol time and increased inter-symbol interference.

> @Koen: do you have any chance to test the attached patch in your
> environment? Thx
>
> >> run 1 @ static 60km:
> >> [  5]   0.00-10.00  sec  7.31 MBytes  6.13 Mbits/sec    0             sender
> >> [  5]   0.00-10.08  sec  7.16 MBytes  5.95 Mbits/sec                  receiver
> >>
> >> run 2 @ static 60km:
> >> [  5]   0.00-10.00  sec  5.88 MBytes  4.93 Mbits/sec    0             sender
> >> [  5]   0.00-10.04  sec  5.77 MBytes  4.81 Mbits/sec                  receiver
> >>
> >> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
> >> floats back to ~525 otherwise:
> >> [  5]   0.00-10.00  sec  20.0 MBytes  16.8 Mbits/sec    0             sender
> >> [  5]   0.00-10.07  sec  19.8 MBytes  16.5 Mbits/sec                  receiver
> >>
> >> [  5]   0.00-10.00  sec  21.4 MBytes  18.0 Mbits/sec    0             sender
> >> [  5]   0.00-10.04  sec  21.2 MBytes  17.7 Mbits/sec                  receiver
> >>
> >> 3) running wpa_supplicant and psk2
> >> 4) running ibss on ch 176 with AREDN channels on top of 18.06.2
> >> 5) on one reboot, one of the stations stayed down at initial 196, then
> >> bumped up to ~250 range and stayed there, link not functional.  Not
> >> sure how to explain this value...
> >>
> >> Question,  can this condition be true periodically while the link is
> >> live or only at initial 802.11 adhoc link setup?:
> >>
> >>                 if (ieee80211_is_assoc_req(hdr->frame_control) ||
> >>                     ieee80211_is_assoc_resp(hdr->frame_control) ||
> >>                     ieee80211_is_auth(hdr->frame_control)) {
> >>
>
> I do not think so since AFAIK auth frames are sent just during ibss join
>
> >> 6)  Auto distance stayed at initial 196 when turning off encryption.
> >>
> >> Any ideas of alternative options of packets to key off in late ack
> >> situation?   running wpad-mini is ~500k file size and RAM consumer.
> >> It would be beneficial to take wpa_supplicant out of the equation if
> >> at all possible.
> >>
>
> What is mandatory are unicast frames during joining phase, maybe you can
> develop an userspace daemon for this purpose
>

I see where you're going with this.   I'd have to learn a lot to do
this.  Possibly a simpler approach, if it doesn't add too much
penalty.  What if the initial ack_to is at max, it quickly settles
down to measured, then after some criteria, time or # acks received,
say ~15 seconds has elapsed  a cycle is triggered back to max ack_to.
 This should catch new stations joining at farther distances when wpad
is not used.

> >> Joe
>
> Regards,
> Lorenzo

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel