>
> On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> <lorenzo.bianc...@redhat.com> wrote:
> >
> > >
> > > bump.
> >
> > Hi Joe,
> >
> > sorry for the delay
> >
> > >
> > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers <j...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
