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

[Lorenzo Bianconi]

> 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

> 
> 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/20190304/6c9aa1f8/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel