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

Lorenzo Bianconi lorenzo.bianconi at redhat.com
Sun Mar 31 15:15:14 EDT 2019


>
> 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?
>

https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L1006

max timeout you can set is AR_TIME_OUT_ACK (0x3fff) / clock_rate

> 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.

yes, but it is already done in ath9k_hw_set_clockrate()
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L61

>
> > @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.
>

I am a little bit concerned about short/medium distance links with high LER.
Is the attached patch working?

Regards,
Lorenzo

> > >> Joe
> >
> > Regards,
> > Lorenzo

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



More information about the openwrt-devel mailing list