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

[Joe Ayers]

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.

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