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

Tue Mar 5 11:31:30 EST 2019

> 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

> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190305/4595c64a/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel