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

[Joe Ayers]

On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte
<koen.vandeputte at ncentric.com> wrote:
>
>
> On 25.02.19 17:33, Joe Ayers wrote:
> > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi
> > <lorenzo.bianconi at redhat.com> 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 60000m  ( "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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel