Am 18.07.2018 um 19:01 schrieb Jean-Pierre TOSONI: > Hi Ben, > > I attached the patch. Please remind that it applies to ath9k. > > At the end there are 3 comments in French, translation follows: > 1) " longretry gives directly the transmit count, the +1 is useless. > Should rather have -1 to account for the first try" > 2) " The retries just made for this frame must be added in to know > If the max was overstepped" > 3) " Add the 1st try (probably useless). > Upstream version adds 1 to A-MPDU retries but I don't understand why. > Since above I removed the +1 to fix the count, I add +1 here once per > frame in case the "+1" is actually hiding a bug in the upstream version" > > @Toke: As you can see in the patch, the value 30 was the fixed value defined > in ath9k, I kept it for compatibility only (and that's why I wanted to make > it configurable :-) > On another hand, Minstrel in mac80211 seems to vary retries according to what > you say, i.e. Minstrel tries to stay below a certain amount of time, but this > only applies to short/long retries. > > Jean-Pierre We also experienced the problems regarding the inconsistencies between documentation and implementation. I will further throw in another set of patches: https://github.com/steinwurf/openwrt-patches/tree/master/openwrt-r41097/mac80211 I think they have have similarities but also other aspects to really restrict ath9k to the specified retry limits. This problem is as Toke already stated additionally depended on minstrel. It is really sad, that all this stuff is offtree and but there is the illusion of an setting in the mainline kernel, which firstly will not set the value as documented and different drivers will apply them (without warnings) in different ways. >> For general internet traffic, a retry count of 30 is way too high; that >> is up to 120 ms of HOL blocking latency. Better to just drop the packet >> at that point. >> >> Ideally, the retry count should be dynamically calculated in units of >> time (which would depend on the rate and aggregate size), and also take >> queueing time into account. I've been meaning to experiment with this >> for minstrel and ath9k, but haven't gotten around to it... We have running current research on this topic but focused on the effects in 802.11s mesh networks. With multiple(forwarding) wireless links, the retry limit have a bigger impact as only in managed mode setups, since every forwarding step is doing repeated transmissions. But I also totally agree, that the retry count needs to be considered in the bufferbloat/airtime queuing stuff, which Toke proposed. Nonetheless, since this ambiguities are known, wouldn't it be nice to clean up all this patches to enable at least ath9k and ath10k to do the right thing, or do anybody can tell why they weren't included the first time ? -- M.Sc. Benjamin Beichler Universität Rostock, Fakultät für Informatik und Elektrotechnik Institut für Angewandte Mikroelektronik und Datentechnik University of Rostock, Department of CS and EE Institute of Applied Microelectronics and CE Richard-Wagner-Straße 31 18119 Rostock Deutschland/Germany phone: +49 (0) 381 498 - 7278 email: Benjamin.Beichler@xxxxxxxxxxxxxx www: http://www.imd.uni-rostock.de/
