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?
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
