[OpenWrt-Devel] ath9k: fix dynack in IBSS mode

Tue Mar 5 11:54:34 EST 2019

On Tue, Mar 5, 2019 at 8:31 AM Lorenzo Bianconi
<lorenzo.bianconi at redhat.com> wrote:
>
> > On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi
> > <lorenzo.bianconi at redhat.com> wrote:
> > >
> > > > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi
> > > > <lorenzo.bianconi at redhat.com> wrote:
> > > > >
> > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi
> > > > > > <lorenzo.bianconi at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel