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