> On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > <lorenzo.bianc...@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
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
