> On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi > <lorenzo.bianc...@redhat.com> wrote: > > > > > 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. > > > > the main idea behind dynack is to measure the delta time between packet > > transmission and the corresponding ack reception (~ 2 * acktimeout). > > To do so we need to correlate the ack with the relative data packet. > > This is easy if the already configured acktimeout is higher than the > > station distance since the related ack will arrive before the timeout > > expiration time. > > If the station distance is higher than the current acktimeout we need to > > know > > that a new station is connecting to the network since we need to dump the > > acktimeout in order to start estimating its distance. This is done through > > association/authentication packets and AFAIK they are not sent in IBSS mode > > if > > we do not run wpa_supplicant. > > > > Regards, > > Lorenzo > > > > What would be the negative of starting out with an initial ack_to > guess of, e.g. 100km and always let it come down to real. I know ack > to values in these 70km ranges are working when statically set with > the devices used at this long distance. Otherwise, if the values > were limited and too short, the link performance would be unusable. > I thought I saw late ack debug messages with IBSS and no > wpa_supplicant (or 'option encryption none') at one point. I'll pick > up the testing, but it is going to be a ~week. Have SoCal Linux Expo > all weekend to prepare for. Also, inherently knowing the > acktimeout is too high a ack_to, could also bump it down a guess notch > too.
even if you set the acktimeout to ~70km or 100km, it will not fix the problem since the acktimeout will be configured according to the stations currently connected. What does it happen if at given point a new 'very far' station is powered up? (with very far I mean the distance is higher than the configured acktimeout) Regards, Lorenzo > > Joe > > > > > > > > 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
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
