On Tue, Mar 5, 2019 at 8:31 AM Lorenzo Bianconi <lorenzo.bianc...@redhat.com> wrote: > > > 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 >
Understand, but was thinking whenever it gets into late ack condition, simply bump it back to 100k (or guess incrementally bump higher the ack_to) to push it back into ability to measure ack_to of data packets. This may be a better trade off when not doing encryption, assuming it is required with current implementation. Running wpa_supplicant is expensive RAM consumption if it can be avoided and we're pushing the ceiling on 32MB RAM devices. I'm seeing wpa-mini flash size of ~500k, but hopes of compiling even smaller. However, would like to avoid an increase of RAM altogether. Thanks for the dialog, I'll play with some different combinations, in a ~week, and post results on the long distance links. Joe > > > > 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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
