[OpenWrt-Devel] ath9k: fix dynack in IBSS mode
joe at ayerscasa.com
Mon Mar 4 16:46:41 PST 2019
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?
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
"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.
> > 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
More information about the openwrt-devel