On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi <lorenzo.bianc...@redhat.com> wrote: > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > <lorenzo.bianc...@redhat.com> wrote: > > > > > > > Lorenzo, I've pulled out all patches related to extended ham radio > > > > channels and ath9k is same out of openwrt 18.06.2. I replaced > > > > wpad-mini > > > > with the full version and "option encryption psk2". In testing > > > > between a > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > However, > > > > I do not see any late ack messages in the debug logging. Shouldn't > > > > I be > > > > seeing late acks? I can send full debug data on both sides of the > > > > fence. > > > > Is there anything that doesn't sound right in my setup? I wanted to do > > > > one more clean test to capture logs. > > > > > > Hi Joe, > > > > > > this is the expected behavior since 'late acks' are triggered just when > > > the real > > > ack-timeout is higher than the initial default value (64us IIRC). In other > > > words 'late acks' are necessary just on pretty long links > > > > > > Regards, > > > Lorenzo > > > > > Hi Joe, > > please keep the ml in cc > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > Is there yet another data point for the algorithm to oscillate in to > > an optimal ack_to setting? For a mobile use case, with increasing > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > increasing values? I'm fundamentally trying to understand if any > > there are any limitations to be aware of when applying dynack - > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > 'late ack' means that we received an ack for a packet where ack-timeout is > already > expired since the configured timeout was too low for the real distance. > If the real ack-timeout is less than the configured initial value (64us --> ~ > 10Km), > it is expected to not detected any 'late acks'. In this scenario the ack > timeout > should just converge to a good value. > If the real distance is grater than 10km we have to dump the ack-timeout in > order > to grab the station and estimate the real timeout (we need to dump the > ack-timeout since the estimation is done through data-ack transmissions). > Are we on the same page? > > Regards, > Lorenzo >
Thanks for taking the time to get to this detail. Still a little fuzzy on what packets are in scope. When not late ack state: xmit a 'packet' and expect an ack in return -- all data 'packets' regardless if using wpa_supplicant or not? estimate and update ack_to "in order to grab the station and estimate the real timeout" Context is in a late ack state, all the acks are late "done through data-ack transmissions". Thus what does it mean to "grab the station and estimate" -- is this the dependency to wpa_supplicant and turning to measuring the handshaking packets generated by wpa_supplicant? And if I understand correctly, this state can only occur if the intial ack_to is shorter than physical distance. If initial ack_to is greater than physical, then we never get into this state. Initial value is /* ackto = slottime + sifs + air delay */ u32 ackto = 9 + 16 + 64; In comparison, I see a static distance to ack_to relationship as: ack_to = (distance in meters) / 151.51515151 + 64 A static setting is never below 64, but with dynack, I've observed down to 55 at 10m real distance. I assume this isn't significant to be concerned about. Joe > > > > BTW, here's a ~77km long distance link that recently came online in > > Alaska in 3GHz: > > https://www.arednmesh.org/content/site-summit-yetna-link These > > devices are 5GHz motherboards with -2GHz down-converters. > > > > Joe _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel