Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 28.08.19 19:34, Joe Ayers wrote: 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 Hi Joe, Purely fyi I just pushed dynack improvements to all openwrt branches. I also noticed the issues you addressed above, and these patches fix them for me. Regards, Koen Thanks for update. Updates on performance observations, I've been recommending usage of auto settings to the AREDN community as follows: * best performance gain on Point-to-Point longer distance links (back bone links). I saw ~30% iperf improvement results on a 60km 5GHz link -- ack-to floats up under load. This was about the difference I measured on a similar 3GHz 60km link head-to-head comparison between AirOS auto distance with TDMA and openwrt static distance with CSMA. (3GHz because it takes wifi noise out of the picture.) I want to do a head-to-head comparison again to confirm, but it appears a P2P w/ auto setting CSMA in openwrt will compare similar thoughput as AirOS auto distance TDMA. * good/poor performance for Point-to-Multipoint long distance settings, up to 20km range (cell coverage). If weak SNR stations, a static setting is optimal. If quality signal, auto works good. Will try to verify this one * Poor performance for short distances, e.g. in the house. auto calculated ack_to settings are several km. Performance is much poorer than a static setting of <1km. Ack on this one. Tested on links ranging from ~500m up to 3.5km static seems to win in terms of performance until the distance goes beyond ~6km here There seems to be something going on with calculation when 'on the bench' testing with short distances. Maybe a bias needs to be applied? I notice that ack_to never drops below 64 on short distance links. (static sets it to 31 on selecting 500m) I wonder if processing delay/time and thread context switching is coming into play here on the slower ar71xx socs Will check it. The main focus of this series was to have working links and avoid breaking existing ones. I think the next round will be regarding these performance "issues" compared to static Koen Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > 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 > > > >>> > Hi Joe, > > Purely fyi > > I just pushed dynack improvements to all openwrt branches. > > I also noticed the issues you addressed above, and these patches fix > them for me. > > Regards, > > Koen > Thanks for update. Updates on performance observations, I've been recommending usage of auto settings to the AREDN community as follows: * best performance gain on Point-to-Point longer distance links (back bone links). I saw ~30% iperf improvement results on a 60km 5GHz link -- ack-to floats up under load. This was about the difference I measured on a similar 3GHz 60km link head-to-head comparison between AirOS auto distance with TDMA and openwrt static distance with CSMA. (3GHz because it takes wifi noise out of the picture.) I want to do a head-to-head comparison again to confirm, but it appears a P2P w/ auto setting CSMA in openwrt will compare similar thoughput as AirOS auto distance TDMA. * good/poor performance for Point-to-Multipoint long distance settings, up to 20km range (cell coverage). If weak SNR stations, a static setting is optimal. If quality signal, auto works good. * Poor performance for short distances, e.g. in the house. auto calculated ack_to settings are several km. Performance is much poorer than a static setting of <1km. There seems to be something going on with calculation when 'on the bench' testing with short distances. Maybe a bias needs to be applied? Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
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 Hi Joe, Purely fyi I just pushed dynack improvements to all openwrt branches. I also noticed the issues you addressed above, and these patches fix them for me. Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > > >> 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 > > > >>> > > > > 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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
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 Lorenzo, 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. Do you think it would be useful to start at high ack_to and let it estimate/drop afterwards? Ps. I've got my 24km link back if required to do some additional testing. Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Tue, Jun 4, 2019 at 3:18 AM Lorenzo Bianconi
wrote:
>
> > On Thu, Apr 4, 2019 at 12:20 AM Lorenzo Bianconi
> > wrote:
> > >
> > > > On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > bump.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Joe,
> > > > > > > > > > > > >
> > > > > > > > > > > > > sorry for the delay
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > > > > > 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 = >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 = >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
> > >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Thu, Apr 4, 2019 at 12:20 AM Lorenzo Bianconi
> wrote:
> >
> > > On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > bump.
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Joe,
> > > > > > > > > > > >
> > > > > > > > > > > > sorry for the delay
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > > > > 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 = >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 = >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
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Thu, Apr 4, 2019 at 12:20 AM Lorenzo Bianconi
wrote:
>
> > On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > bump.
> > > > > > > > > > >
> > > > > > > > > > > Hi Joe,
> > > > > > > > > > >
> > > > > > > > > > > sorry for the delay
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > > > 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 = >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 = >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,
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > bump.
> > > > > > > > > >
> > > > > > > > > > Hi Joe,
> > > > > > > > > >
> > > > > > > > > > sorry for the delay
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > > 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 = >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 = >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
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
wrote:
>
> >
> > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > bump.
> > > > > > > > >
> > > > > > > > > Hi Joe,
> > > > > > > > >
> > > > > > > > > sorry for the delay
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > 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 = >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 = >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
> > > > > > >
> > > > > > > >
> > > > > > > >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > bump.
> > > > > > > >
> > > > > > > > Hi Joe,
> > > > > > > >
> > > > > > > > sorry for the delay
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > 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 = >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 = >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/sec0
> > > > > > > > >> sender
> > > > > > > > >> [ 5] 0.00-10.08
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
wrote:
>
> >
> > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > bump.
> > > > > > >
> > > > > > > Hi Joe,
> > > > > > >
> > > > > > > sorry for the delay
> > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > 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 = >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 = >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/sec0
> > > > > > > >>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/sec0
> > > > > > > >>sender
> > > > > > > >> [ 5]
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > bump.
> > > > > >
> > > > > > Hi Joe,
> > > > > >
> > > > > > sorry for the delay
> > > > > >
> > > > > > >
> > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > 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 = >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 = >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/sec0
> > > > > > >> 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/sec0
> > > > > > >> 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/sec0
> > > > > > >> sender
> > > > > > >> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
wrote:
>
> >
> > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > > bump.
> > > > >
> > > > > Hi Joe,
> > > > >
> > > > > sorry for the delay
> > > > >
> > > > > >
> > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > 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 = >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 = >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/sec0
> > > > > >>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/sec0
> > > > > >>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/sec0
> > > > > >>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/sec0
> > > > > >>sender
> > > > > >> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec
> > > > > >>receiver
> > > > > >>
> > > > >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 31.03.19 15:45, Lorenzo Bianconi wrote: 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 @Koen: do you have any chance to test the attached patch in your environment? Thx Hi Lorenzo, I don't have the 24km link anymore, as that offshore high-voltage station received it's fiber uplink some time ago. This rendered the wifi link obsolete and it got dismounted. I'll see if I can get something similar using other installed equipment offshore. Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > bump.
> > > >
> > > > Hi Joe,
> > > >
> > > > sorry for the delay
> > > >
> > > > >
> > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers 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 = >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 = >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/sec0
> > > > >> 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/sec0
> > > > >> 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/sec0
> > > > >> 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/sec0
> > > > >> 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...
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
wrote:
>
> >
> > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > bump.
> > >
> > > Hi Joe,
> > >
> > > sorry for the delay
> > >
> > > >
> > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers 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 = >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 = >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/sec0
> > > >> 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/sec0
> > > >> 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/sec0
> > > >> 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/sec0
> > > >> 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) ||
> > > >>
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> wrote:
> >
> > >
> > > bump.
> >
> > Hi Joe,
> >
> > sorry for the delay
> >
> > >
> > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers 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 = >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 = >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/sec0
> > >> 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/sec0
> > >> 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/sec0
> > >> 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/sec0
> > >> 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
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
wrote:
>
> >
> > bump.
>
> Hi Joe,
>
> sorry for the delay
>
> >
> > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers 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 = >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 = >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/sec0
> >> 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/sec0
> >> 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/sec0
> >> 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/sec0
> >> 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
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> bump.
Hi Joe,
sorry for the delay
>
> On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers 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 = >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 = >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
@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/sec0 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/sec0 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/sec0 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/sec0 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
>> Joe
Regards,
Lorenzo
From 72f4ba6f6b6021fcc48d07d03407c2fdb16a46c5 Mon Sep 17 00:00:00 2001
Message-Id: <72f4ba6f6b6021fcc48d07d03407c2fdb16a46c5.1554035972.git.lore...@kernel.org>
In-Reply-To:
References:
From: Lorenzo Bianconi
Date: Sun, 31 Mar 2019 14:38:49 +0200
Subject: [PATCH] ath: dynack: set max timeout according to clockrate
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/ath/ath9k/dynack.c | 36 ++---
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
index f112fa5b2eac..0627111249dd 100644
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -20,11 +20,24 @@
#define COMPUTE_TO (5 * HZ)
#define LATEACK_DELAY (10 * HZ)
-#define LATEACK_TO 256
-#define MAX_DELAY 300
#define EWMA_LEVEL 96
#define EWMA_DIV 128
+/**
+ * ath_dynack_get_max_to - set max timeout according to clockrate
+ * @ah: ath hw
+ *
+ */
+static u32 ath_dynack_get_max_to(struct ath_hw *ah)
+{
+ struct ath_common *common = ath9k_hw_common(ah);
+
+ if (common->clockrate)
+ return AR_TIME_OUT_ACK / common->clockrate;
+
+ return 300;
+}
+
/**
* ath_dynack_ewma - EWMA (Exponentially Weighted Moving Average) calculation
*
@@
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
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 = >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 = >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:
run 1 @ static 60km:
[ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0 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/sec0 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/sec0 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/sec0 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)) {
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.
Joe
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Tue, Mar 5, 2019 at 8:31 AM Lorenzo Bianconi wrote: > > > On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi > > wrote: > > > > > > > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > > > > > wrote: > > > > > > > > > > > > > > > Lorenzo,I've pulled out all patches related to extended ham > > > > > > > > radio > > > > > > > > channels and ath9k is same out of openwrt 18.06.2.I > > > > > > > > replaced wpad-mini > > > > > > > > with the full version and "option encryption psk2". In > > > > > > > > testing between a > > > > > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), > > > > > > > > ack_to will > > > > > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > > > > > However, > > > > > > > > I do not see any late ack messages in the debug logging. > > > > > > > > Shouldn't I be > > > > > > > > seeing late acks? I can send full debug data on both sides of > > > > > > > > the fence. > > > > > > > > Is there anything that doesn't sound right in my setup? I > > > > > > > > wanted to do > > > > > > > > one more clean test to capture logs. > > > > > > > > > > > > > > Hi Joe, > > > > > > > > > > > > > > this is the expected behavior since 'late acks' are triggered > > > > > > > just when the real > > > > > > > ack-timeout is higher than the initial default value (64us IIRC). > > > > > > > In other > > > > > > > words 'late acks' are necessary just on pretty long links > > > > > > > > > > > > > > Regards, > > > > > > > Lorenzo > > > > > > > > > > > > > > > > > Hi Joe, > > > > > > > > > > please keep the ml in cc > > > > > > > > > > > > > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > > > > > Is there yet another data point for the algorithm to oscillate in > > > > > > to > > > > > > an optimal ack_to setting? For a mobile use case, with increasing > > > > > > distance apart, there'd need to be a 'late ack' equivalent to > > > > > > trigger > > > > > > increasing values? I'm fundamentally trying to understand if any > > > > > > there are any limitations to be aware of when applying dynack - > > > > > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > > > > > > > > > 'late ack' means that we received an ack for a packet where > > > > > ack-timeout is already > > > > > expired since the configured timeout was too low for the real > > > > > distance. > > > > > If the real ack-timeout is less than the configured initial value > > > > > (64us --> ~ 10Km), > > > > > it is expected to not detected any 'late acks'. In this scenario the > > > > > ack timeout > > > > > should just converge to a good value. > > > > > If the real distance is grater than 10km we have to dump the > > > > > ack-timeout in order > > > > > to grab the station and estimate the real timeout (we need to dump the > > > > > ack-timeout since the estimation is done through data-ack > > > > > transmissions). > > > > > Are we on the same page? > > > > > > > > > > Regards, > > > > > Lorenzo > > > > > > > > > > > > > Thanks for taking the time to get to this detail. > > > > > > > > Still a little fuzzy on what packets are in scope. When not late ack > > > > state: xmit a 'packet' and expect an ack in return -- all data > > > > 'packets' regardless if using wpa_supplicant or not? estimate and > > > > update ack_to > > > > > > > > "in order to grab the station and estimate the real timeout" > > > > Context is in a late ack state, all the acks are late "done through > > > > data-ack transmissions". Thus what does it mean to "grab the station > > > > and estimate" -- is this the dependency to wpa_supplicant and turning > > > > to measuring the handshaking packets generated by wpa_supplicant? > > > > And if I understand correctly, this state can only occur if the intial > > > > ack_to is shorter than physical distance. If initial ack_to is > > > > greater than physical, then we never get into this state. > > > > > > the main idea behind dynack is to measure the delta time between packet > > > transmission and the corresponding ack reception (~ 2 * acktimeout). > > > To do so we need to correlate the ack with the relative data packet. > > > This is easy if the already configured acktimeout is higher than the > > > station distance since the related ack will arrive before the timeout > > > expiration time. > > > If the station distance is higher than the current acktimeout we need to > > > know > > > that a new station is connecting to the network since we need to dump the > > > acktimeout in order to start estimating its distance. This is done through > > > association/authentication packets and AFAIK they are not sent in IBSS > > > mode if > > > we do not run wpa_supplicant. > > > > > > Regards, > > > Lorenzo > > > > > > > What would be the negative of starting out with an initial ack_to > > guess of, e.g. 100km and always let it
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi > wrote: > > > > > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > > > > wrote: > > > > > > > > > > > > > Lorenzo,I've pulled out all patches related to extended ham > > > > > > > radio > > > > > > > channels and ath9k is same out of openwrt 18.06.2.I replaced > > > > > > > wpad-mini > > > > > > > with the full version and "option encryption psk2". In testing > > > > > > > between a > > > > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to > > > > > > > will > > > > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > > > > However, > > > > > > > I do not see any late ack messages in the debug logging. > > > > > > > Shouldn't I be > > > > > > > seeing late acks? I can send full debug data on both sides of > > > > > > > the fence. > > > > > > > Is there anything that doesn't sound right in my setup? I > > > > > > > wanted to do > > > > > > > one more clean test to capture logs. > > > > > > > > > > > > Hi Joe, > > > > > > > > > > > > this is the expected behavior since 'late acks' are triggered just > > > > > > when the real > > > > > > ack-timeout is higher than the initial default value (64us IIRC). > > > > > > In other > > > > > > words 'late acks' are necessary just on pretty long links > > > > > > > > > > > > Regards, > > > > > > Lorenzo > > > > > > > > > > > > > > Hi Joe, > > > > > > > > please keep the ml in cc > > > > > > > > > > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > > > > Is there yet another data point for the algorithm to oscillate in to > > > > > an optimal ack_to setting? For a mobile use case, with increasing > > > > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > > > > increasing values? I'm fundamentally trying to understand if any > > > > > there are any limitations to be aware of when applying dynack - > > > > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > > > > > > > 'late ack' means that we received an ack for a packet where ack-timeout > > > > is already > > > > expired since the configured timeout was too low for the real distance. > > > > If the real ack-timeout is less than the configured initial value (64us > > > > --> ~ 10Km), > > > > it is expected to not detected any 'late acks'. In this scenario the > > > > ack timeout > > > > should just converge to a good value. > > > > If the real distance is grater than 10km we have to dump the > > > > ack-timeout in order > > > > to grab the station and estimate the real timeout (we need to dump the > > > > ack-timeout since the estimation is done through data-ack > > > > transmissions). > > > > Are we on the same page? > > > > > > > > Regards, > > > > Lorenzo > > > > > > > > > > Thanks for taking the time to get to this detail. > > > > > > Still a little fuzzy on what packets are in scope. When not late ack > > > state: xmit a 'packet' and expect an ack in return -- all data > > > 'packets' regardless if using wpa_supplicant or not? estimate and > > > update ack_to > > > > > > "in order to grab the station and estimate the real timeout" > > > Context is in a late ack state, all the acks are late "done through > > > data-ack transmissions". Thus what does it mean to "grab the station > > > and estimate" -- is this the dependency to wpa_supplicant and turning > > > to measuring the handshaking packets generated by wpa_supplicant? > > > And if I understand correctly, this state can only occur if the intial > > > ack_to is shorter than physical distance. If initial ack_to is > > > greater than physical, then we never get into this state. > > > > the main idea behind dynack is to measure the delta time between packet > > transmission and the corresponding ack reception (~ 2 * acktimeout). > > To do so we need to correlate the ack with the relative data packet. > > This is easy if the already configured acktimeout is higher than the > > station distance since the related ack will arrive before the timeout > > expiration time. > > If the station distance is higher than the current acktimeout we need to > > know > > that a new station is connecting to the network since we need to dump the > > acktimeout in order to start estimating its distance. This is done through > > association/authentication packets and AFAIK they are not sent in IBSS mode > > if > > we do not run wpa_supplicant. > > > > Regards, > > Lorenzo > > > > What would be the negative of starting out with an initial ack_to > guess of, e.g. 100km and always let it come down to real. I know ack > to values in these 70km ranges are working when statically set with > the devices used at this long distance. Otherwise, if the values > were limited and too short, the link performance would be unusable. > I thought I saw late ack debug messages with IBSS and no >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi wrote: > > > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi > > wrote: > > > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > Lorenzo,I've pulled out all patches related to extended ham > > > > > > radio > > > > > > channels and ath9k is same out of openwrt 18.06.2.I replaced > > > > > > wpad-mini > > > > > > with the full version and "option encryption psk2". In testing > > > > > > between a > > > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to > > > > > > will > > > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > > > However, > > > > > > I do not see any late ack messages in the debug logging. > > > > > > Shouldn't I be > > > > > > seeing late acks? I can send full debug data on both sides of the > > > > > > fence. > > > > > > Is there anything that doesn't sound right in my setup? I wanted > > > > > > to do > > > > > > one more clean test to capture logs. > > > > > > > > > > Hi Joe, > > > > > > > > > > this is the expected behavior since 'late acks' are triggered just > > > > > when the real > > > > > ack-timeout is higher than the initial default value (64us IIRC). In > > > > > other > > > > > words 'late acks' are necessary just on pretty long links > > > > > > > > > > Regards, > > > > > Lorenzo > > > > > > > > > > > Hi Joe, > > > > > > please keep the ml in cc > > > > > > > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > > > Is there yet another data point for the algorithm to oscillate in to > > > > an optimal ack_to setting? For a mobile use case, with increasing > > > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > > > increasing values? I'm fundamentally trying to understand if any > > > > there are any limitations to be aware of when applying dynack - > > > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > > > > > 'late ack' means that we received an ack for a packet where ack-timeout > > > is already > > > expired since the configured timeout was too low for the real distance. > > > If the real ack-timeout is less than the configured initial value (64us > > > --> ~ 10Km), > > > it is expected to not detected any 'late acks'. In this scenario the ack > > > timeout > > > should just converge to a good value. > > > If the real distance is grater than 10km we have to dump the ack-timeout > > > in order > > > to grab the station and estimate the real timeout (we need to dump the > > > ack-timeout since the estimation is done through data-ack transmissions). > > > Are we on the same page? > > > > > > Regards, > > > Lorenzo > > > > > > > Thanks for taking the time to get to this detail. > > > > Still a little fuzzy on what packets are in scope. When not late ack > > state: xmit a 'packet' and expect an ack in return -- all data > > 'packets' regardless if using wpa_supplicant or not? estimate and > > update ack_to > > > > "in order to grab the station and estimate the real timeout" > > Context is in a late ack state, all the acks are late "done through > > data-ack transmissions". Thus what does it mean to "grab the station > > and estimate" -- is this the dependency to wpa_supplicant and turning > > to measuring the handshaking packets generated by wpa_supplicant? > > And if I understand correctly, this state can only occur if the intial > > ack_to is shorter than physical distance. If initial ack_to is > > greater than physical, then we never get into this state. > > the main idea behind dynack is to measure the delta time between packet > transmission and the corresponding ack reception (~ 2 * acktimeout). > To do so we need to correlate the ack with the relative data packet. > This is easy if the already configured acktimeout is higher than the > station distance since the related ack will arrive before the timeout > expiration time. > If the station distance is higher than the current acktimeout we need to know > that a new station is connecting to the network since we need to dump the > acktimeout in order to start estimating its distance. This is done through > association/authentication packets and AFAIK they are not sent in IBSS mode if > we do not run wpa_supplicant. > > Regards, > Lorenzo > What would be the negative of starting out with an initial ack_to guess of, e.g. 100km and always let it come down to real. I know ack to values in these 70km ranges are working when statically set with the devices used at this long distance. Otherwise, if the values were limited and too short, the link performance would be unusable. I thought I saw late ack debug messages with IBSS and no wpa_supplicant (or 'option encryption none') at one point. I'll pick up the testing, but it is going to be a ~week. Have SoCal Linux Expo all weekend to prepare for. Also, inherently knowing the acktimeout is too high a ack_to, could also
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi > wrote: > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > Lorenzo,I've pulled out all patches related to extended ham radio > > > > > channels and ath9k is same out of openwrt 18.06.2.I replaced > > > > > wpad-mini > > > > > with the full version and "option encryption psk2". In testing > > > > > between a > > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > > However, > > > > > I do not see any late ack messages in the debug logging. > > > > > Shouldn't I be > > > > > seeing late acks? I can send full debug data on both sides of the > > > > > fence. > > > > > Is there anything that doesn't sound right in my setup? I wanted to > > > > > do > > > > > one more clean test to capture logs. > > > > > > > > Hi Joe, > > > > > > > > this is the expected behavior since 'late acks' are triggered just when > > > > the real > > > > ack-timeout is higher than the initial default value (64us IIRC). In > > > > other > > > > words 'late acks' are necessary just on pretty long links > > > > > > > > Regards, > > > > Lorenzo > > > > > > > > Hi Joe, > > > > please keep the ml in cc > > > > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > > Is there yet another data point for the algorithm to oscillate in to > > > an optimal ack_to setting? For a mobile use case, with increasing > > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > > increasing values? I'm fundamentally trying to understand if any > > > there are any limitations to be aware of when applying dynack - > > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > > > 'late ack' means that we received an ack for a packet where ack-timeout is > > already > > expired since the configured timeout was too low for the real distance. > > If the real ack-timeout is less than the configured initial value (64us --> > > ~ 10Km), > > it is expected to not detected any 'late acks'. In this scenario the ack > > timeout > > should just converge to a good value. > > If the real distance is grater than 10km we have to dump the ack-timeout in > > order > > to grab the station and estimate the real timeout (we need to dump the > > ack-timeout since the estimation is done through data-ack transmissions). > > Are we on the same page? > > > > Regards, > > Lorenzo > > > > Thanks for taking the time to get to this detail. > > Still a little fuzzy on what packets are in scope. When not late ack > state: xmit a 'packet' and expect an ack in return -- all data > 'packets' regardless if using wpa_supplicant or not? estimate and > update ack_to > > "in order to grab the station and estimate the real timeout" > Context is in a late ack state, all the acks are late "done through > data-ack transmissions". Thus what does it mean to "grab the station > and estimate" -- is this the dependency to wpa_supplicant and turning > to measuring the handshaking packets generated by wpa_supplicant? > And if I understand correctly, this state can only occur if the intial > ack_to is shorter than physical distance. If initial ack_to is > greater than physical, then we never get into this state. the main idea behind dynack is to measure the delta time between packet transmission and the corresponding ack reception (~ 2 * acktimeout). To do so we need to correlate the ack with the relative data packet. This is easy if the already configured acktimeout is higher than the station distance since the related ack will arrive before the timeout expiration time. If the station distance is higher than the current acktimeout we need to know that a new station is connecting to the network since we need to dump the acktimeout in order to start estimating its distance. This is done through association/authentication packets and AFAIK they are not sent in IBSS mode if we do not run wpa_supplicant. Regards, Lorenzo > > Initial value is > /* ackto = slottime + sifs + air delay */ > u32 ackto = 9 + 16 + 64; > > In comparison, I see a static distance to ack_to relationship as: > > ack_to = (distance in meters) / 151.51515151 + 64 > > A static setting is never below 64, but with dynack, I've observed > down to 55 at 10m real distance. I assume this isn't significant to > be concerned about. > > Joe > > > > > > > BTW, here's a ~77km long distance link that recently came online in > > > Alaska in 3GHz: > > > https://www.arednmesh.org/content/site-summit-yetna-linkThese > > > devices are 5GHz motherboards with -2GHz down-converters. > > > > > > Joe signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi wrote: > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > wrote: > > > > > > > Lorenzo,I've pulled out all patches related to extended ham radio > > > > channels and ath9k is same out of openwrt 18.06.2.I replaced > > > > wpad-mini > > > > with the full version and "option encryption psk2". In testing > > > > between a > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > However, > > > > I do not see any late ack messages in the debug logging. Shouldn't > > > > I be > > > > seeing late acks? I can send full debug data on both sides of the > > > > fence. > > > > Is there anything that doesn't sound right in my setup? I wanted to do > > > > one more clean test to capture logs. > > > > > > Hi Joe, > > > > > > this is the expected behavior since 'late acks' are triggered just when > > > the real > > > ack-timeout is higher than the initial default value (64us IIRC). In other > > > words 'late acks' are necessary just on pretty long links > > > > > > Regards, > > > Lorenzo > > > > > Hi Joe, > > please keep the ml in cc > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > Is there yet another data point for the algorithm to oscillate in to > > an optimal ack_to setting? For a mobile use case, with increasing > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > increasing values? I'm fundamentally trying to understand if any > > there are any limitations to be aware of when applying dynack - > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > 'late ack' means that we received an ack for a packet where ack-timeout is > already > expired since the configured timeout was too low for the real distance. > If the real ack-timeout is less than the configured initial value (64us --> ~ > 10Km), > it is expected to not detected any 'late acks'. In this scenario the ack > timeout > should just converge to a good value. > If the real distance is grater than 10km we have to dump the ack-timeout in > order > to grab the station and estimate the real timeout (we need to dump the > ack-timeout since the estimation is done through data-ack transmissions). > Are we on the same page? > > Regards, > Lorenzo > Thanks for taking the time to get to this detail. Still a little fuzzy on what packets are in scope. When not late ack state: xmit a 'packet' and expect an ack in return -- all data 'packets' regardless if using wpa_supplicant or not? estimate and update ack_to "in order to grab the station and estimate the real timeout" Context is in a late ack state, all the acks are late "done through data-ack transmissions". Thus what does it mean to "grab the station and estimate" -- is this the dependency to wpa_supplicant and turning to measuring the handshaking packets generated by wpa_supplicant? And if I understand correctly, this state can only occur if the intial ack_to is shorter than physical distance. If initial ack_to is greater than physical, then we never get into this state. Initial value is /* ackto = slottime + sifs + air delay */ u32 ackto = 9 + 16 + 64; In comparison, I see a static distance to ack_to relationship as: ack_to = (distance in meters) / 151.51515151 + 64 A static setting is never below 64, but with dynack, I've observed down to 55 at 10m real distance. I assume this isn't significant to be concerned about. Joe > > > > BTW, here's a ~77km long distance link that recently came online in > > Alaska in 3GHz: > > https://www.arednmesh.org/content/site-summit-yetna-linkThese > > devices are 5GHz motherboards with -2GHz down-converters. > > > > Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > wrote: > > > > > Lorenzo,I've pulled out all patches related to extended ham radio > > > channels and ath9k is same out of openwrt 18.06.2.I replaced wpad-mini > > > with the full version and "option encryption psk2". In testing between > > > a > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > > > float up to ~200, then settle down to ~55 -- seems about right. However, > > > I do not see any late ack messages in the debug logging. Shouldn't I > > > be > > > seeing late acks? I can send full debug data on both sides of the fence. > > > Is there anything that doesn't sound right in my setup? I wanted to do > > > one more clean test to capture logs. > > > > Hi Joe, > > > > this is the expected behavior since 'late acks' are triggered just when the > > real > > ack-timeout is higher than the initial default value (64us IIRC). In other > > words 'late acks' are necessary just on pretty long links > > > > Regards, > > Lorenzo > > Hi Joe, please keep the ml in cc > > Intuitively, aren't 'late acks' expected regardless of the distance? > Is there yet another data point for the algorithm to oscillate in to > an optimal ack_to setting? For a mobile use case, with increasing > distance apart, there'd need to be a 'late ack' equivalent to trigger > increasing values? I'm fundamentally trying to understand if any > there are any limitations to be aware of when applying dynack - > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. 'late ack' means that we received an ack for a packet where ack-timeout is already expired since the configured timeout was too low for the real distance. If the real ack-timeout is less than the configured initial value (64us --> ~ 10Km), it is expected to not detected any 'late acks'. In this scenario the ack timeout should just converge to a good value. If the real distance is grater than 10km we have to dump the ack-timeout in order to grab the station and estimate the real timeout (we need to dump the ack-timeout since the estimation is done through data-ack transmissions). Are we on the same page? Regards, Lorenzo > > BTW, here's a ~77km long distance link that recently came online in > Alaska in 3GHz: > https://www.arednmesh.org/content/site-summit-yetna-linkThese > devices are 5GHz motherboards with -2GHz down-converters. > > Joe signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> Lorenzo,I've pulled out all patches related to extended ham radio > channels and ath9k is same out of openwrt 18.06.2.I replaced wpad-mini > with the full version and "option encryption psk2". In testing between a > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > float up to ~200, then settle down to ~55 -- seems about right. However, > I do not see any late ack messages in the debug logging. Shouldn't I be > seeing late acks? I can send full debug data on both sides of the fence. > Is there anything that doesn't sound right in my setup? I wanted to do > one more clean test to capture logs. Hi Joe, this is the expected behavior since 'late acks' are triggered just when the real ack-timeout is higher than the initial default value (64us IIRC). In other words 'late acks' are necessary just on pretty long links Regards, Lorenzo > > It shouldn't matter on wpad-mini or wpad, correct? The size went from > ~500k to 727k, ouch. > > Joe > > On Thu, Feb 28, 2019 at 8:48 AM Lorenzo Bianconi < > lorenzo.bianc...@redhat.com> wrote: > > > > On Thu, Feb 28, 2019 at 1:59 AM Koen Vandeputte > > > wrote: > > > > > > > > > > > > On 27.02.19 08:13, Lorenzo Bianconi wrote: > > > > >> > > > > > What I mean is just a p2p link running in AP-STA mode, I guess there > > is no > > > > > difference for users. Am I missing something? > > > > > > > > > > > The design of the out-of-box firmware for AREDN, there are many end > > > users that do not have IT skill set to change these settings at > > > /etc/config level. Although, we could create high level UI setting > > > options. The firmware is packaged so a "node" can boot live and will > > > simply work extending the network with no previous coordination of > > > config settings -- it can be in any logical network position: P2P, > > > P2MP, MP2P, MP2MP.Adding such a setting of this network position > > > could be a fallback option to consider, but not desirable. > > > > > > > >> Is dynack going to receive the late acks if I manage to run > > > > >> wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? > > > > > What we really needs are authentication packets to trigger 'late > > acks' > > > > > in ibss mode. I think wpa_supplicant in plaintext is enough but I am > > not > > > > > 100% sure. > > > > > @Koen: could you please confirm it? > > > > > > > > Will try to test it asap. > > > > > > > > Regards, > > > > > > > > Koen > > > > > > > > > > I'm also working to test, but may not be for several days. > > > wpa_supplicant would be required on both ends? dynack is dependent on > > > ack's generated by wpa_supplicant? This is an upgrade issue of > > > people using old and and new versions of the firmware at the same time > > > across a larger network. > > > > Yes, you need it on both ends since late acks are detected on > > authentication > > messages in ibss mode and ack timeout estimation is done independently on > > each side. > > Could you please just try it on a single 50km link in order to double > > check if it > > works properly? > > > > Regards, > > Lorenzo > > > > > > > > Joe AE6XE > > signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Thu, Feb 28, 2019 at 1:59 AM Koen Vandeputte > wrote: > > > > > > On 27.02.19 08:13, Lorenzo Bianconi wrote: > > >> > > > What I mean is just a p2p link running in AP-STA mode, I guess there is no > > > difference for users. Am I missing something? > > > > > The design of the out-of-box firmware for AREDN, there are many end > users that do not have IT skill set to change these settings at > /etc/config level. Although, we could create high level UI setting > options. The firmware is packaged so a "node" can boot live and will > simply work extending the network with no previous coordination of > config settings -- it can be in any logical network position: P2P, > P2MP, MP2P, MP2MP.Adding such a setting of this network position > could be a fallback option to consider, but not desirable. > > > >> Is dynack going to receive the late acks if I manage to run > > >> wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? > > > What we really needs are authentication packets to trigger 'late acks' > > > in ibss mode. I think wpa_supplicant in plaintext is enough but I am not > > > 100% sure. > > > @Koen: could you please confirm it? > > > > Will try to test it asap. > > > > Regards, > > > > Koen > > > > I'm also working to test, but may not be for several days. > wpa_supplicant would be required on both ends? dynack is dependent on > ack's generated by wpa_supplicant? This is an upgrade issue of > people using old and and new versions of the firmware at the same time > across a larger network. Yes, you need it on both ends since late acks are detected on authentication messages in ibss mode and ack timeout estimation is done independently on each side. Could you please just try it on a single 50km link in order to double check if it works properly? Regards, Lorenzo > > Joe AE6XE signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Thu, Feb 28, 2019 at 1:59 AM Koen Vandeputte wrote: > > > On 27.02.19 08:13, Lorenzo Bianconi wrote: > >> > > What I mean is just a p2p link running in AP-STA mode, I guess there is no > > difference for users. Am I missing something? > > The design of the out-of-box firmware for AREDN, there are many end users that do not have IT skill set to change these settings at /etc/config level. Although, we could create high level UI setting options. The firmware is packaged so a "node" can boot live and will simply work extending the network with no previous coordination of config settings -- it can be in any logical network position: P2P, P2MP, MP2P, MP2MP.Adding such a setting of this network position could be a fallback option to consider, but not desirable. > >> Is dynack going to receive the late acks if I manage to run > >> wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? > > What we really needs are authentication packets to trigger 'late acks' > > in ibss mode. I think wpa_supplicant in plaintext is enough but I am not > > 100% sure. > > @Koen: could you please confirm it? > > Will try to test it asap. > > Regards, > > Koen > I'm also working to test, but may not be for several days. wpa_supplicant would be required on both ends? dynack is dependent on ack's generated by wpa_supplicant? This is an upgrade issue of people using old and and new versions of the firmware at the same time across a larger network. Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 27.02.19 08:13, Lorenzo Bianconi wrote: What I mean is just a p2p link running in AP-STA mode, I guess there is no difference for users. Am I missing something? Is dynack going to receive the late acks if I manage to run wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? What we really needs are authentication packets to trigger 'late acks' in ibss mode. I think wpa_supplicant in plaintext is enough but I am not 100% sure. @Koen: could you please confirm it? Will try to test it asap. Regards, Koen Regards, Lorenzo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Tue, Feb 26, 2019 at 1:57 PM Lorenzo Bianconi > wrote: > > > > > On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > > > > > > On 26.02.19 06:28, Joe Ayers wrote: > > > > > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > > > > > wrote: > > > > > > > > > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > > > > > wrote: > > > > > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > > > > > Hi Joe, > > > > > > > Hi Joe, > > > > > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > > > > > incorporated > > > > > > > > > > > into the http://www.arednmesh.org project, just getting > > > > > > > > > > > into our > > > > > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to > > > > > > > > > > > increase > > > > > > > > > > > that significantly. We commonly have long distance links > > > > > > > > > > > over 50km. > > > > > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > > > > > acktimeout > > > > > > > > > is 0x3fff. The max ack_to we can configure (assuming > > > > > > > > > clockrate set to > > > > > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If > > > > > > > > > you confirm it > > > > > > > > > works properly I can post a patch (or you can take care of > > > > > > > > > it, up to you) > > > > > > > > > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > > > > > > > > > distance 6m ( "463 S" ) > > > > > > > > channel width = 10MHz > > > > > > > > channel = 176 (5880) Amateur Radio licensing > > > > > > > > Ubiquiti Rocket M w/ RocketDish > > > > > > > > xmit power 27dBm > > > > > > > > > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > > > > > (without drop outs in the call) achieving 30db SNR and MCS15 > > > > > > > > rates. > > > > > > > > It's been live for a couple years in this mode. I don't > > > > > > > > understand > > > > > > > > how this link could operate with the performance we see if the > > > > > > > > ack_to > > > > > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > > > > > > > > > I have tested (limited tests) dynack on a link showing upwards > > > > > > > > of > > > > > > > > ~"400 A", but the real distance to farthest node was about > > > > > > > > ~20km. > > > > > > > > Was wondering the discrepancy (fading, etc.?)? I had changed > > > > > > > > the > > > > > > > > starting point to 20km to work, otherwise it was stuck on the > > > > > > > > original > > > > > > > > starting point, "96 A", and didn't move. > > > > > > > > > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from > > > > > > > > my new > > > > > > > > starting point of "196 A". Something in the calculation > > > > > > > > somewhere > > > > > > > > goes out of bound--to big a jump? I'll do some testing to get > > > > > > > > the > > > > > > > > dynack working on this 60km link, then lets see what it tunes > > > > > > > > to. > > > > > > > > Based on my earlier results, I'm wondering if it will push past > > > > > > > > 500. > > > > > > > > Maybe the vendor specs are only to the limit of what was > > > > > > > > tested, > > > > > > > > does not appear to be a true physical limit? > > > > > > > Could you add some debug logs from Dynack? > > > > > > > > > > > > > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: > > > > > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing > > > > > > > > > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another > > > > > > Rocket M5: > > > > > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing > > > > > > > > > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another > > > > > > tower at 7.68km distance > > > > > > > > > > > > Note: test case 1, the auto distance is much higher than actual > > > > > > (static set about 8km). > > > > > > test case 2, the auto distance does not change from > > > > > > initial > > > > > > value, although I raised MAX_DELAY sufficiently high enough. What > > > > > > dynack.c initial variable conditions would you recommend? > > > > > > test case 3, normally set as "115 S". dynack floated > > > > > > from > > > > > > 196 to 344, then back to 197 A when manually monitoring the ack_to > > > > > > value in debugfs. I've seen this behavior on 3 links now. > > > > > > > > > > > > Joe AE6XE > > > > > > > > > > Hi Joe, > > > > > > > > > > In the "long" log, I'm seeing that dynack is not synced. > > > > > I'm also not seeing any late ack's coming in. > > > > > > > > > > The "Short" log looks OK and is
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi > wrote: > > > > > > > > On 26.02.19 06:28, Joe Ayers wrote: > > > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > > > wrote: > > > > > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > > > wrote: > > > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > > > Hi Joe, > > > > > Hi Joe, > > > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > > > incorporated > > > > > > > > > into the http://www.arednmesh.org project, just getting into > > > > > > > > > our > > > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to > > > > > > > > > increase > > > > > > > > > that significantly. We commonly have long distance links > > > > > > > > > over 50km. > > > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > > > acktimeout > > > > > > > is 0x3fff. The max ack_to we can configure (assuming clockrate > > > > > > > set to > > > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If you > > > > > > > confirm it > > > > > > > works properly I can post a patch (or you can take care of it, up > > > > > > > to you) > > > > > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > > > > > distance 6m ( "463 S" ) > > > > > > channel width = 10MHz > > > > > > channel = 176 (5880) Amateur Radio licensing > > > > > > Ubiquiti Rocket M w/ RocketDish > > > > > > xmit power 27dBm > > > > > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > > > (without drop outs in the call) achieving 30db SNR and MCS15 rates. > > > > > > It's been live for a couple years in this mode. I don't understand > > > > > > how this link could operate with the performance we see if the > > > > > > ack_to > > > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > > > > > I have tested (limited tests) dynack on a link showing upwards of > > > > > > ~"400 A", but the real distance to farthest node was about ~20km. > > > > > > Was wondering the discrepancy (fading, etc.?)? I had changed the > > > > > > starting point to 20km to work, otherwise it was stuck on the > > > > > > original > > > > > > starting point, "96 A", and didn't move. > > > > > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from my > > > > > > new > > > > > > starting point of "196 A". Something in the calculation somewhere > > > > > > goes out of bound--to big a jump? I'll do some testing to get the > > > > > > dynack working on this 60km link, then lets see what it tunes to. > > > > > > Based on my earlier results, I'm wondering if it will push past 500. > > > > > > Maybe the vendor specs are only to the limit of what was tested, > > > > > > does not appear to be a true physical limit? > > > > > Could you add some debug logs from Dynack? > > > > > > > > > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: > > > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing > > > > > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another > > > > Rocket M5: > > > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing > > > > > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another > > > > tower at 7.68km distance > > > > > > > > Note: test case 1, the auto distance is much higher than actual > > > > (static set about 8km). > > > > test case 2, the auto distance does not change from initial > > > > value, although I raised MAX_DELAY sufficiently high enough. What > > > > dynack.c initial variable conditions would you recommend? > > > > test case 3, normally set as "115 S". dynack floated from > > > > 196 to 344, then back to 197 A when manually monitoring the ack_to > > > > value in debugfs. I've seen this behavior on 3 links now. > > > > > > > > Joe AE6XE > > > > > > Hi Joe, > > > > > > In the "long" log, I'm seeing that dynack is not synced. > > > I'm also not seeing any late ack's coming in. > > > > > > The "Short" log looks OK and is what you should see on proper syncing. > > > > > > > > > Could you try following on the long link? (if possible) > > > > > > - Ensure dynack gets enabled on boot > > > - Reboot both locations so they finish booting and setup IBSS at exactly > > > the > > > same time. > > > - Provide these logs from both ends. > > > > > > This allows to compare both ends on a side-by-side fashion. > > > > > > fyi, I've attached logs from my setup (24.1km link) > > > > > > You will notice some prints about late-ack's coming in, which is required. > > > > Hi Joe, > > > > are you running wpa_supplicant on ibss links? IIRC wpa_supplicant is > >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi wrote: > > > > > On 26.02.19 06:28, Joe Ayers wrote: > > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > > wrote: > > > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > > wrote: > > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > > Hi Joe, > > > > Hi Joe, > > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > > incorporated > > > > > > > > into the http://www.arednmesh.org project, just getting into our > > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to > > > > > > > > increase > > > > > > > > that significantly. We commonly have long distance links over > > > > > > > > 50km. > > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > > acktimeout > > > > > > is 0x3fff. The max ack_to we can configure (assuming clockrate set > > > > > > to > > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If you > > > > > > confirm it > > > > > > works properly I can post a patch (or you can take care of it, up > > > > > > to you) > > > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > > > distance 6m ( "463 S" ) > > > > > channel width = 10MHz > > > > > channel = 176 (5880) Amateur Radio licensing > > > > > Ubiquiti Rocket M w/ RocketDish > > > > > xmit power 27dBm > > > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > > (without drop outs in the call) achieving 30db SNR and MCS15 rates. > > > > > It's been live for a couple years in this mode. I don't understand > > > > > how this link could operate with the performance we see if the ack_to > > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > > > I have tested (limited tests) dynack on a link showing upwards of > > > > > ~"400 A", but the real distance to farthest node was about ~20km. > > > > > Was wondering the discrepancy (fading, etc.?)? I had changed the > > > > > starting point to 20km to work, otherwise it was stuck on the original > > > > > starting point, "96 A", and didn't move. > > > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from my new > > > > > starting point of "196 A". Something in the calculation somewhere > > > > > goes out of bound--to big a jump? I'll do some testing to get the > > > > > dynack working on this 60km link, then lets see what it tunes to. > > > > > Based on my earlier results, I'm wondering if it will push past 500. > > > > > Maybe the vendor specs are only to the limit of what was tested, > > > > > does not appear to be a true physical limit? > > > > Could you add some debug logs from Dynack? > > > > > > > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: > > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing > > > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another Rocket > > > M5: > > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing > > > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another > > > tower at 7.68km distance > > > > > > Note: test case 1, the auto distance is much higher than actual > > > (static set about 8km). > > > test case 2, the auto distance does not change from initial > > > value, although I raised MAX_DELAY sufficiently high enough. What > > > dynack.c initial variable conditions would you recommend? > > > test case 3, normally set as "115 S". dynack floated from > > > 196 to 344, then back to 197 A when manually monitoring the ack_to > > > value in debugfs. I've seen this behavior on 3 links now. > > > > > > Joe AE6XE > > > > Hi Joe, > > > > In the "long" log, I'm seeing that dynack is not synced. > > I'm also not seeing any late ack's coming in. > > > > The "Short" log looks OK and is what you should see on proper syncing. > > > > > > Could you try following on the long link? (if possible) > > > > - Ensure dynack gets enabled on boot > > - Reboot both locations so they finish booting and setup IBSS at exactly the > > same time. > > - Provide these logs from both ends. > > > > This allows to compare both ends on a side-by-side fashion. > > > > fyi, I've attached logs from my setup (24.1km link) > > > > You will notice some prints about late-ack's coming in, which is required. > > Hi Joe, > > are you running wpa_supplicant on ibss links? IIRC wpa_supplicant is mandatory > for dynack to work properly on ibss links. > > Regards, > Lorenzo > We do not run wpa_supplicant on ibss.Let's just say, the ~1950's regulations for Amateur Radio Licensing needs to be modernized :) . dynack is working fine for links up to ~30km right now, and we
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > On 26.02.19 06:28, Joe Ayers wrote: > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > wrote: > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > wrote: > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > Hi Joe, > > > Hi Joe, > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > incorporated > > > > > > > into the http://www.arednmesh.org project, just getting into our > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to increase > > > > > > > that significantly. We commonly have long distance links over > > > > > > > 50km. > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > acktimeout > > > > > is 0x3fff. The max ack_to we can configure (assuming clockrate set to > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If you > > > > > confirm it > > > > > works properly I can post a patch (or you can take care of it, up to > > > > > you) > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > distance 6m ( "463 S" ) > > > > channel width = 10MHz > > > > channel = 176 (5880) Amateur Radio licensing > > > > Ubiquiti Rocket M w/ RocketDish > > > > xmit power 27dBm > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > (without drop outs in the call) achieving 30db SNR and MCS15 rates. > > > > It's been live for a couple years in this mode. I don't understand > > > > how this link could operate with the performance we see if the ack_to > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > I have tested (limited tests) dynack on a link showing upwards of > > > > ~"400 A", but the real distance to farthest node was about ~20km. > > > > Was wondering the discrepancy (fading, etc.?)? I had changed the > > > > starting point to 20km to work, otherwise it was stuck on the original > > > > starting point, "96 A", and didn't move. > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from my new > > > > starting point of "196 A". Something in the calculation somewhere > > > > goes out of bound--to big a jump? I'll do some testing to get the > > > > dynack working on this 60km link, then lets see what it tunes to. > > > > Based on my earlier results, I'm wondering if it will push past 500. > > > > Maybe the vendor specs are only to the limit of what was tested, > > > > does not appear to be a true physical limit? > > > Could you add some debug logs from Dynack? > > > > > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another Rocket M5: > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another > > tower at 7.68km distance > > > > Note: test case 1, the auto distance is much higher than actual > > (static set about 8km). > > test case 2, the auto distance does not change from initial > > value, although I raised MAX_DELAY sufficiently high enough. What > > dynack.c initial variable conditions would you recommend? > > test case 3, normally set as "115 S". dynack floated from > > 196 to 344, then back to 197 A when manually monitoring the ack_to > > value in debugfs. I've seen this behavior on 3 links now. > > > > Joe AE6XE > > Hi Joe, > > In the "long" log, I'm seeing that dynack is not synced. > I'm also not seeing any late ack's coming in. > > The "Short" log looks OK and is what you should see on proper syncing. > > > Could you try following on the long link? (if possible) > > - Ensure dynack gets enabled on boot > - Reboot both locations so they finish booting and setup IBSS at exactly the > same time. > - Provide these logs from both ends. > > This allows to compare both ends on a side-by-side fashion. > > fyi, I've attached logs from my setup (24.1km link) > > You will notice some prints about late-ack's coming in, which is required. Hi Joe, are you running wpa_supplicant on ibss links? IIRC wpa_supplicant is mandatory for dynack to work properly on ibss links. Regards, Lorenzo > > > Thanks, > > Koen > > > > > > Thanks, > > > > > > Koen > > > > > > > > > > One of our common scenarios is a P2MP -- tower or cell site with > > > > > > > multiple clients. We're using adhoc mode with OLSR. I see the > > > > > > > ack_to > > > > > > > calculation is based on the furthest station. What happens when > > > > > > > the > > > > > > > furthest station is quiet for long periods of time, nothing but > > > > > > > beacons and olsr 'broadcast' traffic. In
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 26.02.19 06:28, Joe Ayers wrote: On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte wrote: On 25.02.19 17:33, Joe Ayers wrote: On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi wrote: On 24.02.19 21:32, Joe Ayers wrote: Hi Joe, Hi Joe, First of all, thanks for contributing this fix. I've incorporated into the http://www.arednmesh.org project, just getting into our nightly builds now. A comment and a couple questions... The MAX_DELAY was way too short for our community, had to increase that significantly. We commonly have long distance links over 50km. according to ath9k max configurable value in AR_TIME_OUT for acktimeout is 0x3fff. The max ack_to we can configure (assuming clockrate set to ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it works properly I can post a patch (or you can take care of it, up to you) I have a current link in Southern California with settings of: distance 6m ( "463 S" ) channel width = 10MHz channel = 176 (5880) Amateur Radio licensing Ubiquiti Rocket M w/ RocketDish xmit power 27dBm It is rock solid and streams multiple HD videos and voip calls (without drop outs in the call) achieving 30db SNR and MCS15 rates. It's been live for a couple years in this mode. I don't understand how this link could operate with the performance we see if the ack_to max was 372 -- the voip quality would be terrible. I have tested (limited tests) dynack on a link showing upwards of ~"400 A", but the real distance to farthest node was about ~20km. Was wondering the discrepancy (fading, etc.?)? I had changed the starting point to 20km to work, otherwise it was stuck on the original starting point, "96 A", and didn't move. I just loaded dynack on this 60km link and it doesn't move from my new starting point of "196 A". Something in the calculation somewhere goes out of bound--to big a jump? I'll do some testing to get the dynack working on this 60km link, then lets see what it tunes to. Based on my earlier results, I'm wondering if it will push past 500. Maybe the vendor specs are only to the limit of what was tested, does not appear to be a true physical limit? Could you add some debug logs from Dynack? Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another Rocket M5: https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing Test case 3 (no debug data) -- Ubiquiti NanoStation link to another tower at 7.68km distance Note: test case 1, the auto distance is much higher than actual (static set about 8km). test case 2, the auto distance does not change from initial value, although I raised MAX_DELAY sufficiently high enough. What dynack.c initial variable conditions would you recommend? test case 3, normally set as "115 S". dynack floated from 196 to 344, then back to 197 A when manually monitoring the ack_to value in debugfs. I've seen this behavior on 3 links now. Joe AE6XE Hi Joe, In the "long" log, I'm seeing that dynack is not synced. I'm also not seeing any late ack's coming in. The "Short" log looks OK and is what you should see on proper syncing. Could you try following on the long link? (if possible) - Ensure dynack gets enabled on boot - Reboot both locations so they finish booting and setup IBSS at exactly the same time. - Provide these logs from both ends. This allows to compare both ends on a side-by-side fashion. fyi, I've attached logs from my setup (24.1km link) You will notice some prints about late-ack's coming in, which is required. Thanks, Koen Thanks, Koen One of our common scenarios is a P2MP -- tower or cell site with multiple clients. We're using adhoc mode with OLSR. I see the ack_to calculation is based on the furthest station. What happens when the furthest station is quiet for long periods of time, nothing but beacons and olsr 'broadcast' traffic. In this case, there wouldn't be any acks received back? Would it drop out of the ack_to calculation, until user data is active? Thus, distance would tune to a shorter distance for another STA with user data being transferred? What is the behavior in this scenario? nope, we always take into account furthest station (even if it does not tx any data frame) otherwise it will be kicked out (we need to wait it leaves the network) Possibly an option to further optimize? For multi-point stations, maybe it is possible to tune the time out based on the max distance station actively sending user data. Regards, Lorenzo I made a small change so that '0' in /etc/config/wireless distance setting ended up being auto for ath9k. Did I miss an upstream patch to incorporate? Regards, Joe AE6XE Hi Lorenzo, Ensuring that Joe gets the best possible answer, could you please reply on above
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte wrote: > > > On 25.02.19 17:33, Joe Ayers wrote: > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > wrote: > >>> On 24.02.19 21:32, Joe Ayers wrote: > >> Hi Joe, > Hi Joe, > First of all, thanks for contributing this fix. I've incorporated > into the http://www.arednmesh.org project, just getting into our > nightly builds now. A comment and a couple questions... > > The MAX_DELAY was way too short for our community, had to increase > that significantly. We commonly have long distance links over 50km. > >> according to ath9k max configurable value in AR_TIME_OUT for acktimeout > >> is 0x3fff. The max ack_to we can configure (assuming clockrate set to > >> ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > >> We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it > >> works properly I can post a patch (or you can take care of it, up to you) > >> > > I have a current link in Southern California with settings of: > > > > distance 6m ( "463 S" ) > > channel width = 10MHz > > channel = 176 (5880) Amateur Radio licensing > > Ubiquiti Rocket M w/ RocketDish > > xmit power 27dBm > > > > It is rock solid and streams multiple HD videos and voip calls > > (without drop outs in the call) achieving 30db SNR and MCS15 rates. > > It's been live for a couple years in this mode. I don't understand > > how this link could operate with the performance we see if the ack_to > > max was 372 -- the voip quality would be terrible. > > > > I have tested (limited tests) dynack on a link showing upwards of > > ~"400 A", but the real distance to farthest node was about ~20km. > > Was wondering the discrepancy (fading, etc.?)? I had changed the > > starting point to 20km to work, otherwise it was stuck on the original > > starting point, "96 A", and didn't move. > > > > I just loaded dynack on this 60km link and it doesn't move from my new > > starting point of "196 A". Something in the calculation somewhere > > goes out of bound--to big a jump? I'll do some testing to get the > > dynack working on this 60km link, then lets see what it tunes to. > > Based on my earlier results, I'm wondering if it will push past 500. > >Maybe the vendor specs are only to the limit of what was tested, > > does not appear to be a true physical limit? > > Could you add some debug logs from Dynack? > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another Rocket M5: https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing Test case 3 (no debug data) -- Ubiquiti NanoStation link to another tower at 7.68km distance Note: test case 1, the auto distance is much higher than actual (static set about 8km). test case 2, the auto distance does not change from initial value, although I raised MAX_DELAY sufficiently high enough. What dynack.c initial variable conditions would you recommend? test case 3, normally set as "115 S". dynack floated from 196 to 344, then back to 197 A when manually monitoring the ack_to value in debugfs. I've seen this behavior on 3 links now. Joe AE6XE > > Thanks, > > Koen > > > > One of our common scenarios is a P2MP -- tower or cell site with > multiple clients. We're using adhoc mode with OLSR. I see the ack_to > calculation is based on the furthest station. What happens when the > furthest station is quiet for long periods of time, nothing but > beacons and olsr 'broadcast' traffic. In this case, there wouldn't > be any acks received back? Would it drop out of the ack_to > calculation, until user data is active? Thus, distance would tune to > a shorter distance for another STA with user data being transferred? > What is the behavior in this scenario? > >> nope, we always take into account furthest station (even if it does not tx > >> any data frame) otherwise it will be kicked out (we need to wait it leaves > >> the network) > >> > > Possibly an option to further optimize? For multi-point stations, > > maybe it is possible to tune the time out based on the max distance > > station actively sending user data. > > > >> Regards, > >> Lorenzo > >> > I made a small change so that '0' in /etc/config/wireless distance > setting ended up being auto for ath9k. Did I miss an upstream patch > to incorporate? > > Regards, > Joe AE6XE > >>> > >>> Hi Lorenzo, > >>> > >>> Ensuring that Joe gets the best possible answer, could you please reply on > >>> above comments/questions? > >>> > >>> > >>> Highly appreciated, > >>> > >>> Koen > >>> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 25.02.19 17:33, Joe Ayers wrote: On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi wrote: On 24.02.19 21:32, Joe Ayers wrote: Hi Joe, Hi Joe, First of all, thanks for contributing this fix. I've incorporated into the http://www.arednmesh.org project, just getting into our nightly builds now. A comment and a couple questions... The MAX_DELAY was way too short for our community, had to increase that significantly. We commonly have long distance links over 50km. according to ath9k max configurable value in AR_TIME_OUT for acktimeout is 0x3fff. The max ack_to we can configure (assuming clockrate set to ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it works properly I can post a patch (or you can take care of it, up to you) I have a current link in Southern California with settings of: distance 6m ( "463 S" ) channel width = 10MHz channel = 176 (5880) Amateur Radio licensing Ubiquiti Rocket M w/ RocketDish xmit power 27dBm It is rock solid and streams multiple HD videos and voip calls (without drop outs in the call) achieving 30db SNR and MCS15 rates. It's been live for a couple years in this mode. I don't understand how this link could operate with the performance we see if the ack_to max was 372 -- the voip quality would be terrible. I have tested (limited tests) dynack on a link showing upwards of ~"400 A", but the real distance to farthest node was about ~20km. Was wondering the discrepancy (fading, etc.?)? I had changed the starting point to 20km to work, otherwise it was stuck on the original starting point, "96 A", and didn't move. I just loaded dynack on this 60km link and it doesn't move from my new starting point of "196 A". Something in the calculation somewhere goes out of bound--to big a jump? I'll do some testing to get the dynack working on this 60km link, then lets see what it tunes to. Based on my earlier results, I'm wondering if it will push past 500. Maybe the vendor specs are only to the limit of what was tested, does not appear to be a true physical limit? Could you add some debug logs from Dynack? Thanks, Koen One of our common scenarios is a P2MP -- tower or cell site with multiple clients. We're using adhoc mode with OLSR. I see the ack_to calculation is based on the furthest station. What happens when the furthest station is quiet for long periods of time, nothing but beacons and olsr 'broadcast' traffic. In this case, there wouldn't be any acks received back? Would it drop out of the ack_to calculation, until user data is active? Thus, distance would tune to a shorter distance for another STA with user data being transferred? What is the behavior in this scenario? nope, we always take into account furthest station (even if it does not tx any data frame) otherwise it will be kicked out (we need to wait it leaves the network) Possibly an option to further optimize? For multi-point stations, maybe it is possible to tune the time out based on the max distance station actively sending user data. Regards, Lorenzo I made a small change so that '0' in /etc/config/wireless distance setting ended up being auto for ath9k. Did I miss an upstream patch to incorporate? Regards, Joe AE6XE Hi Lorenzo, Ensuring that Joe gets the best possible answer, could you please reply on above comments/questions? Highly appreciated, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi wrote: > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > Hi Joe, > > > > First of all, thanks for contributing this fix. I've incorporated > > > into the http://www.arednmesh.org project, just getting into our > > > nightly builds now. A comment and a couple questions... > > > > > > The MAX_DELAY was way too short for our community, had to increase > > > that significantly. We commonly have long distance links over 50km. > > according to ath9k max configurable value in AR_TIME_OUT for acktimeout > is 0x3fff. The max ack_to we can configure (assuming clockrate set to > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it > works properly I can post a patch (or you can take care of it, up to you) > I have a current link in Southern California with settings of: distance 6m ( "463 S" ) channel width = 10MHz channel = 176 (5880) Amateur Radio licensing Ubiquiti Rocket M w/ RocketDish xmit power 27dBm It is rock solid and streams multiple HD videos and voip calls (without drop outs in the call) achieving 30db SNR and MCS15 rates. It's been live for a couple years in this mode. I don't understand how this link could operate with the performance we see if the ack_to max was 372 -- the voip quality would be terrible. I have tested (limited tests) dynack on a link showing upwards of ~"400 A", but the real distance to farthest node was about ~20km. Was wondering the discrepancy (fading, etc.?)? I had changed the starting point to 20km to work, otherwise it was stuck on the original starting point, "96 A", and didn't move. I just loaded dynack on this 60km link and it doesn't move from my new starting point of "196 A". Something in the calculation somewhere goes out of bound--to big a jump? I'll do some testing to get the dynack working on this 60km link, then lets see what it tunes to. Based on my earlier results, I'm wondering if it will push past 500. Maybe the vendor specs are only to the limit of what was tested, does not appear to be a true physical limit? > > > > > > One of our common scenarios is a P2MP -- tower or cell site with > > > multiple clients. We're using adhoc mode with OLSR. I see the ack_to > > > calculation is based on the furthest station. What happens when the > > > furthest station is quiet for long periods of time, nothing but > > > beacons and olsr 'broadcast' traffic. In this case, there wouldn't > > > be any acks received back? Would it drop out of the ack_to > > > calculation, until user data is active? Thus, distance would tune to > > > a shorter distance for another STA with user data being transferred? > > > What is the behavior in this scenario? > > nope, we always take into account furthest station (even if it does not tx > any data frame) otherwise it will be kicked out (we need to wait it leaves > the network) > Possibly an option to further optimize? For multi-point stations, maybe it is possible to tune the time out based on the max distance station actively sending user data. > Regards, > Lorenzo > > > > > > > I made a small change so that '0' in /etc/config/wireless distance > > > setting ended up being auto for ath9k. Did I miss an upstream patch > > > to incorporate? > > > > > > Regards, > > > Joe AE6XE > > > > > > Hi Lorenzo, > > > > Ensuring that Joe gets the best possible answer, could you please reply on > > above comments/questions? > > > > > > Highly appreciated, > > > > Koen > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > On 24.02.19 21:32, Joe Ayers wrote: Hi Joe, > > First of all, thanks for contributing this fix. I've incorporated > > into the http://www.arednmesh.org project, just getting into our > > nightly builds now. A comment and a couple questions... > > > > The MAX_DELAY was way too short for our community, had to increase > > that significantly. We commonly have long distance links over 50km. according to ath9k max configurable value in AR_TIME_OUT for acktimeout is 0x3fff. The max ack_to we can configure (assuming clockrate set to ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it works properly I can post a patch (or you can take care of it, up to you) > > > > One of our common scenarios is a P2MP -- tower or cell site with > > multiple clients. We're using adhoc mode with OLSR. I see the ack_to > > calculation is based on the furthest station. What happens when the > > furthest station is quiet for long periods of time, nothing but > > beacons and olsr 'broadcast' traffic. In this case, there wouldn't > > be any acks received back? Would it drop out of the ack_to > > calculation, until user data is active? Thus, distance would tune to > > a shorter distance for another STA with user data being transferred? > > What is the behavior in this scenario? nope, we always take into account furthest station (even if it does not tx any data frame) otherwise it will be kicked out (we need to wait it leaves the network) Regards, Lorenzo > > > > I made a small change so that '0' in /etc/config/wireless distance > > setting ended up being auto for ath9k. Did I miss an upstream patch > > to incorporate? > > > > Regards, > > Joe AE6XE > > > Hi Lorenzo, > > Ensuring that Joe gets the best possible answer, could you please reply on > above comments/questions? > > > Highly appreciated, > > Koen > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 24.02.19 21:32, Joe Ayers wrote: First of all, thanks for contributing this fix. I've incorporated into the http://www.arednmesh.org project, just getting into our nightly builds now. A comment and a couple questions... The MAX_DELAY was way too short for our community, had to increase that significantly. We commonly have long distance links over 50km. One of our common scenarios is a P2MP -- tower or cell site with multiple clients. We're using adhoc mode with OLSR. I see the ack_to calculation is based on the furthest station. What happens when the furthest station is quiet for long periods of time, nothing but beacons and olsr 'broadcast' traffic. In this case, there wouldn't be any acks received back? Would it drop out of the ack_to calculation, until user data is active? Thus, distance would tune to a shorter distance for another STA with user data being transferred? What is the behavior in this scenario? I made a small change so that '0' in /etc/config/wireless distance setting ended up being auto for ath9k. Did I miss an upstream patch to incorporate? Regards, Joe AE6XE Hi Lorenzo, Ensuring that Joe gets the best possible answer, could you please reply on above comments/questions? Highly appreciated, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath9k: fix dynack in IBSS mode
First of all, thanks for contributing this fix. I've incorporated into the http://www.arednmesh.org project, just getting into our nightly builds now. A comment and a couple questions... The MAX_DELAY was way too short for our community, had to increase that significantly. We commonly have long distance links over 50km. One of our common scenarios is a P2MP -- tower or cell site with multiple clients. We're using adhoc mode with OLSR. I see the ack_to calculation is based on the furthest station. What happens when the furthest station is quiet for long periods of time, nothing but beacons and olsr 'broadcast' traffic. In this case, there wouldn't be any acks received back? Would it drop out of the ack_to calculation, until user data is active? Thus, distance would tune to a shorter distance for another STA with user data being transferred? What is the behavior in this scenario? I made a small change so that '0' in /etc/config/wireless distance setting ended up being auto for ath9k. Did I miss an upstream patch to incorporate? Regards, Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
