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

[Koen Vandeputte]

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?


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