> On Tue, Feb 26, 2019 at 1:57 PM Lorenzo Bianconi > <lorenzo.bianc...@redhat.com> wrote: > > > > > On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi > > > <lorenzo.bianc...@redhat.com> wrote: > > > > > > > > > > > > > > On 26.02.19 06:28, Joe Ayers wrote: > > > > > > 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 > > > > > > > > > > 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 > > > > Ok, let me look at this to see if I can get wpa_supplicant running. > It's not an option to move from ibss to ap-sta mode. The design is > such that any node can come online and extend the network > autonomously. ap-sta would generally mean a pre-designed network.
What I mean is just a p2p link running in AP-STA mode, I guess there is no difference for users. Am I missing something? > > Is dynack going to receive the late acks if I manage to run > wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? What we really needs are authentication packets to trigger 'late acks' in ibss mode. I think wpa_supplicant in plaintext is enough but I am not 100% sure. @Koen: could you please confirm it? Regards, Lorenzo > > I appreciate the help and dialog. We have a lot of people in our > community eager for this capability. One example is this group: > http://www.landops.com/ > > Joe AE6XE > > > > > > > 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 -- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel