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

[Joe Ayers]

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.

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