> > On 24.02.19 21:32, Joe Ayers wrote: 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) > > > > 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) 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
