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

Tue Feb 26 16:57:26 EST 2019

> On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi
> <lorenzo.bianconi at redhat.com> wrote:
> >
> > >
> > > On 26.02.19 06:28, Joe Ayers wrote:
> > > > 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
> > >
> > > 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 :) .

Hi Joe,

wpa_supplicant is mandatory to use dynack on ibss links so you need to
run it (otherwise dynack will not be able to trigger 'late' acks and
the processing will not converge for very long links).
The other possibility is to convert the ibss links in AP-STA mode.

Regards,
Lorenzo

> 
> dynack is working fine for links up to ~30km right now, and we are
> seeing max ack_to values above 400.   My original testing for the
> short link failed exactly the same way (with the original MAX_DELAY
> and starting ack_to) as the long link is failing now.     I changed
> MAX_DELAY and starting ack_to values to get working in the short link.
>   Now, we are seeing proper syncing in this debug data.   Can we not
> do similar changes for the long link?  Seems to be something in the
> logic conditions vs. wpa_supplicant.
> 
> We have 500+ node network here in  Southern CA spanning end to end
> probably over 400km.  This long link is a back bone between counties,
> so I need to be a little sensitive with the up/down and testing I'm
> doing.
> 
> Regards,
> Joe AE6XE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190226/860f89c9/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel